OpenAI: Vượt qua giới hạn mở rộng của PostgreSQL

 (pixelstech.net)
35 điểm bởi GN⁺ 2025-05-24 | 2 bình luận | Chia sẻ qua WhatsApp
  • OpenAI đã chia sẻ tại PGConf.dev 2025 cách sử dụng PostgreSQL mà không cần sharding nhưng vẫn xử lý hiệu quả lưu lượng từ hàng trăm triệu người dùng
  • Để giải quyết vấn đề nút thắt ghi, họ đã áp dụng nhiều cách tiếp cận như phân tán ghi, tối ưu truy vấn và quản lý schema
  • Các vấn đề chính được nêu gồm những giới hạn cấu trúc và khó khăn vận hành của PostgreSQL như phình to bảng/chỉ mục do thiết kế MVCC và độ trễ sao chép do WAL
  • Các chiến lược tối ưu truy vấn như phân tán tải đọc, giới hạn giao dịch dài và giảm thiểu ORM là trọng tâm
  • OpenAI đạt 1 triệu QPS thông qua hơn 40 replica phân tán theo địa lý, đồng thời bảo đảm tính sẵn sàng cao ngay cả khi xảy ra sự cố

Trường hợp mở rộng PostgreSQL ở quy mô lớn của OpenAI

Bối cảnh

  • Nhiều dịch vụ cốt lõi của OpenAI phụ thuộc vào PostgreSQL
  • Nếu cơ sở dữ liệu gặp sự cố, toàn bộ dịch vụ sẽ bị ảnh hưởng trực tiếp
  • Trước đây đã từng có các vụ gián đoạn ở những dịch vụ lớn như ChatGPT do vấn đề với PostgreSQL
  • OpenAI vận hành cơ sở dữ liệu được quản lý trên Azure với kiến trúc Primary-Replica (1 Primary duy nhất + hơn 40 Replica)
  • Trong môi trường phục vụ 500 triệu người dùng hoạt động hằng tháng, khả năng mở rộng là yếu tố then chốt đối với thành công kinh doanh

Thách thức chính

  • Lưu lượng đọc có thể được phân tán sang nhiều Replica, nhưng yêu cầu ghi lại tập trung vào một Primary duy nhất, gây ra nút thắt cổ chai
  • Các điểm cải thiện chính
    • Offload và phân tán mọi yêu cầu ghi có thể
    • Giảm tối đa việc các dịch vụ mới kết nối thêm vào DB Primary
  • Do cấu trúc MVCC (điều khiển đồng thời đa phiên bản), tồn tại các nhược điểm như phình to bảng/chỉ mục, tinh chỉnh garbage collection phức tạp và kiểm tra khả kiến của chỉ mục
  • Khi số lượng Replica tăng, lưu lượng WAL (Write-Ahead Logging) cũng tăng mạnh, khiến băng thông mạng trở thành một nút thắt khác

Biện pháp ứng phó

Phân tán tải cho cơ sở dữ liệu Primary

  • Dự đoán và giảm tải ghi:
    • Offload mọi tác vụ ghi có thể
    • Ngăn các thao tác ghi không cần thiết ở tầng ứng dụng
    • Áp dụng Lazy Write, điều chỉnh chu kỳ backfill dữ liệu
  • Tải đọc được phân tán sang Replica tối đa có thể; nếu buộc phải xử lý ở Primary thì phải đạt hiệu quả cao

Tối ưu truy vấn

  • Giao dịch dài chiếm giữ tài nguyên hệ thống trong thời gian dài, làm chậm garbage collection
  • Áp dụng Timeout theo session/truy vấn/client, giới hạn các session Idle in transaction
  • Chỉ ra rằng dùng ORM có thể làm tăng tính kém hiệu quả, khuyến nghị sử dụng thận trọng
  • Tối ưu các truy vấn multi-join phức tạp (ví dụ: join 12 bảng)

Ứng phó với điểm lỗi đơn (SPOF)

  • Nếu Primary lỗi thì không thể ghi; còn Replicas vẫn bảo đảm tính liên tục cho việc đọc ngay cả khi một phần gặp sự cố
  • Các yêu cầu quan trọng (ưu tiên cao) được xử lý trên Replica chuyên dụng để giảm thiểu nhiễu từ các yêu cầu ưu tiên thấp

Quản lý schema

  • Việc tạo bảng mới và đưa workload mới vào cụm bị hạn chế
  • Chỉ cho phép các thao tác nhẹ thêm/xóa cột trong giới hạn 5 giây; các thao tác yêu cầu viết lại toàn bộ bảng thì không được phép
  • Tạo/xóa chỉ mục chỉ được phép với tùy chọn CONCURRENTLY
  • Có vấn đề các truy vấn dài trên 1 giây liên tục chặn thay đổi schema, nên cần tối ưu/offload các truy vấn đó ở cấp ứng dụng

Kết quả vận hành

  • Toàn cụm xử lý 1 triệu QPS (đọc + ghi), hỗ trợ các dịch vụ chính của OpenAI
  • Không có gia tăng độ trễ sao chép dù đã thêm khoảng 40 Replica
  • Triển khai Read-only Replica ở nhiều Region khác nhau để duy trì độ trễ thấp
  • Trong 9 tháng gần đây chỉ xảy ra 1 sự cố SEV0 liên quan đến PostgreSQL
  • Đã bảo đảm được dung lượng để đáp ứng tăng trưởng trong tương lai

Các trường hợp sự cố

  • Lỗi cache gây ra hiệu ứng cascading
  • Một bug khiến tiến trình WALSender dừng truyền WAL và rơi vào trạng thái lặp khi mức sử dụng CPU cao → gây ra độ trễ sao chép

Các đề xuất cải tiến tính năng cho PostgreSQL

  1. Quản lý chỉ mục: đề xuất tính năng Disable để vô hiệu hóa an toàn các chỉ mục không cần thiết, nhằm giảm rủi ro trước khi xóa
  2. Khả năng quan sát: yêu cầu cung cấp các chỉ số dựa trên histogram/phân vị độ trễ như p95, p99
  3. Lịch sử thay đổi schema: cần tính năng lưu lại lịch sử thay đổi schema như DDL
  4. Làm rõ ý nghĩa các monitoring view: đặt câu hỏi về nguyên nhân và cách xử lý hiện tượng một session duy trì lâu ở trạng thái ClientRead
  5. Tối ưu tham số mặc định: cho rằng giá trị mặc định của PostgreSQL quá bảo thủ, đề xuất mặc định tốt hơn hoặc đưa vào heuristic

Bình luận của Lao Feng

  • Chiến lược mở rộng của OpenAI trong môi trường cực hạn như vậy là một trường hợp sử dụng thực tế có ý nghĩa đối với các nhà phát triển cốt lõi của PostgreSQL
  • Các dịch vụ quy mô lớn như Tantan ở Trung Quốc cũng có trải nghiệm tương tự (33 Replica, 400 nghìn QPS, áp dụng sharding ở phía ứng dụng)
  • Trong môi trường phần cứng hiệu năng cao ngày nay, cách tiếp cận như OpenAI cho thấy một cụm PostgreSQL đơn lẻ vẫn có thể mở rộng rất mạnh, hàm ý rằng không phải lúc nào cũng cần DB phân tán
  • OpenAI sử dụng Azure Managed PostgreSQL, hơn 40 Replica, triển khai cross-region và Kubernetes + PgBouncer
  • Dù nhận được hỗ trợ tập trung từ đội Azure PostgreSQL, năng lực vận hành của ứng dụng/DBA và khả năng quan sát vẫn là yếu tố thiết yếu
  • Có đề cập đến việc giám sát qua Datadog cùng gánh nặng về hiệu năng và chi phí
  • Bí quyết vận hành, kinh nghiệm thất bại và tài sản DBA là yếu tố cốt lõi đối với chất lượng dịch vụ

Hỏi đáp của Lao Feng

Tính năng vô hiệu hóa chỉ mục

  • Về mặt nội bộ, PostgreSQL có thể vô hiệu hóa index bằng trường indisvalid (tuy nhiên cần quyền superuser, và môi trường RDS có hạn chế)
  • Giải pháp thực tế là kiểm tra mức sử dụng index qua giám sát rồi xóa một cách an toàn

Mở rộng khả năng quan sát: độ trễ P95/P99

  • Việc hỗ trợ chỉ số phân vị trong pg_stat_statements là khó do overhead bộ nhớ; có các cách vòng như pg_stat_monitor/eBPF/giám sát độ trễ ở tầng ứng dụng
  • Trong môi trường Azure Managed PostgreSQL, một số tùy chọn (truy cập server, eBPF...) không được hỗ trợ

Lịch sử thay đổi schema

  • Có thể tận dụng log file, pgaudit, CREATE EVENT TRIGGER, pg_ddl_historization... (tuy nhiên cần quyền superuser và Azure RDS có hạn chế hỗ trợ)
  • Điều được mong muốn là lưu lịch sử dưới dạng system view/bảng có thể truy vấn

Ý nghĩa của monitoring view

  • Tổ hợp State=Active + WaitEvent=ClientRead có nghĩa là đang chờ đầu vào từ client trong lúc thực thi statement, và có thể do nhiều nguyên nhân chứ không hẳn là bug
  • Có thể giảm tác dụng phụ bằng cách giới hạn thời gian giữ kết nối (ví dụ cấu hình hết hạn kết nối ở tầng mạng như HAProxy, quản lý vòng đời connection pool phía client); chưa rõ Azure có hỗ trợ tính năng đó hay không

Tham số mặc định

  • Giá trị mặc định của PostgreSQL khá bảo thủ, nhưng có thể bù đắp bằng heuristic tinh chỉnh theo từng dịch vụ hoặc tự động tuning tham số (RDS, Pigsty...)
  • Nếu trong tương lai các công cụ PostgreSQL có khả năng tự phát hiện và áp dụng cấu hình theo đặc tả phần cứng, gánh nặng thực tế sẽ được giảm bớt

Tùy chọn tự vận hành (self-hosting)

  • Các vấn đề vận hành thực tế phát sinh không hẳn từ bản thân PostgreSQL mà chủ yếu từ giới hạn của dịch vụ quản lý Azure
  • Nếu tự xây cụm PostgreSQL trên IaaS với NVMe SSD (như Pigsty), độ linh hoạt về tính năng và vận hành sẽ tăng lên
  • Các giải pháp như Pigsty có thể giải quyết trước phần lớn yêu cầu của OpenAI, vì vậy tùy theo quy mô và nhu cầu mà vẫn có dư địa để cân nhắc áp dụng

Bài viết liên quan

2 bình luận

 
GN⁺ 2025-05-24
Ý kiến trên Hacker News

  • Tuần trước tôi tham dự PGConf và rất ấn tượng vì đây là một trong những phiên có đông người nhất; đặc biệt trong một hội nghị khá hướng nội, nơi phần lớn các phiên tập trung vào phát triển chính Postgres, thì đây là một case study mang lại cảm giác mới mẻ. Cần luôn nhớ rằng khi sản phẩm tăng trưởng thành công, nhiều đội ngũ thực ra không hiểu sâu cách mở rộng một phần cụ thể trong stack; bài trình bày này được đánh giá là một câu chuyện rất hay về cách một nhóm nhỏ vượt qua vấn đề và học hỏi dần. Thay vì những phản ứng đơn giản hóa kiểu “làm thế này là không được đâu?”, nó đã sống động cho thấy quá trình tăng trưởng và mức độ phổ biến rất cao của sản phẩm thông qua câu chuyện người dùng thực tế, nên là một phiên cực kỳ phù hợp với một sự kiện thiên về các developer nội bộ. Thông điệp cốt lõi của bài nói là nếu khối lượng ghi không nhiều, chỉ với các read replica và kiến trúc single-master cũng có thể mở rộng Postgres lên mức thông lượng đọc khổng lồ. Và đây mới chính là điều áp dụng cho phần lớn ứng dụng. Trong phần Q&A, chủ yếu là các core developer của Postgres đặt câu hỏi để tìm hiểu use case chứ gần như không có ý định chỉ trích; cảm nhận là cộng đồng Postgres thật sự rất thân thiện và cởi mở

    • Về thông điệp “nếu khối lượng ghi không nhiều thì có thể mở rộng mạnh thông lượng đọc của Postgres bằng single-master và read replica”, khi phỏng vấn thiết kế hệ thống tôi nhận ra có quá nhiều ứng viên muốn đưa vào các kiến trúc phân tán khổng lồ hoặc các hệ thống rốt cuộc sẽ phá vỡ tính nhất quán, ngay cả với một hệ thống đơn giản chỉ khoảng 5 lượt đọc mỗi giây. Mười triệu người dùng thật ra cũng chưa phải quy mô quá lớn. Trong khi cả ngành chỉ chăm chăm vào scale ngang, tôi mong nhiều người nhận ra rằng phần cứng thực tế đã nhanh và lớn hơn rất nhiều so với tưởng tượng. Giờ là thời đại bạn có thể thuê server 32TB RAM từ Amazon. Và ngay cả khi đã lên quy mô lớn, bảo đảm ACID vẫn cực kỳ quý giá

    • Cảm ơn, đó đúng là thông điệp cốt lõi mà bài nói thực sự muốn truyền tải (Bohan)

    • Có chỗ nào xem được slide hoặc bản ghi của bài nói này không?

    • Tôi có cảm giác thread này đang đánh giá nhóm đó hơi khắt khe. Những người dùng HN có nhiều kinh nghiệm trong lĩnh vực này hứng thú với việc các dịch vụ quy mô lớn như ChatGPT đã được mở rộng về mặt kiến trúc ra sao, và các công ty gần như có tài nguyên vô hạn tuyển dụng như thế nào. Chính thông điệp trong bài nói kiểu “nếu dùng ORM thì rất dễ sinh ra query kém hiệu quả nên hãy cẩn thận” lại được hiểu như một bằng chứng cho thấy nhóm đó vẫn chưa có nhiều kinh nghiệm vận hành hạ tầng ở quy mô lớn như vậy

  • Về mặt linh hoạt thì self-hosting postgres rất hấp dẫn, như có quyền superuser hoặc tận dụng các tính năng nâng cao, nhưng việc tự vận hành ngoài thực tế vẫn khiến tôi phải đắn đo. Tôi cũng hy vọng các nhà cung cấp cloud có thể hỗ trợ chuẩn một tính năng vô hiệu hóa index trong query planner trước khi thật sự drop index. Nếu là công ty lớn, chọn self-hosting để tùy biến stack hoàn toàn là quyết định hợp lý

    • Trong Postgres đã có nhiều cách để buộc dùng hoặc vô hiệu một index cụ thể, và vẫn dùng được cả trên các instance Postgres managed trên cloud. Ví dụ điển hình là chỉnh thiết lập query planner theo từng query (chẳng hạn enable_indexscan=off), hoặc chèn một phép toán số học đơn giản vào mệnh đề where để cố tình không dùng index, cũng như extension pg_hintplan (có thể dùng chú thích để hint nên dùng index nào, tham khảo: https://pg-hint-plan.readthedocs.io/en/latest/hint_table.html#hints-for-scan-methods)

    • Xin nói rõ là tôi thuộc đội Azure Postgres: OpenAI không self-host mà đang dùng PostgreSQL managed của Azure (Flexible Server)

    • Chính diễn giả của OpenAI (Bohan) đã xác nhận họ không chạy môi trường self-host mà dùng Azure Database for PostgreSQL. Trong bài nói có nhắc “Azure Postgres” nhiều lần, nhưng xin lỗi vì đáng lẽ phải làm rõ hơn đây là dịch vụ do Microsoft quản lý

    • Trong MySQL hay MariaDB có DDL cho phép tạo index ở chế độ INVISIBLE hoặc IGNORED để query planner bỏ qua, nên thật ngạc nhiên khi Postgres không có tính năng tương tự

    • Chỉ trích nguyên văn câu “Ưu điểm của self-hosting postgres là sự linh hoạt…”

  • Trước yêu cầu cần tính năng ghi lại lịch sử các sự kiện thay đổi schema (thêm/xóa cột, v.v.), có người hướng dẫn rằng điều này đã có thể triển khai theo thời gian thực bằng EVENT TRIGGER, và có thể tham khảo ví dụ triển khai trong Aquameta(https://github.com/aquametalabs/aquameta)

    • Chúng tôi cũng đang triển khai tính năng quản lý lịch sử thay đổi DDL trong môi trường Postgres nội bộ. Bản thân Postgres rất mạnh nên có thể làm theo nhiều cách, nhưng quản lý lịch sử và log vận hành của các DB lớn hoặc quan trọng cũng là nhu cầu cực kỳ phổ biến. Phần lớn mọi người không nhận ra tầm quan trọng của nó cho đến khi tự mình trải nghiệm đau thương. Không chỉ thay đổi DDL, mà cả khi các chính sách vận hành quan trọng được áp dụng, ví dụ thay đổi mô hình giá hay tùy biến SKU/giá, cũng nhất định phải đảm bảo khả năng “audit”. Khi thật sự thiết kế mô hình quan hệ đầy đủ thì trong ứng dụng thực tế chỉ có một số bảng thay đổi thường xuyên, còn đa số là các bảng “tĩnh” gần như không đổi; khi các bảng này thay đổi thì phải lưu lại lịch sử cẩn thận để dễ diễn giải dữ liệu cũ hoặc rollback

    • Chúng tôi (Xata) đều dùng EVENT TRIGGER trong cả pgroll(https://github.com/xataio/pgroll) lẫn pgstream(https://github.com/xataio/pgstream) để phát hiện thay đổi DDL, ghi lại lịch sử schema migration hoặc đưa sự kiện thay đổi schema vào logical replication stream. Tuy vậy, hầu hết các DBaaS dựa trên Postgres đều hạn chế phần nào EVENT TRIGGER vì quyền superuser; RDS/Aurora và Xata thì hỗ trợ, còn Supabase cũng đang chuẩn bị hỗ trợ

    • Cảm ơn vì vẫn nhớ tới Aquameta, sắp có tính năng mới rất hay được ra mắt

  • Những nội dung này như tạo index đồng thời ở quy mô lớn, tránh table rewrite, phân tán lưu lượng, transaction timeout, read replica, v.v. thật ra gần như là điều bắt buộc và khá cơ bản ngay cả ở quy mô nhỏ hơn OpenAI rất nhiều. Các yêu cầu với Postgres cũng là những thứ mọi người đã đòi hỏi từ lâu; dù tiêu đề gắn là “Next Level”, trên thực tế lại gần giống một quá trình đang cố sống cố chết giữ single-master để tiếp tục scale [trong bối cảnh workload mới bị hạn chế]. Điểm chính là chịu được tải đọc lớn một cách ổn định, mà bản thân điều này vốn đã là công thức kinh điển của read replica và scale ngang. Cách vô hiệu index bằng việc chỉnh trường nội bộ (indisvalid) cũng chỉ là mẹo không được hỗ trợ chính thức, và kiểu tinh chỉnh system catalog như vậy là nguy hiểm. Việc dựa vào monitoring view để xem index có được dùng hay không rồi drop cũng không phải lời giải hoàn hảo; nếu muốn xác định rõ hơn index nào cần hay không cần thì phải kiểm tra cả query plan mới đáng tin

    • TFA (bài gốc) nói OpenAI đang xử lý 1 triệu query mỗi giây trên Azure, và mức này trong môi trường cloud thực tế, đặc biệt khi dùng storage qua mạng, là khá ấn tượng. Tuy nhiên đây là con số được phân tán qua khoảng 40 read replica, nên mỗi instance chỉ khoảng 25 nghìn QPS, vì vậy cũng chưa hẳn là quá đáng kinh ngạc. Còn về tranh luận dùng index, nếu nắm được thống kê mới nhất và đặc tính của DB thì chỉ cần kiểm tra xem nên dùng index nào, và liệu điều kiện/projection của query có tuân theo left-most prefix của index hay không là đủ

    • Hoàn toàn không có giải thích nào về lý do OpenAI không shard Postgres, và điều đó thực sự gây bức bối. Chỉ cần shard theo người dùng thôi có lẽ vấn đề sẽ dễ hơn rất nhiều, nên tôi không hiểu vì sao họ cứ giữ single-master

  • Có vẻ họ đang dùng physical replication; còn tôi hiện đang cân nhắc chuyển sang logical replication để tiết kiệm chi phí, chủ yếu là giảm lưu lượng egress liên vùng. Từ Postgres 17 trở đi thì logical replication native có vẻ đã tiến bộ nhiều, nên tôi muốn hỏi liệu có đáng triển khai trong thực tế không

  • Có vẻ để phục vụ nhiều loại query thì họ hẳn cũng chạy song song các storage engine khác như key-value, search, vector search, cache, v.v., nên việc bài nói chỉ tập trung vào Postgres là hơi lạ. Có lẽ nội bộ họ thật sự đang dùng nhiều chiến lược khác nhau để phân tán traffic và tải

  • Tôi tự hỏi liệu sẽ có hiệu năng tốt hơn nếu chỉ tự vận hành trực tiếp instance ghi trên server chuyên dụng gắn SSD tốc độ cao cục bộ, còn phần đọc thì chỉ xử lý bằng dịch vụ managed hay không

  • Ý kiến rất mạnh là “hãy shard DB đi”. Chỉ cần shard theo người dùng hoặc tổ chức thôi là có thể giải quyết đơn giản các vấn đề chính hiện tại. Việc thử đi thử lại nhiều cách lách phức tạp như vậy chỉ khiến mọi thứ lòng vòng hơn

    • Trong bài nói, thông điệp cốt lõi là ngay cả không cần shard, kiến trúc single-master vẫn có thể scale lên thông lượng rất lớn; dĩ nhiên họ cũng đã cân nhắc sharding, nhưng trade-off không phù hợp và với cấu trúc hiện tại họ vẫn scale được

    • Người trình bày của OpenAI (Bohan) trả lời trực tiếp: workload của họ không dễ shard, và các workload ghi nhiều đã được tách khỏi PostgreSQL để xử lý theo dạng shard rồi; phần còn lại hầu như chỉ đọc nên đưa sharding vào sẽ tốn nỗ lực rất lớn. Hiện tại họ đánh giá chỉ với Azure Database for PostgreSQL cũng đã đủ khả năng mở rộng và còn dư địa cho tương lai. Dù vậy, về dài hạn họ không hề loại trừ hoàn toàn sharding, chỉ là chưa phải ưu tiên ngắn hạn

    • Có ý kiến cho rằng sharding không hề đơn giản như tưởng tượng. Lý do dùng một DB mạnh là để thực hiện các phân tích và truy vấn dữ liệu phức tạp; nếu mục tiêu chỉ là lưu trữ/phân tán đơn thuần thì dùng nhiều mount NFS còn đơn giản hơn

    • Phản hồi rất thực tế là việc bảo ai đó “cứ shard đơn giản đi” với một hệ DB khổng lồ cỡ một triệu query mỗi giây là điều không dễ. Shard theo tổ chức nghe có vẻ là khóa shard tự nhiên, nhưng ở quy mô này thì chẳng có gì là đơn giản cả

    • Phản ứng đồng tình mạnh với lập luận trên

  • Về nhận xét trong bài nói rằng phải cẩn thận khi dùng ORM, một người cho rằng tất cả ORM, đặc biệt là ORM hỗ trợ đa DB, đều có vấn đề. Khi dùng ORM, người ta chỉ nghĩ về pattern dữ liệu ở mức code ứng dụng, và rốt cuộc gần như không tận dụng được các tính năng mạnh mẽ mà từng DB cung cấp. Bản thân người này không dùng ORM chút nào, mà tích cực tận dụng query và tính năng dành riêng cho Postgres; tập trung vào sức mạnh của DB thay vì ngôn ngữ hay sự tiện lợi đem lại lợi ích lớn hơn nhiều. Kết luận là tự viết SQL tốt mới mang lại hạnh phúc cho toàn bộ hệ thống

    • Trước đây khi migrate từ DB2 sang psql, ORM đã giúp ích rất nhiều để giảm downtime. Nhờ ORM mà việc chuyển DB diễn ra minh bạch, hầu hết logic gần như không phải đụng vào; hơn nữa không phải mọi developer đều quen tự viết query, và nếu query bị trộn vào code thì việc refactor/đọc hiểu sẽ rất khó. Cuối cùng SQL rồi cũng sẽ được trừu tượng hóa thành library

    • Tôi đã dùng Django ORM rất lâu và thấy nó thực sự là phần mềm xuất sắc, nhưng gần đây dùng sqlc thì lại thấy kiểu chuyển query trực tiếp thành code Go có lẽ là điểm thỏa hiệp lý tưởng giữa ORM và raw SQL

    • Có lẽ chỉ là bạn chưa từng trải nghiệm một ORM thật sự tốt, chẳng hạn Entity Framework Core

  • Một góp ý nhẹ là tiêu đề “Scaling PostgreSQL to the Next Level at OpenAI” có vẻ mới đúng với tiêu đề thật của bài nói
 
ddogi 2025-05-25

Có vẻ như các sản phẩm thương mại như Oracle RAC hay DB2 pureScale có khả năng multi-write không nằm trong diện được cân nhắc nhỉ.