Cứ dùng Postgres đi

• Hầu hết các ứng dụng web đều cần lưu trữ dữ liệu bền vững, vì vậy khi tạo ứng dụng mới, mặc định nên chọn Postgres

Vì sao không phải sqlite?

• sqlite là một DB tốt, nhưng dữ liệu được lưu trong một tệp duy nhất
• Điều đó có nghĩa là ứng dụng chỉ chạy trên một máy duy nhất
• Phù hợp với ứng dụng desktop hoặc di động, nhưng có thể không phù hợp với website
  • Có những trường hợp dùng sqlite thành công cho website, nhưng đa phần là khi tự xây dựng máy chủ và hạ tầng riêng
• Bạn có thể phải từ bỏ tính năng sao lưu cơ sở dữ liệu tự động do nền tảng cung cấp và khả năng cấu hình nhiều máy chủ ứng dụng

Vì sao không phải DynamoDB, Cassandra, hoặc MongoDB?

• Những cơ sở dữ liệu này có hiệu năng rất tốt, nhưng đi kèm nhiều tiền đề:
  • Phải biết chính xác ứng dụng cần làm gì và các mẫu truy cập sẽ là gì
  • Có nhu cầu mở rộng tới quy mô dữ liệu rất lớn
  • Có thể chấp nhận đánh đổi một phần tính nhất quán
• Những cơ sở dữ liệu này hoạt động tương tự như các bảng băm phân tán, nên bạn phải phản ánh hiểu biết về mẫu truy vấn vào cách lưu trữ dữ liệu
• Nếu mẫu truy cập (truy vấn) thay đổi, bạn có thể phải xử lý lại toàn bộ dữ liệu
• Cơ sở dữ liệu quan hệ có thể dễ dàng thêm chỉ mục để phục vụ truy vấn, nhưng với cơ sở dữ liệu NoSQL thì điều đó khó hơn
• Không phù hợp cho các truy vấn phân tích
• Nếu sinh viên đại học hoặc lập trình viên mới vào nghề dùng MongoDB thì có lẽ họ sẽ cần được trợ giúp

Vì sao không phải Valkey?

• Cơ sở dữ liệu này, vốn được biết đến với tên Redis, nổi tiếng là một bộ nhớ đệm cực kỳ hiệu quả
• Có thể dùng làm cơ sở dữ liệu chính, nhưng có các vấn đề sau:
  • Nó lưu toàn bộ dữ liệu trong RAM nên rất nhanh, nhưng dung lượng RAM có giới hạn
  • Cần phải thỏa hiệp trong việc mô hình hóa dữ liệu

Vì sao không phải Datomic?

• Nếu bạn đã biết cái này rồi thì xin tặng bạn một "ngôi sao vàng"
• Datomic là một cơ sở dữ liệu NoSQL quan hệ, không gặp vấn đề "thiết kế ngay từ đầu (Up-front Design)", và có vài thuộc tính khá hay
  • Nó lưu dữ liệu dưới dạng các cặp EAVT(entity-attribute-value-time) thay vì bảng, và dùng chỉ mục tổng quát
  • Khi viết truy vấn, không cần phối hợp với tác giả trước đó. Chỉ cần truy vấn cơ sở dữ liệu ở trạng thái "hiện tại" tại một thời điểm nhất định. Dữ liệu mới, kể cả việc xóa (hay còn gọi là 'thu hồi/retractions') cũng không thực sự xóa dữ liệu cũ
• Nhưng nó cũng có một số nhược điểm:
  • Chỉ hoạt động trên các ngôn ngữ JVM
  • API không tốt với các ngôn ngữ ngoài Clojure
  • Thông báo lỗi phát sinh từ các truy vấn có cấu trúc sai rất khó hiểu
  • Thiếu công cụ vì không có hệ sinh thái công cụ kiểu như SQL

Vì sao không phải XTDB?

• Người dùng Clojure tạo ra rất nhiều cơ sở dữ liệu
• Nó tương tự Datomic, nhưng có các đặc điểm sau:
  • Cung cấp HTTP API nên không phụ thuộc vào JVM
  • Có thể truy vấn theo hai trục là "thời gian hệ thống" và "thời gian hiệu lực"
  • Hỗ trợ SQL API
• Nhưng vấn đề lớn nhất là nó vẫn còn "non trẻ". SQL API mới ra mắt năm ngoái, và gần đây họ còn thay đổi toàn bộ mô hình lưu trữ
  • Liệu 10 năm nữa nó còn tồn tại không? Khả năng được hỗ trợ dài hạn vẫn chưa chắc chắn

Vì sao không phải Kafka?

• Kafka là một log "chỉ ghi thêm (Append-Only)" rất tốt, phù hợp để xử lý dữ liệu ở quy mô TB
• Nó hoạt động cực kỳ tốt nếu bạn muốn làm các kiểu công việc event sourcing với dữ liệu đổ vào từ nhiều dịch vụ do nhiều nhóm khác nhau quản lý
• Tuy nhiên
  • Ở quy mô nhỏ, một bảng trong Postgres thường đã đủ để thay thế
  • Việc xây dựng consumer cho Kafka dễ phát sinh lỗi hơn bạn nghĩ, vì rốt cuộc bạn phải tự theo dõi vị trí của mình trong log
  • Bạn phải quản lý thêm hạ tầng bổ sung

Vì sao không phải ElasticSearch?

• Nếu tìm kiếm dữ liệu là tính năng chính của sản phẩm thì ElasticSearch là một lựa chọn phù hợp
  • Bạn sẽ phải ETL dữ liệu và quản lý toàn bộ quy trình, nhưng ElasticSearch được sinh ra cho tìm kiếm và làm điều đó rất tốt
• Nhưng nếu tìm kiếm không phải là chức năng cốt lõi thì khả năng tìm kiếm văn bản tích hợp sẵn của Postgres cũng đã đủ
  • Về sau bạn vẫn có thể bổ sung một công cụ tìm kiếm chuyên dụng

Vì sao không phải MSSQL hoặc Oracle DB?

• Câu hỏi thực sự bạn nên tự đặt ra là: "Nó có đáng tiền không?"
• Không chỉ chi phí giấy phép mà còn phải tính cả chi phí bị khóa vào hệ sinh thái
• Nếu lưu dữ liệu trong Oracle, bạn sẽ phải trả tiền cho Oracle mãi mãi và tiếp tục đào tạo lập trình viên
  • Bạn sẽ phải chọn một trong hai thứ vĩnh viễn: tính năng enterprise hoặc ví tiền của mình
• Trừ khi thực sự cần một tính năng cụ thể nào đó, tốt hơn hết là nên tránh dùng
  • Đừng dùng trừ khi có một tính năng sát thủ mà bạn không thể sống thiếu MSSQL

Vì sao không phải MySQL?

• Phần này hơi cần người đọc bổ sung thêm một chút
• MySQL thuộc sở hữu của Oracle, và một số tính năng bị khóa trong bản enterprise
  • Tất nhiên, MySQL đã được sử dụng từ lâu và có một bản miễn phí được dùng rất rộng rãi
• Tôi tin rằng Postgres là lựa chọn tốt hơn, nhưng vẫn cần thêm thông tin về MySQL

Vì sao không phải AI vector DB?

• Phần lớn các AI vector DB là công nghệ còn non trẻ, nên có rủi ro khi sử dụng
  • Nên thận trọng với các mô hình kinh doanh dựa trên bong bóng AI
• Kể cả nếu doanh nghiệp của bạn cũng chỉ là một trò lừa kiểu AI grift khác, thì có lẽ chỉ cần import openai là đủ

Vì sao không phải Google Sheets?

• Không có nhược điểm gì đặc biệt, nếu cần thì cứ dùng thôi

[hilft]

Cứ dùng Postgres thôi

Firestore...

[wedding]

Những bài viết khẳng định chắc nịch kiểu này đa phần là sai lầm mà người mới thường mắc phải..

[nemorize]

Xin hãy cứ dùng Postgres.

[roxie]

zzz

[bus710]

Tự nhiên tôi lại nhớ đến câu đùa kiểu như… muốn có được thông tin hay thì hãy câu tương tác haha
Dù sao thì với đa số lập trình viên backend, thứ đầu tiên họ dùng thường là postgresql nên…

[dicebattle]

Tôi tin rằng Postgres là lựa chọn tốt hơn, nhưng cần thêm thông tin về MySQL

haha;;;;

[koxel]

Vấn đề thực sự của MySQL Enterprise không phải là giấy phép, mà là ngay cả khách hàng trả phí cũng nhận được hỗ trợ cực kỳ tệ khi sự cố xảy ra.
Trước đây từng có lần chỉ mục MySQL bị hỏng khiến hệ thống không thể chạy, và dù đã gửi yêu cầu hỗ trợ thì phía Oracle cũng chỉ bảo rằng nếu mở ticket hỗ trợ thì họ sẽ hỗ trợ qua điện thoại, vậy thôi.
Cuối cùng phía khách hàng nói là không ổn rồi, nên bên tôi vẫn phải tự giải quyết.
Thay vì tin Oracle mà dùng Enterprise thì miễn phí vẫn là nhất..

[kaydash]

Sao không phải là mariadb, impala, hive, kudu

[koxel]

Các tính năng enterprise của MySQL là những thứ không nhất thiết phải cần, như connection pool riêng chẳng hạn..
Nếu đúng là môi trường enterprise thật thì thay vì dùng cái này, cài sql proxy ở lớp phía trước sẽ hiệu quả hơn cho cân bằng tải.
Tôi cũng thích Pgsql.. nhưng bảo là không thèm tìm hiểu MySQL mà cứ phán bừa vậy à.. haha

[iolothebard]

Cứ dùng MySQL thôi…

• Tại sao không phải là PostgreSQL? Phần này cần được hỗ trợ thêm một chút.

[love7peace]

MariaDB thì sao??

[aer0700]

Đây đúng là một bài đăng có thể gây ra tranh luận rất lớn...

[aer0700]

Lý do dùng SQLite là vì nó đơn giản và ở quy mô vừa phải thì cứ thế mà chạy rất ổn.
Cứ triển khai trước bằng SQLite, rồi sau này nếu cần thì chuyển sang Postgres cũng đâu có gì quá khó.

[xguru]

Lại là một bài ca ngợi Postgres xuất hiện theo định kỳ. Giờ thì cứ tận hưởng thôi!

Hãy cứ dùng Postgres cho mọi thứ
PostgreSQL là đủ rồi
Từ khi nào Postgres trở nên ngầu vậy

[GN⁺]

Ý kiến Hacker News

• Có nhiều ý kiến tiêu cực về MongoDB, nhưng phần lớn là thông tin sai

  • MongoDB phù hợp ở giai đoạn đầu
  • Khi dữ liệu tăng lớn, nó vẫn hoạt động ổn
  • Các vấn đề về tính nhất quán cũng được giải quyết tốt
  • MongoDB không phải là một distributed hash map như Dynamo
  • Nhiều người không hiểu rõ khả năng aggregation của MongoDB
  • Bảo không nên dùng MongoDB chỉ vì lập trình viên mới cần học SQL là điều không công bằng

• Ưu điểm của SQLite

  • Dựa trên tệp nên sao lưu dễ dàng
  • Nếu dùng ORM thì có thể dễ dàng nâng cấp từ SQLite lên Postgres

• Việc chỉ ra các khiếm khuyết kỹ thuật không có nhiều ý nghĩa

  • Rick Houlihan của MongoDB hiện đang làm việc tại MongoDB

• Lý do migrate từ MySQL sang Postgres

  • MySQL thuộc sở hữu của Oracle nên có rủi ro kinh doanh
  • Postgres có nhiều công cụ hơn để duy trì tính nhất quán dữ liệu
  • Các extension của Postgres giúp tiết kiệm thời gian phát triển
  • Hệ sinh thái công cụ của Postgres trưởng thành và hoàn thiện hơn

• Postgres còn thiếu hỗ trợ cho temporal table

  • Cần versioning “bi-temporal” theo SQL:2011 cho system time và application time
  • Trong các ngành bị quản lý chặt với yêu cầu báo cáo phức tạp, temporal table là lựa chọn lý tưởng

• Không hiểu lý do dùng SQLite

  • Cài đặt Postgres không khó
  • Cần giải thích sự khác biệt giữa SQLite và Postgres

• Xin lỗi vì đã nhắc sai tên Rick Houlihan

  • So sánh DynamoDB/Cassandra với MongoDB xuất phát từ bài nói chuyện của ông ấy
  • MongoDB là cơ sở dữ liệu lưu thông tin phi chuẩn hóa, nên không linh hoạt khi mô hình truy cập thay đổi

• Điều quan trọng là dùng thứ mình biết và triển khai thứ hữu ích

• MySQL giống như Javascript

  • Có nhiều quyết định tệ và yếu tố rủi ro
  • Nó vẫn chạy tốt, nhưng khi Postgres đã tồn tại thì không có lý do gì phải dùng nó

[touguy]

Postgres có nhiều công cụ hơn để duy trì tính nhất quán của dữ liệu
=> Có ví dụ nào không?

[leftliber]

Một nhược điểm của SQLite so với Postgres là dường như nó không hỗ trợ schema. Khi số lượng bảng tăng lên đến vài chục hoặc hơn, việc thiết kế để phân chia bảng theo đơn vị schema sẽ gọn gàng hơn, nhưng vì SQLite không làm được điều đó nên phải đưa toàn bộ phần phân loại vào tên bảng.