Đây là loạt bài mình đăng trên Grokking NewsLetter, chuyên mục hệ thống phân tán - nay tóm tắt lại vào cùng một bài viết. Bài viết giới thiệu CAP theorem, NewSQL và hướng tiếp cận mới sử dụng CSDL tất định (deterministic database)

CAP Theorem

Khi nhắc tới định lí CAP, chắc hẳn các bạn engineer đều sẽ biết vì phát biểu đơn giản, nhưng ấn tượng: trong một hệ thống database, chỉ được chọn 2 trong 3 thuộc tính: Consistency; Availability; và Partitioning. Do vậy, một hệ thống database có thể được chia thành 3 dạng CA / CP và AP.

Tuy nhiên, theo như lời giới thiệu về paper Spanner, database dường như đảm bảo được cả 3 thuộc tính CAP, hay cách khác, vi phạm định lí CAP - đã được chứng minh?

Spanner is Google’s highly available global-scale distributed database. It provides strong consistency for all transactions. This combination of availability and consistency over the wide area is generally considered impossible due to the CAP Theorem

Giải thích ngắn gọn cho điều trên, Availability trong định lí CAP là 100% availability, một giả định không tưởng trên hầu hết các hệ thống chạy thực tế (cho dù single node hoặc multiple node). Tuy vậy, Spanner là một database chạy hoàn toàn bên trong cơ sở hạ tầng của Google (máy tính / đường dây mạng giữa các datacenter xuyên suốt các lục địa/ …). , cho nên Google có thể quản lí và tối ưu cho từng network packet chạy trong hệ thống. Spanner, do vậy, đảm bảo được 5 nines (99.999%) availability - 5 phút downtime/year. Từ đấy ta thấy, dưới góc độ của end-user khi sử dụng Spanner, hệ thống hầu như availability và không có downtime.

Hiểu cách khác, Spanner là hệ thống CP, và rất highly-available.

Chi tiết về nhận định trên có thể tham khảo qua bài viết sau từ Eric Brewer - tác giả của chính định lí CAP.

Google Research: Spanner, TrueTime and the CAP Theorem – Google Research

2-phase commit protocol

2PC - 2 phase commit, là một khái niệm ra đời từ lâu trong khoa học máy tính, được ứng dụng nhiều trong nhiều lĩnh vực khoa học máy tính: database; networking; … Trong lĩnh vực database, 2PC nhằm đảm bảo tính atomic cho một transaction . 2PC được biết, và sử dụng nhiều hơn trong hệ thống phân tán thông qua những database thuộc thế hệ NewSQL như Spanner; CockRoachDB; YugabyteDB …

Tuy nhiên, 2PC vẫn có những nhược điểm như độ trễ cao; scalability; availability … Một lí do xuất phất từ một giả định căn bản: Để đảm bảo tính atomic, một transaction có thể phải abort tại bất cứ lúc nào; và cho bất cứ lí do gì. Bài viết sau đưa ra góc nhìn mới về 2PC - nhìn lại giả định trên ở lăng kính mới, và từ đó đưa ra hướng thiết kế một cơ sở dữ liệu vẫn đảm bảo được tính atomic, nhưng đồng thời có thể khắc phục được những nhược điểm của 2PC.

It’s Time to Move on from Two Phase Commit

True-time API

NewSQL là khái niệm để chỉ về một lớp CSDL vừa có thể đảm bảo thuộc tính ACID như trên các hệ CSDL truyền thống - như MySQL / PostgresSQL, vừa đảm bảo tính scalability - dữ liệu được phân ra và đồng thời được replicate trên nhiều máy. Nhắc tới NewSQL, ta thường nghĩ đến Spanner và các CSDL phái sinh như CockRoachDB; YugabyteDB; TiDB; …

Các database này có các điểm chung như sử dụng consensus để replicate data, sử dụng 2PC - 2-phase commit để đảm bảo tính atomic giữa các data shard. Song song đó, để đảm bảo được thuộc tính strict serializability, Spanner sử dụng TrueTime API, mục đích để diễn tả tính không chắc chắn (uncertain) của đồng hồ thời gian trong hệ thống (hình minh họa). Điểm đặc biệt của API là tận dụng ưu thế cơ sở hạ tầng của Google, do vậy luôn đảm bảo error margin xấp xỉ 10ms. Đây cũng là điểm khó khăn cho các CSDL liệu khác xây dựng trên kiến trúc này vì không thể xây dựng được cơ sở hạ tầng tương tự như vậy.

Bài viết sau trình bày những điểm yếu của các database như YugabyteDB; CockroachDB gặp phải khi hiện thực lại theo paper Google Spanner, đồng thời giới thiệu hướng tiếp cận mới - mục đích có thể đảm bảo được “CAP consistency”, và hoàn toàn có thể hiện thực trên những hardware thông thường.

NewSQL database systems are failing to guarantee consistency, and I blame Spanner

Partitioned Consensus và Unified Consensus

Qua các loạt bài trước, ta đã tìm hiểu về ý nghĩa của CAP theorem trong hệ thống cơ sở dữ liệu (CSDL) phân tán và dẫn đến khái niệm NewSQL - đại diện tiêu biểu là Google Spanner. Thiết kế của Google Spanner có các đặc điểm chính như sau:

  • 2PL (2-phase locking): đảm bảo tính serializability trên cùng một data shard.
  • 2PC (2-phase commit): đảm bảo atomic giữa các data shard.
  • TrueTime API: đảm bảo strict serializability.
  • Thuật toán đồng thuận (cụ thể là Paxos): đảm bảo đồng thời tính thứ tự của event và replicate data cho trên cùng data shard.

Các loạt bài trước đã cho thấy ưu điểm, và đồng thời nhược điểm của giao thức 2PC và TrueTime API trong thiết kế hệ thống CSDL phân tán. Bài viết sau sẽ giải thích mảnh ghép cuối cùng - ứng dụng của thuật toán đồng thuận. Cụ thể, trong hệ thống phân tán, thuật toán đồng thuận có thể chia thành 2 dạng:

  • Partition consensus (ví dụ Google Spanner): mỗi data shard sẽ tham gia vào các quá trình đồng thuận độc lập nhau.
  • Unified consensus: toàn bộ thao tác trong hệ thống phải cùng tham gia vào cùng một quá trình đồng thuận.

Sử dụng partition consensus là suy nghĩ rất tự nhiên khi muốn thiết kế một hệ thống đảm bảo scalability. Tuy vậy, nhược điểm của việc sử dụng partition consensus là khó đồng thuận được một thứ tự duy nhất về vent giữa các node trong hệ thống. Do vậy, Google Spanner nói riêng, hoặc các hệ thống phái sinh từ Spanner nói chung, cần sử dụng 2PC và TrueTime API, để đảm bảo strict serializability. Điều này, theo ý tác giả, dẫn đến những khó khăn trong việc thiết kế, và khả năng mở rộng hệ thống.

Từ nhận định trên, tác giả đưa ra thiết kế unified consensus: toàn bộ event đều sẽ được đưa vào một “global event queue”, nói cách khác, chạy trên cùng một thuật toán đồng thuận. Thứ tự toàn cục này có thể đóng vai trò thay thế đồng hồ thời gian trong việc diễn tả khái niệm trước/sau của các sự kiện. Qua đó, thiết kế có thể bỏ qua việc phụ thuộc vào 2PC và TrueTime API, với kết quả là có thể deploy trên các phần cứng thông thường. (commodity hardware)

Ta có thể tham khảo kĩ hơn những nhận định trên qua bài viết sau.

Partitioned consensus and its impact on Spanner’s latency