Chuyện Giao Dịch Database: Vì Sao App Của Bạn Chậm Như Rùa Bò và Cách Cải Thiện!

Lê Lân

22/08/2025

So Sánh Độ Trễ Giao Dịch Kinh Doanh Giữa PostgreSQL và MongoDB: Tối Ưu Hóa Logic Ứng Dụng và Mô Hình Dữ Liệu

Mở Đầu

Trong thế giới ứng dụng hiện đại, tối ưu hóa độ trễ (latency) của các giao dịch kinh doanh là yếu tố then chốt để nâng cao trải nghiệm người dùng và khả năng mở rộng của hệ thống. Các quy trình giao dịch truyền thống trong cơ sở dữ liệu quan hệ (SQL) như PostgreSQL thường yêu cầu nhiều lượt trao đổi giữa ứng dụng và cơ sở dữ liệu do mô hình dữ liệu phân tán và sự phụ thuộc vào đa bảng chuẩn hóa (normalization). Ngược lại, MongoDB – một cơ sở dữ liệu dạng document – sử dụng mô hình dữ liệu không chuẩn hóa, cho phép giao dịch diễn ra chỉ trong một lần gọi duy nhất lên cơ sở dữ liệu với toàn bộ thông tin giao dịch được lưu trữ trong một document.

Bài viết này sẽ phân tích chi tiết sự khác biệt về mặt kiến trúc và hiệu suất của hai hệ thống PostgreSQL và MongoDB trong các giao dịch đa bước, chứng minh lợi ích của việc giảm thiểu các lượt đi lại giữa client và database thông qua các ví dụ thực tế, đồng thời cung cấp cái nhìn sâu sắc về việc “business logic” nên đặt ở đâu để tối ưu hiệu quả.

1. Khó Khăn Trong Giao Dịch Đa Bước Với PostgreSQL

1.1 Các Vấn Đề Về Roundtrip và Latency

Khi một giao dịch kinh doanh yêu cầu cập nhật và truy vấn đồng thời nhiều bảng khác nhau, PostgreSQL theo mô hình chuẩn hóa thường phải thực thi nhiều câu lệnh SQL trong một transaction. Ví dụ, trong bài kiểm thử TPCB-like tiêu chuẩn bằng công cụ pgbench , các câu lệnh bắt đầu một transaction bao gồm BEGIN , cập nhật số dư tài khoản, truy vấn số dư, cập nhật bảng teller, chi nhánh, và ghi lịch sử giao dịch rồi cuối cùng END để commit transaction.

Việc chạy từng câu lệnh một trong transaction sẽ gây ra nhiều lượt client-server roundtrip làm tăng độ trễ tổng giao dịch lên gấp nhiều lần độ trễ mạng cơ bản (trong ví dụ, độ trễ thực tế lên đến 7 lần độ trễ mạng 50ms).

1.2 Ví Dụ Triển Khai và Kết Quả Thực Tế

Trong môi trường giả lập, khi thêm 50ms độ trễ mạng, toàn bộ một transaction trung bình mất khoảng 353 ms (với 7 câu lệnh cần thiết trong một transaction). Điều này dẫn đến throughput thấp (2.8 tps - transactions per second). Mỗi lệnh đều gây ra 1 lần gọi mạng và việc xử lý các câu lệnh rời rạc khiến tài nguyên hệ thống bị khóa trong thời gian dài, ảnh hưởng tiêu cực đến khả năng mở rộng.

1.3 Giải Pháp Sử Dụng Stored Procedures hoặc DO Blocks

Để giảm thiểu roundtrip, PostgreSQL có thể chạy toàn bộ logic trong một PL/pgSQL block hay stored procedure và gọi một lần duy nhất. Ví dụ, sử dụng lệnh DO với toàn bộ các câu lệnh SQL bên trong block:

DO '
begin
  UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
  PERFORM abalance FROM pgbench_accounts WHERE aid = :aid;
  UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
  UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
  INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
end;';

Với cách này, toàn bộ giao dịch qua một lần gọi, giảm đáng kể thời gian phản hồi xuống còn khoảng 51 ms, gần bằng với độ trễ mạng giả lập.

Tuy nhiên, thực tế stored procedures phức tạp trong phát triển, kiểm thử và triển khai, và nhiều dự án không ưa chuộng việc mã hóa business logic bên trong database.

2. Mô Hình Dữ Liệu và Transaction Trong MongoDB

2.1 Khác Biệt Về Mô Hình Dữ Liệu: Document vs. Bảng Chuẩn Hóa

MongoDB lưu trữ dữ liệu dưới dạng document JSON, cho phép gom toàn bộ thông tin liên quan đến một giao dịch kinh doanh vào trong một document duy nhất.

Cách thiết kế này giúp business transaction trở nên atomic trong một lần gọi, hạn chế tối đa roundtrip và tránh cần transaction đa collection phức tạp.

Ngược lại, việc phân tán dữ liệu trên nhiều collection (tương đương bảng) vẫn có thể thực hiện transaction đa document trong MongoDB, tuy nhiên hiệu suất và độ trễ không cải thiện đáng kể do phải xử lý nhiều lượt gọi.

2.2 Thực Thi Giao Dịch Đa Document Trên MongoDB

Kịch bản tương đương với Pgbench được triển khai với 4 collection (accounts, branches, tellers, history) và thực thi trong một transaction đa document. Mặc dù có thể tái sử dụng logic tương tự, độ trễ vẫn ở mức khoảng 319 ms với latency mạng 50 ms.

2.3 Giao Dịch Đơn Document: Giải Pháp Tối Ưu

Thay vì cập nhật đồng thời nhiều collection, MongoDB khuyến khích bạn lưu trữ toàn bộ thông tin transaction trong collection history dưới dạng một document duy nhất, với trường to_apply làm cờ trạng thái chờ xử lý.

Ví dụ:

db.history.insertOne({
  tid: tid,
  bid: bid,
  aid: aid,
  delta: delta,
  mtime: new Date(),
  to_apply: true // đánh dấu chờ áp dụng vào các bản tóm tắt
});

LƯU Ý: Việc cập nhật các bảng tổng hợp (accounts, tellers, branches) sẽ được xử lý bất đồng bộ trong background bằng transaction đa document nhằm giảm độ trễ trực tiếp cho ứng dụng.

2.4 Ưu Điểm Của Phương Pháp Này

Giao dịch kinh doanh của người dùng hoàn tất trong một roundtrip duy nhất, giảm độ trễ xuống còn gần bằng độ trễ mạng cơ bản (~54 ms).

Không cần transaction đa bước phức tạp khi thực thi thao tác chính.

Khả năng mở rộng và duy trì dễ dàng do tách bạch rõ ràng business logic và data update.

Giảm tải cho ứng dụng, thuật toán áp dụng bất đồng bộ chạy gần database.

2.5 Tối Ưu Tra Cứu Bản Cập Nhật Ngoài Giờ Thực

Sử dụng aggregation pipeline giúp truy vấn số dư tài khoản gần đúng ngay cả khi các giao dịch chưa được áp dụng hoàn toàn:

db.accounts.aggregate([
  { $match: { _id: 53077 } },
  { $lookup: {
      from: "history",
      let: { aid: "$_id", bid: "$bid" },
      pipeline: [
        { $match: { $expr: { $and: [
          { $eq: ["$to_apply", true] },
          { $eq: ["$aid", "$$aid"] },
          { $eq: ["$bid", "$$bid"] }
        ]}}},
        { $group: {
          _id: null,
          total: { $sum: "$delta" },
          mtime: { $max: "$mtime" }
        }}
      ],
      as: "pending"
  }},
  { $addFields: {
      abalance: { $add: ["$abalance", { $ifNull: [{ $arrayElemAt: ["$pending.total", 0] }, 0] }] },
      mtime: { $arrayElemAt: ["$pending.mtime", 0] }
  }},
  { $project: { pending: 0 }}
])

2.6 Bảo Trì Tìm Kiếm Thông Minh

Một index partial trên trường to_apply giúp tìm nhanh các giao dịch cần xử lý cũng như không tăng đáng kể độ trễ khi thêm mới:

db.history.createIndex({ bid: 1, aid: 1 }, { partialFilterExpression: { to_apply: true } });

3. Kết Luận: Nơi Đặt Logic Kinh Doanh Và Thiết Kế Ứng Dụng

3.1 Mối Quan Hệ Giữa Độ Trễ, Mô Hình Dữ Liệu Và Logic Ứng Dụng

Trong SQL chuẩn hóa, việc đa bảng và nhiều câu lệnh phức tạp khiến độ trễ tăng cao khi ứng dụng và database tách biệt địa lý.

Tối ưu duy nhất là gom business logic vào stored procedure / block duy nhất bên database để giảm lượt gọi, nhưng gây khó khăn phát triển và bảo trì.

MongoDB cho phép gom logic và dữ liệu của một transaction vào một document để thực thi giao dịch nguyên tử trong một yêu cầu, phù hợp kiến trúc ứng dụng hiện đại, giúp giảm thiểu latency đáng kể.

3.2 Lời Khuyên và Tư Duy Thiết Kế

Để đạt được hiệu suất tốt nhất trong giao dịch kinh doanh có tính thời gian thực và nhạy cảm với độ trễ:

Ưu tiên thiết kế mô hình dữ liệu sao cho các giao dịch chính có thể thực hiện chỉ trong một lần gọi atomic.

Tách biệt business logic và cập nhật bản tóm tắt (aggregates) theo cơ chế bất đồng bộ hoặc xử lý nền.

Hạn chế sử dụng multi-statement transactions từ ứng dụng, đặc biệt trong kiến trúc client-server phân tán.

Sử dụng stored procedures nếu chấp nhận được chi phí về phát triển và thử nghiệm.

Điều này giúp hệ thống ứng dụng không những đạt độ trễ thấp, mà còn dễ mở rộng, bảo trì và đảm bảo tính đúng đắn dữ liệu trong môi trường nhiều người dùng.

Tham Khảo

Pachot, F. (2025). Client-server latency in PostgreSQL and MongoDB. https://www.mongodb.com/docs/manual/core/transactions/?utm_campaign=devrel&utm_source=third-party-content&utm_term=franck_pachot&utm_medium=devto&utm_content=client-server-latency-in-postgresql-and-mongodb

Official PostgreSQL Documentation: pgbench Benchmark Tool

MongoDB Manual: Transactions

Feuerstein, S. (2018). The Smart DB Resource Center. https://stevenfeuersteinonplsql.blogspot.com/2018/05/the-smartdb-resource-center.html

Gray, J., & Reuter, A. (1993). Transaction Processing: Concepts and Techniques. Morgan Kaufmann.