Ở các chương trước, chúng ta đã phân tích cơ chế log-based CDC ở tầng database: WAL của PostgreSQL, binlog của MySQL, replication slot, logical decoding. Chương này đi vào bên trong Debezium — thành phần đứng giữa database và Kafka — để trả lời câu hỏi mà mọi kiến trúc sư phải trả lời được trước khi đưa Debezium vào production: nó thực sự làm gì bên trong, trạng thái của nó nằm ở đâu, và điều gì xảy ra khi nó chết? ...
Đối tượng: Senior Backend Engineer, Tech Lead, Solution Architect thiết kế pipeline CDC end-to-end. Mục tiêu chương: Hai chương trước đi sâu vào từng nguồn log. Chương này trả lời câu hỏi ở tầng trên: bất kể nguồn là WAL, binlog hay oplog, một CDC connector phải giải năm bài toán bất biến: (1) dựng trạng thái ban đầu khi log không giữ toàn bộ lịch sử; (2) nhớ vị trí đọc để crash không chết pipeline; (3) đảm bảo gì về delivery; (4) đảm bảo gì về thứ tự; (5) sống sót qua schema change. Ai nắm năm bài toán này sẽ đánh giá được mọi công cụ CDC — Debezium hay bất cứ tên nào xuất hiện sau này — bằng cùng một checklist. ...
Đối tượng: Senior Backend Engineer, Tech Lead, Solution Architect vận hành CDC trên MySQL và MongoDB. Mục tiêu chương: Chương 4 đã mổ xẻ WAL của PostgreSQL. Chương này áp cùng khung tư duy lên hai họ database còn lại chiếm phần lớn thị phần CDC: MySQL (binlog) và MongoDB (oplog). Điểm mấu chốt không phải là học ba bộ thuật ngữ — mà là nhận ra ba hệ đã chọn ba mô hình retention và contract khác nhau cho cùng một bài toán, và mỗi lựa chọn sinh ra một failure mode đặc trưng mà bạn, người thiết kế platform, phải phòng thủ theo cách khác nhau. ...
Đối tượng: Senior Backend Engineer, Tech Lead, Solution Architect đang thiết kế hoặc vận hành pipeline CDC trên PostgreSQL. Mục tiêu chương: Sau chương này, bạn phải trả lời được ba câu hỏi mà mọi cuộc review kiến trúc CDC trên PostgreSQL đều xoay quanh: (1) WAL thực chất là gì và vì sao nó là nguồn sự thật duy nhất mà CDC có thể tin; (2) replication slot hoạt động thế nào và vì sao nó là con dao hai lưỡi nổi tiếng nhất của CDC trên PostgreSQL; (3) REPLICA IDENTITY ảnh hưởng gì đến nội dung event và bạn phải trả giá gì cho từng lựa chọn. ...
3.1. Insight nền tảng: dữ liệu về mọi thay đổi đã tồn tại sẵn Hãy quay lại điểm mà Chương 2 dừng lại. Chúng ta cần một nguồn thông tin về thay đổi thỏa mãn ba điều kiện: đầy đủ tuyệt đối (mọi thay đổi, từ mọi đường ghi, kể cả DELETE), atomic với dữ liệu commit (không event ma, không mất event), và không đặt thêm chi phí vào transaction path. ...
Chương 1 đã xác lập bài toán: dữ liệu buộc phải phân mảnh theo workload, và cần một cơ chế đưa thay đổi từ source of truth đến các hệ thống downstream. Chương này đi qua các phương pháp mà ngành đã dùng suốt ba thập kỷ — theo đúng thứ tự tiến hóa của chúng. Đây không phải bài điểm danh lịch sử: mỗi phương pháp vẫn đang chạy trong production ở đâu đó ngay lúc này, và mỗi phương pháp đều dạy ta một bài học về vì sao CDC log-based cuối cùng trở thành câu trả lời. Với mỗi phương pháp, ta phân tích theo cùng một template: cách hoạt động, ưu điểm, hạn chế kỹ thuật, một ví dụ production khi nó fail, và — quan trọng không kém — khi nào nó vẫn là lựa chọn đúng. ...
1.1. Bắt đầu từ một bài toán kinh doanh cụ thể Hãy hình dung một hệ thống e-commerce cỡ vừa: 5 triệu người dùng, 2 triệu SKU, khoảng 300.000 đơn hàng mỗi ngày. PostgreSQL là source of truth — nơi mọi transaction ghi đơn, trừ kho, cập nhật giá diễn ra. Hệ thống chạy tốt trong hai năm đầu. Rồi các yêu cầu sau lần lượt xuất hiện: Search: người dùng cần tìm kiếm sản phẩm theo full-text, fuzzy matching, faceted filter theo thương hiệu, khoảng giá, đánh giá. Đội ngũ chọn Elasticsearch. Analytics: đội business cần dashboard doanh thu theo giờ, phân tích cohort, funnel conversion trên hàng trăm triệu event. Đội data chọn ClickHouse. Cache: trang chi tiết sản phẩm chịu 20.000 request/giây lúc flash sale, không thể đánh thẳng vào PostgreSQL. Đội backend đặt Redis phía trước. Đến đây, cùng một thực thể product tồn tại ở bốn nơi: PostgreSQL (bản gốc), Elasticsearch (bản đánh index cho search), ClickHouse (bản denormalized cho analytics), Redis (bản serialized cho cache). Dữ liệu đã bị phân mảnh (data fragmentation). Và câu hỏi trung tâm của toàn bộ tài liệu này xuất hiện: ...
Bộ tài liệu chuyên sâu về Change Data Capture (CDC) — viết từ góc nhìn của người thiết kế Data Platform và Distributed Systems, không phải từ góc nhìn người dùng công cụ. Đối tượng: Backend Engineer, Data Engineer, Senior Backend Engineer, Tech Lead, Solution Architect, Software Architect. Triết lý trình bày: Business Problem → Vì sao cần đồng bộ dữ liệu → Hạn chế của Polling → Trigger / Dual Write / Event Publishing → CDC → Log-based CDC → Internal Architecture → Trade-off → Production → Khi nào không nên dùng CDC. ...
Thời gian gần đây khi mình tham gia các buổi phỏng vấn ở vị trí backend thì thường xuyên được hỏi đến các câu hỏi về database, trong đó chủ yếu xoay quanh transaction. Vậy nên trong bài viết hôm nay mình sẽ cùng ôn lại kiến thức về nó nhé. Nội dung này mình không rành lắm nên chủ yếu là góp nhặt và tích luỹ để viết cho bản thân nhớ lâu hơn — cũng tiện chia sẻ cho các bạn hữu duyên nếu đọc được. ...
Khi làm việc với database chắc hẳn chúng ta đã quen với các câu lệnh như SELECT, UPDATE, INSERT, DELETE,… Giả sử khi chạy một câu lệnh INSERT INTO ... để thêm record vào DB thì bên trong cơ sở dữ liệu sẽ làm những gì để xử lý? Trong bài viết này, hãy cùng mình tìm hiểu đằng sau một câu lệnh SQL khi thực thi sẽ đi qua những bước gì nhé. ...
Xin chào các bạn, Trong bài viết này, tôi sẽ chia sẻ một số kinh nghiệm cá nhân khi phải lựa chọn giữa hai loại cơ sở dữ liệu phổ biến là SQL và NoSQL, cụ thể là PostgreSQL và MongoDB. Bài viết không đi sâu vào lý thuyết SQL hay NoSQL là gì, mà sẽ tập trung vào góc nhìn thực tế khi phải đưa ra lựa chọn trong một dự án cụ thể. ...