Data Integration & Unbundling Databases — Tách database thành những chuyên gia nhỏ (DDIA) | Blog

Mở đầu

Ảnh: Markus Winkler — Pexels

Đến chương 12 của DDIA, Martin Kleppmann đưa ra một góc nhìn khá thú vị: thay vì coi database là một khối monolithic "làm được tất cả", ông đề xuất tư duy unbundling — tách database ra thành nhiều mảnh ghép chuyên biệt, mỗi mảnh làm một việc tốt nhất.

Câu hỏi đặt ra: nếu bạn có data, và bạn cần vừa query nhanh (OLTP), vừa phân tích (OLAP), vừa search full-text, vừa stream processing — thì liệu có một database nào làm hết được không? Câu trả lời là không, và đó là lý do chúng ta cần unbundling.

Bài toán data integration

Ảnh: Wolfgang Weiser — Pexels

Trong thực tế, một ứng dụng thường dùng nhiều hơn một data store. Bạn có PostgreSQL cho dữ liệu chính, Elasticsearch cho tìm kiếm, Redis cho cache, Kafka cho message queue, và một data warehouse (Snowflake, BigQuery) cho phân tích. Mỗi hệ thống đều chứa một phiên bản của dữ liệu — và việc giữ chúng đồng bộ là bài toán khó.

Vấn đề là mỗi hệ thống này được tối ưu cho một access pattern khác nhau:

OLTP database — tối ưu cho writes nhanh, transactional
Search index — tối ưu cho keyword search, full-text query
Data warehouse — tối ưu cho analytics scan, aggregation
Cache — tối ưu cho reads siêu nhanh
Stream processor — tối ưu cho data flow, real-time

Không có một hệ thống nào làm tốt tất cả. Và đó là lúc khái niệm "unbundling" xuất hiện.

Database "inside out" — Lật ngược database

Martin đề xuất một cách tư duy mới: đừng coi database là một hộp đen. Hãy nhìn vào bên trong — một database thực ra là sự kết hợp của nhiều thành phần nhỏ hơn:

Storage engine — cách dữ liệu được ghi và đọc từ disk
Indexing — cách tìm kiếm nhanh
Replication — cách copy dữ liệu giữa các node
Partitioning — cách chia dữ liệu
Transaction — cách đảm bảo consistency
Query processor — cách parse và tối ưu query

Nếu bạn tách rời các thành phần này, bạn có thể kết hợp chúng theo những cách khác nhau để giải quyết các bài toán khác nhau. Đây chính là unbundling.

Một cách nhìn khác: thay vì có một database "làm tất cả", bạn có nhiều hệ thống nhỏ, mỗi hệ thống là một "chuyên gia" trong lĩnh vực của nó. Và bạn dùng stream/batch processing để kết nối chúng lại.

Derived data — Dữ liệu được suy ra

Ảnh: Ray Bran — Pexels

Một ý quan trọng khác trong chương này là sự phân biệt giữa source of truth và derived data:

Source of truth — dữ liệu gốc, là primary data. Nếu mất nó, bạn không thể khôi phục được.
Derived data — dữ liệu được tính toán từ source, có thể tái tạo lại. Cache, search index, materialized view, aggregate đều là derived data.

Điều này thay đổi cách bạn nghĩ về consistency. Nếu derived data bị hỏng, bạn có thể xây lại nó từ source — không sao cả. Nhưng nếu source bị hỏng, bạn gặp vấn đề lớn.

Trong kiến trúc unbundling, source of truth thường là một OLTP database hoặc event log (Kafka). Còn tất cả các hệ thống khác (search, analytics, cache) đều là derived data — được cập nhật qua stream processors.

Streams làm "keo dán" kết nối mọi thứ

Vậy làm sao để kết nối tất cả các hệ thống chuyên biệt này? Câu trả lời của Martin là: dùng streams.

Change Data Capture (CDC) — bắt mọi thay đổi từ OLTP database và publish lên Kafka
Event sourcing — lưu tất cả events thay vì state hiện tại
Stream processors — đọc events từ Kafka, transform, và ghi vào derived systems (search index, cache, warehouse)
Batch processors — chạy định kỳ để rebuild lại derived data từ đầu nếu cần

Kafka ở đây đóng vai trò là "unbundled database log" — nó không phải là database truyền thống, nhưng nó là thành phần trung tâm giúp mọi thứ đồng bộ.

Điều này dẫn tới một kiến trúc rất phổ biến hiện nay: Kafka-Centric Architecture hoặc Data Mesh, nơi mỗi team sở hữu domain data của mình và publish events qua Kafka để các team khác consume.

Key Takeaways

Không có database nào làm tốt tất cả — unbundling giúp bạn chọn đúng công cụ cho đúng bài toán
Phân biệt source of truth (dữ liệu gốc) và derived data (dữ liệu suy ra) giúp bạn thiết kế hệ thống chịu lỗi tốt hơn
Streams (CDC, event log) là "keo dán" kết nối các hệ thống chuyên biệt lại với nhau
Một database truyền thống có thể được "unbundle" thành nhiều thành phần nhỏ hơn và kết hợp lại theo cách mới
Kiến trúc unbundling đặt nền móng cho Data Mesh, Kafka-centric architecture, và các hệ thống real-time hiện đại

Glossary

Thuật ngữ	Ý nghĩa
Unbundling	Tách database monolithic thành nhiều hệ thống chuyên biệt, kết nối qua streams
Derived data	Dữ liệu được tính toán từ source of truth — có thể tái tạo lại nếu mất
Source of truth	Dữ liệu gốc, primary data — nếu mất thì không thể khôi phục
Change Data Capture (CDC)	Cơ chế bắt mọi thay đổi trong database và publish thành event stream
Event sourcing	Lưu trữ tất cả events thay vì state hiện tại, cho phép rebuild state bất kỳ lúc nào
Materialized view	Một snapshot của kết quả query được tính toán trước và lưu lại để truy vấn nhanh

Kết

Unbundling databases là một tư duy thiết kế mạnh mẽ: thay vì cố gắng tìm một database "vạn năng", hãy chấp nhận rằng mỗi hệ thống có thế mạnh riêng, và dùng streams để kết nối chúng. Đây là nền tảng cho rất nhiều kiến trúc hiện đại — từ event-driven microservices đến data mesh.

Bài tiếp theo trong chương 12 sẽ đi sâu hơn về cách các công cụ xử lý dữ liệu (batch, stream, OLAP) đang hội tụ và trở nên khó phân biệt.