29 thg 8, 2025·8 phút
Chọn cơ sở dữ liệu theo mẫu truy cập, không theo xu hướng
Hướng dẫn thực tế chọn cơ sở dữ liệu theo đường đọc/ghi, độ trễ, tính nhất quán và nhu cầu tăng trưởng — để tránh tạo nợ kỹ thuật do chạy theo xu hướng.
Hướng dẫn thực tế chọn cơ sở dữ liệu theo đường đọc/ghi, độ trễ, tính nhất quán và nhu cầu tăng trưởng — để tránh tạo nợ kỹ thuật do chạy theo xu hướng.
Chọn cơ sở dữ liệu chỉ vì nó “phổ biến” giống như mua một phương tiện vì ai cũng nói về nó—mà không kiểm tra bạn cần xe máy, pickup hay xe buýt. Xu hướng phản ánh điều đã hiệu quả cho sản phẩm, kích thước đội, ngân sách và mức chịu rủi ro của người khác. Cơ sở dữ liệu của bạn phải phù hợp với workload của bạn: ứng dụng của bạn thực sự làm gì mỗi ngày.
Workload là hành vi thực tế của hệ thống trong production:
Những hành vi này là mẫu truy cập—những cách lặp lại ứng dụng của bạn chạm tới dữ liệu. Nếu bạn mô tả rõ mẫu truy cập, việc chọn cơ sở dữ liệu sẽ bớt bí ẩn.
Hiếm khi có một giải pháp cho tất cả. Nhiều hệ thống thành công dùng cách kết hợp: một cơ sở dữ liệu tối ưu cho giao dịch, một cho phân tích, và đôi khi một công cụ tìm kiếm hoặc cache riêng. Đó không phải là “độ phức tạp thừa”—mà là thừa nhận rằng các mẫu truy cập khác nhau hưởng lợi từ các kho lưu trữ và engine truy vấn khác nhau.
Trước khi so sánh “SQL vs NoSQL” hoặc đuổi theo cái đang hot, hãy ghi ra 5–10 truy vấn đọc và ghi hàng đầu. Bắt đầu từ đó; mọi thứ khác là chi tiết.
Một mẫu truy cập là mô tả thực tế cách ứng dụng của bạn tương tác với dữ liệu hàng ngày: đọc gì, ghi gì, tần suất, tốc độ, và dưới dạng nào. Nó ít liên quan đến dữ liệu là gì (“orders” hay “users”) và nhiều hơn đến bạn làm gì với nó (“lấy đơn hàng theo ID 10.000 lần mỗi phút” hay “scan tất cả đơn hàng tháng trước để làm báo cáo”).
Phần lớn lưu lượng đọc rơi vào vài nhóm nhận diện được:
Một feed mạng xã hội là ví dụ điển hình của dạng đọc hỗn hợp: bạn có thể tra cứu profile theo point lookup, range read cho “bài mới nhất,” và aggregation cho các đếm.
Mẫu ghi quan trọng không kém:
Log thường “ghi nhiều và append-only” (nhiều chèn, ít cập nhật). Đơn hàng thường “ghi rồi cập nhật” (tạo rồi thay đổi trạng thái).
Nhiều sản phẩm muốn mọi thứ: point lookup nhanh cho app, truy vấn phức tạp cho support, và scan lớn cho analytics. Một cơ sở dữ liệu có thể xử lý một vài sự phối hợp tốt, nhưng một số kết hợp sẽ xung đột—ví dụ scan phân tích nặng có thể làm chậm các đọc nhạy cảm độ trễ dùng cho checkout hoặc feed.
Khi bạn nêu rõ được mẫu truy cập, bạn có thể đánh giá cơ sở dữ liệu dựa trên hành vi thực tế thay vì độ nổi tiếng.
Trước khi so thương hiệu cơ sở dữ liệu, hãy gọi tên workload bạn thực sự phục vụ. Hầu hết sản phẩm không chỉ có “một workload”—chúng là vài workload khác nhau đứng cạnh nhau (và đôi khi cạnh tranh). Xác định đúng sớm sẽ ngăn bạn ép một cơ sở dữ liệu vào công việc nó không được tối ưu cho.
OLTP là nhịp tim hàng ngày của đa số app: nhiều đọc/ghi nhỏ, nhiều người dùng đồng thời và yêu cầu hoàn thành nhanh.
Hãy nghĩ: “cập nhật giỏ hàng,” “tạo đơn,” “thay đổi địa chỉ,” “kiểm tồn.” Những thao tác này ngắn, có mục tiêu và nhạy cảm về đúng đắn. Nếu một khoản thanh toán được xác nhận, nó không được biến mất; nếu một chỗ ngồi được giữ, không hai người cùng lấy một chỗ.
OLTP thường hướng bạn tới hệ thống xử lý concurrency tốt và cung cấp đảm bảo rõ ràng về transaction và tính toàn vẹn dữ liệu.
Phân tích đảo hình dạng công việc: ít truy vấn hơn, nhưng mỗi truy vấn chạm tới nhiều dữ liệu hơn.
Hãy nghĩ: “doanh thu theo vùng quý trước,” “tỷ lệ chuyển đổi theo kênh,” “top sản phẩm theo danh mục,” “xu hướng DAU.” Những truy vấn này thường scan nhiều hàng, group, aggregate và sort. Kỳ vọng độ trễ có thể lỏng hơn (vài giây có thể ổn), nhưng chi phí scan nặng thì quan trọng—đặc biệt nếu dashboard chạy cả ngày.
Nếu bạn cố gắng chạy truy vấn OLAP trên cùng hệ thống phục vụ checkout, thường sẽ có một trong hai bên bị ảnh hưởng.
Time-series và log thường append-heavy: sự kiện mới đến liên tục, và bạn thường truy vấn theo khoảng thời gian.
Hãy nghĩ: metrics, clickstream, telemetry thiết bị, audit log. Nhu cầu phổ biến gồm chính sách lưu trữ (xoá/expire dữ liệu cũ), rollup (giữ raw 7 ngày, aggregate 12 tháng), và ghi nhanh khi có spikes.
Workload này ít liên quan đến join phức tạp hơn là ingest hiệu quả rất nhiều bản ghi có timestamp và giữ dung lượng lưu trữ dự đoán được theo thời gian.
Tìm kiếm không chỉ là “tìm hàng.” Nó là khớp văn bản, xếp hạng relevance, tìm một phần, và lọc thân thiện với người dùng.
Hãy nghĩ: tìm sản phẩm theo từ khoá, tìm ticket theo cụm từ, lọc theo facet (hãng, khoảng giá, màu), và sắp xếp theo “phù hợp nhất.” Những tính năng này thường cần chỉ mục và khả năng truy vấn chuyên dụng mà cơ sở dữ liệu tổng quát có thể bắt chước—nhưng hiếm khi làm tốt hơn công cụ tìm kiếm chuyên dụng.
Nếu tìm kiếm là tính năng cốt lõi, coi nó như workload riêng ngay từ đầu, không phải chi tiết “sẽ thêm sau.”
Hiệu năng không chỉ một con số. Hai cơ sở dữ liệu đều có thể “nhanh” nhưng cảm nhận khác nhau đối với người dùng và người vận hành. Để chọn đúng, hãy tách những gì con người cảm nhận (độ trễ) khỏi những gì hệ thống phải chịu (thông lượng), rồi kiểm tra giả định bằng các đợt spike.
Độ trễ là thời gian một yêu cầu đơn lẻ mất—“nhấn nút, nhận kết quả.” Người dùng cảm nhận độ trễ trực tiếp.
Thông lượng là số yêu cầu bạn xử lý mỗi giây—lượng tải hệ thống có thể chịu.
Một cơ sở dữ liệu có thể đạt thông lượng cao bằng cách gom lô công việc, nhưng vẫn có độ trễ trên mỗi yêu cầu. Một hệ khác tối ưu cho đọc điểm nhanh nhưng vật lộn khi nhiều ghi đến cùng lúc.
Trung bình độ trễ che giấu đau đớn. Nếu 99 request xong trong 50 ms và 1 request mất 2 giây, giá trị trung bình trông ổn—nhưng 1% đó là khoảnh khắc “ứng dụng này chậm.”
Đó là ý nghĩa của P99 latency: thời gian chậm nhất của 1% yêu cầu. Với các tính năng hướng người dùng (checkout, login, kết quả tìm kiếm), P99 thường quyết định thiết kế database có cảm giác đáng tin hay không.
Phần lớn hệ thống không chết ở tải trung bình; chúng chết trong các đỉnh: email marketing, sự kiện thời sự, ngày trả lương, báo cáo cuối tháng.
Spike thay đổi cuộc trò chuyện về database:\n
Cache có thể khiến workload đọc trông nhỏ hơn—cho đến khi có cache miss hoặc purge.
Nếu phần lớn đọc trúng cache, cơ sở dữ liệu của bạn có thể chủ yếu phục vụ ghi và vài đọc tốn kém thỉnh thoảng. Điều đó ưu tiên các lựa chọn khác so với hệ thống mà mọi đọc đều vào database. Lên kế hoạch cho sự kiện “cold cache” và độ trễ đuôi của các miss, không chỉ đường tốt nhất.
Chọn cơ sở dữ liệu không chỉ về tốc độ. Còn là chuyện gì có thể sai, mất mát bao lâu bạn chịu được, và người dùng ở đâu.
Bắt đầu bằng cách nêu dữ liệu nào phải luôn đúng. Thanh toán, số dư tài khoản và tồn kho là ví dụ kinh điển. Nếu khách hàng bị tính hai lần, hoặc bạn bán quá số lượng, chi phí không chỉ là app chậm—mà là hoàn tiền, support và mất niềm tin.
Với những phần này, thường bạn muốn đảm bảo mạnh: ghi được xác nhận trước khi coi là hoàn tất, và người đọc không thấy cập nhật nửa chừng. Đổi lại, độ đúng đắn mạnh thường giảm bớt linh hoạt: một số chiến lược scale trở nên khó, và ghi đa vùng chậm hơn.
Tiếp theo, quyết định chuyện gì xảy ra nếu DB không khả dụng 5 phút.
Nếu downtime nghĩa là “đơn không thể đặt và doanh thu dừng,” bạn cần độ sẵn sàng cao hơn: failover tự động, backup tốt, và kế hoạch bảo trì mà không làm app ngưng. Nếu downtime chỉ làm dashboard nội bộ chậm, bạn có thể chấp nhận cấu hình đơn giản hơn.
Độ sẵn sàng cao hơn thường tăng chi phí và độ phức tạp vận hành (nhiều replica, giám sát, nâng cấp thận trọng). Chìa khóa là khớp khoản đầu tư đó với tác động kinh doanh.
Nếu người dùng tập trung một vùng, giữ dữ liệu một nơi rẻ hơn và nhanh hơn. Nếu người dùng phân bố toàn cầu—hoặc có yêu cầu pháp lý về vị trí dữ liệu—bạn cần sao chép đa vùng.
Thiết kế đa vùng cải thiện trải nghiệm và khả năng chịu lỗi, nhưng buộc bạn chọn: cho phép đọc lỗi thời nhẹ, hay chấp nhận ghi chậm hơn để giữ đồng bộ hoàn hảo? Câu trả lời phụ thuộc vào mức độ chấp nhận được của workload.
Phần lớn cuộc tranh luận “cơ sở dữ liệu” thực ra là tranh về hình dạng truy vấn. Nếu bạn biết câu hỏi ứng dụng phải trả lời—join, aggregation, filter, cửa sổ thời gian—bạn có thể thu hẹp lựa chọn nhanh chóng.
Mô hình quan hệ tỏa sáng khi bạn cần lọc linh hoạt và join giữa nhiều thực thể (customers → orders → items), đặc biệt khi yêu cầu thay đổi. Nếu sản phẩm cần báo cáo ad-hoc (“tìm tất cả khách hàng mua X rồi trả Y”), SQL và join thường đơn giản hơn theo thời gian.
Nếu truy vấn của bạn dự đoán trước và chủ yếu đọc theo khóa chính (“lấy profile theo user_id”), document hay key-value model có thể phù hợp—thường bằng cách lưu dữ liệu theo cách bạn đọc. Đổi lại bạn có thể nhân bản dữ liệu để tránh join, đẩy độ phức tạp sang ghi và cập nhật.
Index là cách bạn nói với DB: “đây là mẫu truy cập của tôi.” Một truy vấn trông ổn trong mockup có thể chậm nếu lọc hoặc sắp xếp trên trường không được index.
Quy tắc hữu ích: mọi filter, sort hoặc khóa join thường xuyên đều nên có kế hoạch index. Nhưng index không miễn phí: tốn lưu trữ và làm ghi nặng hơn.
Những tuyên bố “ghi nhanh” thường bỏ qua write amplification—công việc thừa do secondary index, compaction, replication, hay cập nhật nhiều bản sao dữ liệu denormalized. Thiết kế tối ưu đọc bằng cách thêm index hoặc sao chép tài liệu có thể âm thầm biến workload ghi cao thành nút thắt.
Schema-less không có nghĩa là vô cấu trúc. Schema linh hoạt giúp iter nhanh ban đầu, nhưng nếu không có quy ước, sẽ tạo trường hợp trường không đồng nhất, truy vấn khó gỡ lỗi và migration tốn kém sau này. Khi bạn dự đoán nhiều đội, nhiều tính năng hoặc thời gian lưu dài, schema chặt chẽ và ràng buộc rõ ràng thường giảm tổng chi phí—even nếu ban đầu có vẻ chậm hơn.
Chọn DB vì nó đang hot thường thất bại ở phần vận hành: giữ nó chạy, giữ an toàn, và trả hóa đơn hàng tháng. Hai DB có thể cùng đáp ứng chức năng, nhưng khác nhau nhiều về công sức vận hành và tổng chi phí.
Hỏi sớm ai sẽ trực ca lúc 2 giờ sáng để chạy hệ thống này. Backup, point-in-time recovery, nâng cấp, patch, drill failover, và giám sát không phải “việc sau”—chúng quyết định rủi ro và nhu cầu nhân sự.
Managed service giảm toil nhưng không xóa hết. Một số hệ đòi compaction định kỳ, tuning cẩn thận, hoặc chuyên môn sâu để tránh chậm. Hệ khác làm thay đổi schema đau đớn, hoặc cần playbook migration đặc biệt. Nếu đội bạn nhỏ, DB dễ vận hành có thể thắng “giải pháp hoàn hảo” trên giấy.
Chi phí DB thường đến từ:\n
Một mẫu truy cập nặng ghi và nhiều secondary index có thể nhân I/O và storage ngay cả khi dataset nhỏ.
Ngôn ngữ truy vấn độc quyền, tính năng nhất quán đặc thù, hoặc “serverless magic” có thể tăng tốc giao hàng—nhưng giới hạn di chuyển trong tương lai. Xem xét khả năng export dữ liệu, chạy local để test, hoặc đổi nhà cung cấp mà không phải viết lại app.
Ít nhất, xác nhận mã hoá khi truyền/lưu trữ, tùy chọn quản lý khóa, auditing, kiểm soát truy cập và chính sách lưu trữ. Nhu cầu tuân thủ thường quyết định giữa “hợp lệ” và “chấp nhận được”, bất kể độ hot của công nghệ.
Khi bạn mô tả mẫu truy cập (đọc gì, ghi gì, tần suất, và khi nào có spike), họ cơ sở dữ liệu phù hợp thường rõ ràng hơn. Mục tiêu không phải chọn công cụ phổ biến nhất—mà là hệ đơn giản nhất vẫn đúng dưới workload của bạn.
Chọn CSDL quan hệ khi bạn cần nhất quán mạnh, quan hệ rõ ràng và transaction đáng tin—orders, thanh toán, tồn kho, phân quyền, lịch biểu. Nếu bạn thường xuyên truy vấn xuyên thực thể (“khách hàng có hóa đơn mở trong 30 ngày”), SQL giúp giảm phức tạp ứng dụng.
Một heuristics: nếu đội bạn sắp phải tái thực hiện join, constraint và transaction trong code, có lẽ bạn cần DB quan hệ.
Document DB phù hợp khi bạn chủ yếu đọc/ghi toàn bộ đối tượng có cấu trúc thay đổi, như profile người dùng, trang nội dung, catalog sản phẩm có trường tùy chọn, hoặc cài đặt. Nếu truy vấn thông thường là “lấy profile theo user_id” và cập nhật các phần, document giữ dữ liệu cùng nơi bạn dùng.
Cẩn trọng khi truy vấn trở nên quan hệ cao (nhiều truy vấn xuyên tài liệu) hoặc khi cần giao dịch đa thực thể.
Key-value phù hợp cho cache, session, rate limit, feature flag, và trạng thái ngắn hạn nơi mẫu truy cập là “get/set theo key” và độ trễ quan trọng. Chúng thường là bổ trợ, không phải hệ chính lưu trữ.
Nếu bạn lưu dữ liệu nghiệp vụ bền vững, hãy cân nhắc chuyện gì xảy ra khi bị eviction, restart, hoặc trì hoãn replication.
Cho analytics—dashboard, cohort, revenue rollup, group-by trên lịch sử lớn—hệ columnar/warehouse thắng vì tối ưu cho scan và aggregate nhiều hàng hiệu quả.
Tách thực tế: giữ ghi OLTP trong DB chính, feed một warehouse cho báo cáo. Điều này tránh làm chậm truy vấn khách hàng với workload BI.
Nhiều sản phẩm thành công không “chọn một DB.” Họ map mỗi mẫu truy cập chính tới lưu trữ đơn giản nhất phục vụ tốt, ngay cả khi cần dùng hai hoặc ba DB chạy cùng lúc.
Cửa hàng trực tuyến thường có ba workload rất khác nhau:
Sản phẩm cảm nhận như một khối thống nhất, nhưng lưu trữ chuyên dụng theo mẫu truy cập.
Một SaaS B2B có thể lưu thực thể lõi (project, invoice, ticket) trong DB transaction, nhưng vẫn cần:
Nền tảng IoT ingest burst telemetry, sau đó đọc lại cho dashboard theo cửa sổ thời gian.
Phân tách phổ biến: store ingest nhanh cho dữ liệu gần đây, lưu trữ rẻ hơn cho lâu dài, và engine analytics cho aggregate.
Bài học: các thành phần có thể—và thường nên—dùng DB khác nhau khi mẫu truy cập lệch nhau.
Mismatch thường hiện ra dưới dạng dồn các “fix nhỏ.” Nếu đội dành nhiều thời gian chiến đấu với DB hơn xây sản phẩm, chú ý—đây thường là vấn đề mẫu truy cập, không phải tuning.
Một vài dấu hiệu xuất hiện thường xuyên:\n
Nếu DB đòi hỏi nỗ lực phi thường để hỗ trợ hoạt động bình thường, workload và họ DB có lẽ không khớp.
Chọn DB vì nó hot có thể khóa bạn vào chi phí dài hạn:\n
Hóa đơn đến khi quy mô tăng hoặc yêu cầu thay đổi, và cách sửa duy nhất thường là re-platform đau đớn.
Bạn không cần observability hoàn hảo, nhưng cần vài tín hiệu:\n
Ghi lại top mẫu truy cập (đọc/ghi, truy vấn chính, tốc độ đỉnh), giả định dung lượng dữ liệu, và những điều “không thể thương lượng” (tính nhất quán, sẵn sàng, ràng buộc vùng). Thêm link tới dashboard và ví dụ các truy vấn tồi tệ nhất. Bản ghi ngắn này làm quyết định sau này nhanh hơn—và cho thấy rõ khi nào DB không còn phù hợp.
Một access pattern là cách lặp đi lặp lại mà ứng dụng của bạn tương tác với dữ liệu trong môi trường production: điều gì được đọc/ghi, tần suất, tốc độ, và dạng truy vấn (point lookup, range scan, join, aggregation, cửa sổ thời gian, v.v.). Nó hành động hơn là nói “chúng tôi có users và orders” vì nó trực tiếp liên quan đến index, schema và phù hợp với cơ sở dữ liệu.
Bởi vì “phổ biến” phản ánh ràng buộc của đội khác, không phải của bạn. Cùng một cơ sở dữ liệu có thể tuyệt vời cho một workload (ví dụ OLTP) và là ác mộng cho workload khác (ví dụ truy vấn phân tích nặng). Hãy bắt đầu bằng cách liệt kê top 5–10 truy vấn đọc và ghi của bạn, rồi đối chiếu cơ sở dữ liệu với những hành vi đó thay vì theo đuổi danh tiếng thương hiệu.
Ghi lại:
Đây sẽ là tài liệu yêu cầu của bạn để so sánh các lựa chọn.
OLTP là nhiều thao tác nhỏ, đồng thời, nhạy cảm với tính đúng đắn (checkout, cập nhật tồn kho, thay đổi tài khoản) nơi transaction và constraint quan trọng.
OLAP/analytics là ít truy vấn hơn nhưng mỗi truy vấn xử lý nhiều dữ liệu (scan, group-by, dashboard) nơi độ trễ vài giây có thể chấp nhận được nhưng các lần đọc nặng có thể rất tốn kém.
Chạy cả hai trên cùng một hệ thống thường làm các truy vấn phân tích ảnh hưởng tới độ trễ cho người dùng.
Theo dõi p95/p99 latency, đừng chỉ nhìn trung bình. Nếu 1% các yêu cầu chậm mất vài giây, người dùng vẫn cảm thấy ứng dụng không đáng tin cậy ngay cả khi giá trị trung bình ổn.
Mẹo thực tế: track p95/p99 riêng cho các endpoint quan trọng (login, checkout, search) và liên kết các đợt tăng với chỉ số cơ sở dữ liệu (khóa, replication lag, I/O).
Khi các nhu cầu cạnh tranh nhau:
Dùng các hệ lưu trữ chuyên biệt có thể đơn giản hơn tổng thể so với ép một cơ sở dữ liệu làm mọi thứ bằng các giải pháp chắp vá.
Caching có thể khiến cơ sở dữ liệu chủ yếu phải xử lý ghi và những lần đọc tốn kém khi cache miss. Điều này thay đổi điều cần tối ưu:
Cache có thể che giấu vấn đề tạm thời, nhưng cũng có thể tạo ra thất bại đột ngột nếu các miss áp đảo database.
Tính đúng đắn mạnh mẽ nghĩa là bạn cần các đảm bảo về transaction và tính hiển thị của cập nhật (không được thấy trạng thái nửa chừng). Điều này đặc biệt quan trọng cho thanh toán, số dư tài khoản, tồn kho và đặt chỗ.
Các đánh đổi có thể gồm:
Xác định dữ liệu nào là “không được sai” và dữ liệu nào có thể chấp nhận trễ một chút.
Indexing là hợp đồng hiệu năng giữa workload và cơ sở dữ liệu. Lập kế hoạch index cho các:
Nhưng index tiêu tốn lưu trữ và làm chậm ghi (write amplification). Mục tiêu là index cho những gì bạn thực sự làm thường xuyên, không phải mọi thứ.
Hãy coi PoC như buổi diễn tập sản xuất nhỏ:
Nếu một lựa chọn không đáp ứng một yêu cầu bắt buộc trong PoC, loại bỏ sớm.