Kleppmann và Riccomini cập nhật DDIA: lưu trữ dần dời lên object store, đánh đổi dời theo
Ngày càng nhiều hệ thống dữ liệu cất dữ liệu trên object store thay vì ổ đĩa của máy chủ. Những đánh đổi cũ vẫn còn nguyên, chỉ chuyển sang chỗ khác, và cuốn sách này giúp bạn tìm ra chúng.
Khi chuyển từ ổ đĩa cục bộ sang object store, nhà cung cấp lo việc nhân bản, nhưng độ trễ và chi phí request trở thành đánh đổi mới.
Đồ hoạ: FDE Times
Tóm tắt nhanh
- Ấn bản 2 giữ phần lõi của ấn bản đầu, có thêm đồng tác giả Chris Riccomini, đồng thời bổ sung công nghệ và xu hướng mới.
- Một thay đổi kiến trúc đáng chú ý: lưu trữ chuyển dần sang object store, tức một dịch vụ từ xa đã được nhân bản sẵn.
- Với FDE, giá trị của sách nằm ở các câu hỏi về đánh đổi. Đó là những câu bạn sẽ phải hỏi ở site khách hàng nào cũng vậy.
Trong số những thay đổi được nhắc tới quanh ấn bản 2 của Designing Data-Intensive Applications, có một thay đổi nghe rất "hạ tầng". Đó là chỗ dữ liệu được cất: theo bài viết trên HackerNoon, ngày càng nhiều hệ thống ghi vào object store thay vì file system trên ổ đĩa cục bộ.
Với một FDE, chi tiết này không hề khô khan. Nó quyết định cụm máy của khách hàng có mở rộng nhanh được không, sự cố lúc nửa đêm làm mất bao nhiêu dữ liệu, và hóa đơn cuối tháng đến từ đâu. Vì thế cuốn sách đáng đọc lại, kể cả khi bạn đã đọc ấn bản đầu.
Ai viết, và lần này đổi những gì?
Trang cá nhân của Kleppmann ghi sách do O’Reilly Media xuất bản, ra mắt tháng 3/2026 và dày khoảng 670 trang. HackerNoon thuật lại rằng lần này Kleppmann mời Chris Riccomini, cộng sự lâu năm của ông, làm đồng tác giả.
Kleppmann mô tả ấn bản mới là bản xây tiếp trên nền ấn bản đầu, bổ sung những công nghệ mới và các xu hướng đang nổi lên.
Theo HackerNoon, mục tiêu biên soạn là giữ nguyên phần lõi, lồng thêm ý tưởng mới và làm mới chi tiết ở khắp cuốn sách. Nói cách khác, đây là một lần cập nhật lớn chứ không phải một cuốn sách mới.
Lựa chọn ấy có lý. Ngay từ ấn bản đầu, trang dataintensive.net đã giới thiệu sách như một tấm bản đồ để đi qua thế giới công nghệ lưu trữ và xử lý dữ liệu, vốn đa dạng và đổi rất nhanh. Bản đồ tốt không vẽ từng quán xá. Nó vẽ những con đường chính.
Ý tưởng đầu tiên: thiết kế nào cũng là một cuộc mặc cả
Sách xoay quanh năm đánh đổi mà hệ thống dữ liệu hiện đại nào cũng phải giải: khả năng mở rộng, tính nhất quán, độ tin cậy, hiệu quả và khả năng bảo trì. Bạn hiếm khi có được cả năm cùng lúc.
Một FDE dùng điều này hằng ngày. Khi khách hàng nói "dashboard phải realtime", câu hỏi thật sự là họ chấp nhận dữ liệu cũ bao nhiêu giây, và đổi lại được gì về chi phí hay độ ổn định. Ai hỏi được câu đó trong buổi customer discovery thường tiết kiệm cho cả đội một tuần làm lại.
Ý tưởng thứ hai: object store dời đánh đổi sang chỗ khác
Một thay đổi được nêu ra trong bài là lưu trữ ngày càng dựa trên object store, tức một dịch vụ từ xa đã được nhân bản sẵn, thay cho file system cục bộ.
Để thấy hệ quả, thử hình dung một cụm database 3 node lưu trên ổ đĩa cục bộ, mỗi node giữ một bản sao. Cuối tháng, khách hàng muốn tăng lên 6 node để chạy báo cáo. Mỗi node mới phải chép dữ liệu về trước khi làm việc được, và việc chép tốn cả thời gian lẫn băng thông.
Nếu dữ liệu nằm trên object store, 3 node thêm vào không cần chép gì. Chúng đọc thẳng từ kho chung, chạy xong thì tắt, còn việc nhân bản do nhà cung cấp lo. Nhưng đánh đổi không biến mất: về lý mà nói, đọc từ xa chậm hơn đọc ổ đĩa, và số request thành một dòng trên hóa đơn.
Đem ý tưởng đó vào stack của khách hàng thế nào?
Sách cho bạn bộ từ vựng về đánh đổi. Để dùng nó ở site khách hàng, bạn có thể đặt thêm một lăng kính không có trong sách: tách stack thành ba plane. Giả sử khách hàng dùng một managed data warehouse, dữ liệu nằm trên object storage.
| Lớp | Trong ví dụ warehouse | Câu hỏi nên hỏi khách hàng |
|---|---|---|
| Control plane | Catalog, metadata bảng, quyền truy cập, cấu hình cụm | Ai được sửa schema? Metadata hỏng thì phục hồi thế nào? |
| Data plane | File dữ liệu trên object store, đã được nhân bản sẵn | Dữ liệu nằm ở region nào? Giữ trong bao lâu? |
| Compute plane | Các cụm query bật lên theo nhu cầu, không giữ trạng thái | Giới hạn chạy đồng thời là bao nhiêu? Ai trả tiền cho query chạy lâu? |
Đặt năm đánh đổi của sách vào bảng này, bạn thấy chúng rơi vào những chỗ khác nhau. Độ tin cậy của dữ liệu thô phần lớn do data plane gánh, còn khả năng mở rộng nằm ở compute plane. Nhất quán và bảo trì dồn về control plane: hai job cùng ghi vào một bảng thì job nào thắng là do catalog quyết định, không phải ổ đĩa.
Vì thế, ở buổi làm việc đầu tiên với khách hàng, nên hỏi về control plane trước. Đó là lớp giữ trạng thái quan trọng nhất, nhưng lại ít khi có ai vẽ nó ra.
Ý tưởng thứ ba: học nguyên lý trước, công cụ sau
Cách biên soạn của chính cuốn sách, giữ phần lõi và làm mới chi tiết, cũng là một lời khuyên học tập. Một năm sau, tên sản phẩm trong CV của bạn có thể đã cũ. Còn khả năng giải thích vì sao một hệ thống chọn tính nhất quán thay vì độ trễ thấp thì vẫn dùng được.
Nếu bạn có 2-4 năm kinh nghiệm và chưa đọc ấn bản nào, hãy đọc ấn bản 2 từ đầu, đọc chậm, mỗi tuần một chương, và đối chiếu từng chương với một hệ thống bạn đang vận hành.
Nếu đã đọc ấn bản đầu, hãy dành thời gian cho những chỗ sách bổ sung công nghệ và xu hướng mới.
Khi đọc JD của các vị trí FDE, để ý những cụm như "data pipelines" hay "distributed systems". Trước buổi phỏng vấn, hãy chuẩn bị sẵn một câu chuyện về một quyết định đánh đổi cụ thể bạn từng đưa ra, và kể nó bằng chính năm khái niệm của sách.
Cuốn sách không giúp bạn chọn database cho dự án tới. Nó giúp bạn hỏi đúng câu trước khi phải chọn, và ở site khách hàng, một câu hỏi đúng thường đáng giá hơn một câu trả lời nhanh.