NewSQL

1. Tổng quan

NewSQL là nhóm cơ sở dữ liệu quan hệ phân tán thế hệ mới được thiết kế để duy trì nguyên vẹn tính nhất quán mạnh, giao dịch ACID và giao diện SQL chuẩn của cơ sở dữ liệu quan hệ (RDBMS), đồng thời đạt được khả năng mở rộng theo chiều ngang (scale-out) và tính sẵn sàng cao mà [[nosql]] đã thể hiện. Thuật ngữ này lần đầu được Matthew Aslett, nhà phân tích của 451 Group, đặt ra vào năm 2011 để chỉ "các CSDL mới nổi mở rộng OLTP mà vẫn giữ các bảo đảm của SQL."

Công nghệ xử lý dữ liệu truyền thống từ lâu đã buộc phải bỏ một trong hai trục đối lập. Một bên là RDBMS một nút đã được kiểm chứng qua nhiều thập niên. Nó cung cấp những vũ khí mạnh mẽ là lược đồ chuẩn hóa, bảo đảm ACID cho giao dịch và SQL khai báo, nhưng khi thông lượng chạm giới hạn của một máy chủ thì không có con đường nào ngoài mở rộng theo chiều dọc (scale-up) — thay bằng máy lớn hơn — vốn vấp phải bức tường chi phí và trần giới hạn. Bên kia là NoSQL xuất hiện cuối những năm 2000. Nó dễ dàng có được khả năng mở rộng theo chiều ngang và tính sẵn sàng cao thông qua sharding, nhưng đổi lại phải nới lỏng tính nhất quán mạnh thành nhất quán cuối cùng (eventual consistency) và từ bỏ phần lớn giao dịch, phép nối và SQL chuẩn trải trên nhiều hàng, nhiều bảng.

NewSQL trực diện thách thức phép nhị phân cũ rằng "muốn có khả năng mở rộng thì phải từ bỏ tính nhất quán." Nói cách khác, bản chất của NewSQL là cung cấp cho lập trình viên ACID và SQL không đổi, trong khi bên dưới che giấu một hệ phân tán tự động phân mảnh, sao chép và đồng bộ dữ liệu. Trong bài luận, NewSQL không được thu hẹp thành chỉ là "RDBMS có khả năng mở rộng", mà phải trình bày theo ba trục: (1) kiến trúc phân tán che giấu sharding và sao chép khỏi ứng dụng một cách trong suốt, (2) cơ chế giao dịch phân tán và đồng thuận giữ được tính tuần tự hóa (serializability) ngay cả trong môi trường phân tán, và (3) việc bảo toàn SQL và ACID vốn phân biệt nó với NoSQL.

A. Bối cảnh ra đời và sự cần thiết

Thứ nhất, nhu cầu bùng nổ về giao dịch quy mô web là động lực quyết định. Các nghiệp vụ xử lý hàng chục nghìn đến hàng trăm nghìn lượt ghi mỗi giây — thương mại điện tử toàn cầu, thanh toán fintech, tính cước trong game quy mô lớn — nhưng đòi hỏi "tuyệt đối không được có đơn trùng lặp hay thanh toán hai lần" ngày càng nhiều. Nhất quán cuối cùng của NoSQL khó bảo đảm tính chính xác của các giao dịch mang tính tài chính này, còn một RDBMS đơn lẻ không kham nổi thông lượng, nên một giải pháp kết hợp ưu điểm của cả hai trở nên cấp thiết.

Thứ hai, đó là phản ứng từ kinh nghiệm vận hành NoSQL. Nhiều doanh nghiệp áp dụng NoSQL để mở rộng, nhưng phải chịu đựng sự phức tạp khi tự triển khai phép nối, tổng hợp và giao dịch ở tầng ứng dụng, cùng những lỗi nhất quán dữ liệu tinh vi do nhất quán cuối cùng gây ra. Phản hồi từ thực địa "nhớ SQL và giao dịch" đã chuyển thành nhu cầu NewSQL.

Thứ ba, sự trưởng thành của phần cứng và công nghệ phân tán đã hiện thực hóa NewSQL. Khi bộ nhớ dung lượng lớn, mạng tốc độ cao, và các thuật toán đồng thuận phân tán đã được kiểm chứng như Paxos và Raft ([[distributed-consensus]]) trở nên phổ biến, thì "mở rộng theo chiều ngang mà vẫn giữ nhất quán mạnh" — vốn từng chỉ là lý thuyết — đã khả thi ở mức thương mại. Bài báo Spanner do Google công bố năm 2012, chứng minh rằng có thể đạt nhất quán ngoài (external consistency) ở quy mô toàn cầu, đã trở thành bước ngoặt quyết định của xu thế này.

2. Kiến trúc tổng thể NewSQL

Hệ thống NewSQL nhìn bên ngoài giống như một RDBMS khổng lồ duy nhất, nhưng bên trong lại có cấu trúc phân tán trong đó nhiều nút không chia sẻ trạng thái (shared-nothing) chia nhỏ dữ liệu để gánh vác. Tư tưởng thiết kế cốt lõi là "tách tầng SQL và tầng lưu trữ." Ứng dụng ném SQL như với một RDBMS thông thường, và bên dưới một engine SQL phân tán xé truy vấn ra nhiều nút để thực thi rồi gom kết quả lại.

graph TB
    APP["Ứng dụng(SQL chuẩn·JDBC)"] --> LB["Cân bằng tải·cổng"]
    LB --> SQL1["Nút SQL(phân tích·tối ưu·thực thi phân tán)"]
    LB --> SQL2["Nút SQL(phân tích·tối ưu·thực thi phân tán)"]
    SQL1 --> TXN["Điều phối giao dịch phân tán(dấu thời gian·2PC)"]
    SQL2 --> TXN
    TXN --> SH1["Shard/Range 1(Leader + bản sao)"]
    TXN --> SH2["Shard/Range 2(Leader + bản sao)"]
    TXN --> SH3["Shard/Range 3(Leader + bản sao)"]
    SH1 -. "Sao chép Raft/Paxos" .- R1["Bản sao A·B"]
    SH2 -. "Sao chép Raft/Paxos" .- R2["Bản sao A·B"]
    META["Quản lý siêu dữ liệu·bố trí(vị trí shard·tái cân bằng)"] --> SH1
    META --> SH2
    META --> SH3

Trong cấu trúc trên, ứng dụng kết nối bằng SQL chuẩn và driver (JDBC, giao thức wire PostgreSQL, v.v.), nên mã vốn dùng một RDBMS sẵn có có thể tái sử dụng gần như nguyên vẹn. Nút SQL phân tích và tối ưu truy vấn đến, nắm từ bộ quản lý siêu dữ liệu dữ liệu nào nằm trên shard nào, rồi chỉ gửi các mảnh truy vấn tới những shard liên quan để thực thi song song. Tầng lưu trữ chia dữ liệu thành shard theo dải khóa (range) hoặc hàm băm, và mỗi shard lại được sao chép đồng bộ tới nhiều bản sao qua Raft/Paxos, nên dù một nút chết thì một leader tự động được bầu và dịch vụ không bị gián đoạn. Điều then chốt là toàn bộ việc phân mảnh, sao chép và phục hồi lỗi này phải vận hành trong suốt (transparent), vô hình đối với ứng dụng — và đây là điểm NewSQL khác biệt dứt khoát so với cách triển khai [[db-sharding]] thủ công trong quá khứ.

A. Giao dịch phân tán và cơ chế đồng thuận

Thách thức khó nhất của NewSQL là giữ ACID ngay cả trong các giao dịch sửa đổi dữ liệu nằm rải trên nhiều shard. Với một nút đơn thì khóa cục bộ và nhật ký là đủ, nhưng khi dữ liệu trải trên nhiều nút thì phải bảo đảm qua mạng tính nguyên tử "tất cả đều commit hoặc tất cả đều rollback". Vì vậy NewSQL thường dùng cấu trúc hai tầng: điều phối commit nguyên tử trên nhiều shard bằng [[two-phase-commit]] (2PC) cổ điển, còn việc sao chép bên trong mỗi shard thì xử lý bằng đồng thuận Raft/Paxos vốn chịu lỗi tốt hơn 2PC.

Một vấn đề tinh tế hơn ở đây là tính cô lập (isolation), đặc biệt là tính tuần tự hóa. Trong môi trường phân tán, đồng hồ của các nút khác nhau bị lệch, khiến khó phán định "giao dịch nào đến trước." Spanner của Google đưa ra TrueTime, một API thời gian giới hạn biên sai số trong vài ms nhờ GPS và đồng hồ nguyên tử, và bằng cách cố ý chờ hết khoảng không chắc chắn tại thời điểm commit (commit-wait), nó đạt được một thứ tự nhất quán toàn cục, tức là nhất quán ngoài. Ngược lại CockroachDB, không cần phần cứng đặc biệt, kết hợp thời gian vật lý và bộ đếm logic bằng Đồng hồ Logic Lai (HLC, Hybrid Logical Clock), và bảo đảm tính tuần tự hóa (SERIALIZABLE) thông qua làm mới dấu thời gian (read refresh) khi đọc. Như vậy "xử lý đồng hồ phân tán ra sao" trở thành lựa chọn kỹ thuật cốt lõi phân định bản sắc của từng sản phẩm NewSQL.

B. Cách hoạt động của sharding và tái cân bằng tự động

Khả năng mở rộng theo chiều ngang của NewSQL sinh ra từ năng lực chia dữ liệu thành các mảnh nhỏ và tự động tái bố trí các mảnh đó theo việc thêm/bớt nút và thay đổi tải. CockroachDB gọi đơn vị này là range, TiDB gọi là region; chúng thường được chia theo đơn vị vài trăm MB, mỗi đơn vị phụ trách một dải khóa nhất định. Khi một mảnh lớn quá thì tách (split), còn khi tải dồn vào một nút thì chuyển (rebalance) sang nút khác — toàn bộ quá trình này hệ thống tự thực hiện.

graph LR
    START["Luồng ghi·dữ liệu tăng"] --> CHK{"Kích thước range/tải vượt ngưỡng?"}
    CHK -->|"Không"| KEEP["Giữ nguyên·đồng bộ bản sao"]
    CHK -->|"Có"| SPLIT["Tách range(split)"]
    SPLIT --> DECIDE{"Mất cân bằng tải giữa các nút?"}
    DECIDE -->|"Có"| MOVE["Chuyển bản sao·tái cân bằng"]
    DECIDE -->|"Không"| PLACE["Giữ bố trí"]
    MOVE --> RAFT["Tái cấu hình nhóm Raft·bầu leader mới"]
    PLACE --> RAFT
    KEEP --> RAFT
    RAFT --> SERVE["Dịch vụ liên tục không gián đoạn"]
    SERVE --> START

Điều quan trọng trong luồng trên là tái cân bằng diễn ra trực tuyến (online), không gián đoạn dịch vụ. Khi chuyển một bản sao, trước tiên một bản sao mới được thêm vào nhóm Raft và cho đuổi kịp dữ liệu rồi mới gỡ bản sao cũ, nên đa số (quorum) luôn được duy trì và việc đọc, ghi không bị cắt. Ví dụ khi lưu lượng tăng đột biến vào Black Friday, thêm vài nút sẽ khiến hệ thống tự động phân tán các range nóng (hot) sang nút mới, nhờ đó thông lượng tăng gần tuyến tính trong vài phút — đây chính là thực thể của tính đàn hồi (elasticity) mà NewSQL đề cao.

3. Các yếu tố kỹ thuật cốt lõi

Các công nghệ NewSQL huy động để đạt mục tiêu "khả năng mở rộng và tính nhất quán cùng lúc" trải trên nhiều tầng, mỗi công nghệ là sự kết tụ của nghiên cứu hệ phân tán phát triển độc lập. Bảng dưới đây chỉ là tóm tắt bổ trợ; "vì sao mỗi công nghệ cần thiết" phải được hiểu bằng văn xuôi.

Tầng	Công nghệ cốt lõi	Vấn đề giải quyết
Lưu trữ·phân mảnh	Sharding Range/Hash, tái cân bằng tự động	Phân tán dữ liệu·tải theo chiều ngang
Sao chép·sẵn sàng	Sao chép đồng bộ Raft/Paxos, chuyển đổi dự phòng tự động	Không gián đoạn khi nút lỗi([[database-replication-high-availability]])
Giao dịch	2PC phân tán, MVCC([[mvcc-snapshot-concurrency-control]])	Tính nguyên tử·đồng thời đa shard
Thời gian·thứ tự	TrueTime, HLC, timestamp oracle	Tính tuần tự hóa phân tán·nhất quán ngoài
Truy vấn	Trình tối ưu SQL phân tán, push-down	Đưa SQL chuẩn vào thực thi song song theo nút

Đặc biệt, MVCC (điều khiển đồng thời đa phiên bản) là nền móng ẩn của hiệu năng NewSQL. Bằng cách quản lý nhiều phiên bản của mỗi hàng theo dấu thời gian để việc đọc không chặn việc ghi, một lượt ghi OLTP ngắn vẫn có thể trôi chảy không trễ ngay cả khi một truy vấn phân tích dài đang chạy. Ngoài ra, tối ưu push-down — đẩy các phép lọc, tổng hợp xuống nút lưu trữ nơi có dữ liệu — giảm lượng dữ liệu phải chuyển qua mạng, và là yếu tố quyết định chi phối hiệu năng truy vấn trong môi trường phân tán.

4. Phân loại NewSQL

Trong bài báo chung năm 2016, Andy Pavlo và Matthew Aslett đã phân loại NewSQL thành ba nhánh theo phương thức triển khai, và khung này đến nay vẫn là tiêu chí mô tả hữu dụng.

Thứ nhất, kiến trúc hoàn toàn mới (New Architectures). Các engine được thiết kế mới từ nền tảng trên tiền đề phân tán như Spanner, CockroachDB, TiDB, VoltDB, YugabyteDB, với cấu trúc shared-nothing và giao dịch phân tán gốc. Đây là NewSQL thuần túy nhất, mạnh nhất ở cả khả năng mở rộng lẫn tính nhất quán, nhưng độ phức tạp triển khai và rủi ro về độ trưởng thành lớn.

Thứ hai, middleware sharding trong suốt (Transparent Sharding Middleware). Các phương thức như Vitess (dựa trên MySQL, do YouTube phát triển) hay Citus (phần mở rộng PostgreSQL) đặt một tầng sharding trước nhiều thực thể RDBMS đơn lẻ sẵn có, để ứng dụng thấy chúng như một DB duy nhất. Nhờ tái dùng engine RDBMS đã kiểm chứng nên ổn định, nhưng độ mạnh của giao dịch phân tán không bằng kiến trúc mới.

Thứ ba, DBaaS (Database-as-a-Service). Các dạng như Amazon Aurora, Google AlloyDB, trong đó nhà cung cấp đám mây tách lưu trữ và điện toán rồi cung cấp dưới dạng dịch vụ quản lý, chuyển gánh nặng vận hành cho nhà cung cấp trong khi hưởng mở rộng tự động.

5. So sánh RDBMS·NoSQL·NewSQL

Sự khác biệt giữa ba nhóm phải được hiểu không phải như một danh sách tính năng đơn thuần, mà như sự khác biệt triết lý thiết kế về mỗi bên cố giữ gì bằng cách hy sinh gì.

Phân loại	RDBMS truyền thống	NoSQL	NewSQL
Cách mở rộng	Dọc(scale-up)	Ngang(scale-out)	Ngang(scale-out)
Tính nhất quán	Nhất quán mạnh(ACID)	Nhất quán cuối cùng(BASE)	Nhất quán mạnh(ACID)
Truy vấn	SQL chuẩn·phép nối	Hạn chế·lấy API làm trung tâm	SQL chuẩn·phép nối
Giao dịch	Hỗ trợ đầy đủ	Hạn chế(khóa đơn)	Hỗ trợ giao dịch phân tán
Tiêu biểu	Oracle, MySQL	MongoDB, Cassandra	Spanner, CockroachDB, TiDB

Nếu RDBMS hy sinh khả năng mở rộng để giữ tính nhất quán và SQL, thì NoSQL hy sinh tính nhất quán và SQL để có khả năng mở rộng và tính sẵn sàng. NewSQL "giữ cả hai, nhưng trả chi phí đó bằng đồng thuận phân tán và độ trễ mạng" — tức là không miễn phí; dưới ràng buộc của định lý CAP, nó mua tính nhất quán bằng cách trả giá bằng độ trễ và chi phí sao chép theo địa lý. Do đó khẳng định "NewSQL vượt trội vô điều kiện" là sai, và phải luôn nêu kèm sự đánh đổi là độ trễ ghi tăng trong môi trường phân tán theo vùng.

6. So sánh các triển khai

Đi xuống sản phẩm cụ thể, khác biệt trong lựa chọn thiết kế hiện rõ. Google Spanner lấy phần cứng TrueTime (GPS·đồng hồ nguyên tử) làm tiền đề để đạt nhất quán ngoài quy mô toàn cầu, chống đỡ các giao dịch quy mô hàng nghìn tỷ won của hệ thống quảng cáo Google (F1) — song bị ràng buộc vào hạ tầng đặc biệt và trên thực tế chỉ dành cho Google Cloud. CockroachDB lấy cảm hứng từ Spanner nhưng triển khai tính tuần tự hóa bằng HLC trên phần cứng phổ thông nên chạy được ở bất cứ đâu, và nâng tính khả chuyển nhờ tương thích wire PostgreSQL. TiDB tách tầng SQL tương thích MySQL khỏi TiKV, một KV phân tán dựa trên Raft, và thêm engine lưu trữ cột TiFlash để bao quát cả [[htap]] — điểm đặc trưng là xử lý cả OLTP và phân tích thời gian thực trên một bản dữ liệu duy nhất. Tại Hàn Quốc, việc áp dụng TiDB và CockroachDB cũng đang tăng trong các lĩnh vực thương mại điện tử, game và tài chính quy mô lớn, với các báo cáo liên tục về việc vận hành hàng trăm TB dữ liệu như một DB logic duy nhất đồng thời giảm mạnh gánh nặng vận hành sharding.

7. Chuyên sâu: Định nghĩa lại và hội tụ thành "Distributed SQL"

Gần đây ngành ưa chuộng tên gọi "SQL phân tán (Distributed SQL)" thay cho thuật ngữ 'NewSQL' vốn khá mơ hồ. Đây là phạm trù hẹp và rõ ràng hơn, chỉ "DB được thiết kế từ nền tảng trên tiền đề phân tán và cung cấp SQL chuẩn, nhất quán mạnh", mà CockroachDB, YugabyteDB, TiDB, Spanner đang tự tái định vị vào. Đó là nỗ lực phân biệt với middleware sharding đơn giản hay các sản phẩm OLTP in-memory từng được gộp vào NewSQL thuở đầu.

Xu thế thứ hai là tách lưu trữ-điện toán và chuyển sang serverless. Các mô hình tính phí tự động co về 0 và giãn ra theo mức sử dụng như CockroachDB Serverless, TiDB Serverless đã xuất hiện, nhờ đó cả dịch vụ quy mô vừa và nhỏ cũng có thể hưởng lợi ích của DB phân tán mà không gánh chi phí ban đầu. Xu thế thứ ba là hội tụ với khối lượng công việc HTAP và AI. Đó là hướng tích hợp lưu trữ hàng và lưu trữ cột trong một hệ thống để cùng cung cấp phân tích thời gian thực và tìm kiếm vector trên dữ liệu vận hành, khiến ranh giới giữa giao dịch, phân tích và AI mờ dần bên trong cơ sở dữ liệu. Dẫu vậy, SQL phân tán vẫn có độ trễ ghi lớn hơn RDBMS một nút và đòi hỏi nhiều chuyên môn vận hành, nên điểm bất biến là nó không phải giải pháp vạn năng phù hợp cho mọi nghiệp vụ.

8. Điểm cân nhắc và hàm ý

Thứ nhất, áp dụng chọn lọc theo mức độ yêu cầu nhất quán là cốt lõi. NewSQL phù hợp cho OLTP cốt lõi vừa cần nhất quán mạnh vừa cần khả năng mở rộng như thanh toán và tồn kho toàn cầu, nhưng nếu cưỡng ép chuyển các nghiệp vụ mà một vùng đơn lẻ vẫn đủ sang SQL phân tán thì chỉ làm tăng độ trễ ghi và độ phức tạp vận hành. Phải trước tiên kiểm chứng "khả năng mở rộng có thực sự vượt giới hạn của một RDBMS đơn lẻ không" rồi mới quyết định áp dụng.

Thứ hai, sự đánh đổi giữa độ trễ-tính nhất quán-phân tán theo địa lý phải được thiết kế một cách định lượng. Sao chép đồng bộ đa vùng có thể làm tăng độ trễ ghi hàng chục ms trở lên do chặng khứ hồi mạng, nên năng lực thiết kế kiểm soát độ trễ bằng chính sách bố trí (phân vùng theo khu vực) khai thác tính cục bộ (locality) của dữ liệu sẽ quyết định thành bại.

Thứ ba, độ trưởng thành vận hành và rủi ro hệ sinh thái phải được cân nhắc. NewSQL kiến trúc mới còn tương đối non trẻ, nên công cụ và nhân lực lành nghề cho xử lý sự cố, sao lưu và giám sát chưa dồi dào bằng RDBMS truyền thống. Qua PoC, phải kiểm chứng các kịch bản tiêm lỗi (chaos) cùng lộ trình nâng cấp, di trú, và cũng phải rà soát khả năng khóa nhà cung cấp (lock-in) và khả năng thay đổi giấy phép mã nguồn mở.

Thứ tư, chiến lược chuyển đổi và cùng tồn tại với tài sản hiện có là cần thiết. Thay vì thay thế toàn bộ, thực tế hơn là di trú dần từ các nghiệp vụ nghẽn cổ chai về mở rộng theo phương thức Strangler, và thiết kế chuyển đổi không gián đoạn bằng di trú dữ liệu và đồng bộ dựa trên CDC. Vì SQL chuẩn và tương thích PostgreSQL hạ mạnh chi phí khả chuyển, nên khi chọn sản phẩm phải lấy độ hoàn thiện của giao thức tương thích và công cụ di trú làm hạng mục đánh giá cốt lõi.

Thứ năm, theo góc nhìn triển vọng của Kỹ sư chuyên nghiệp, NewSQL/SQL phân tán đang dần xác lập vị thế là tầng dữ liệu mặc định của các dịch vụ cloud-native, đa vùng, và được dự báo sẽ tiến hóa thành nền tảng dữ liệu tích hợp xử lý "giao dịch, phân tích và trí tuệ trên một bản dữ liệu duy nhất" khi hấp thụ các năng lực HTAP, vector và AI.

Tài liệu tham khảo

Andrew Pavlo, Matthew Aslett, "What's Really New with NewSQL?" ACM SIGMOD Record (2016): https://db.cs.cmu.edu/papers/2016/pavlo-newsql-sigmodrec2016.pdf
Google, "Spanner: Google's Globally-Distributed Database" (OSDI 2012): https://research.google/pubs/pub39966/
CockroachDB Architecture — Transaction Layer: https://www.cockroachlabs.com/docs/stable/architecture/transaction-layer
Tài liệu PingCAP TiDB Architecture: https://docs.pingcap.com/tidb/stable/tidb-architecture
Wikipedia, "Distributed SQL": https://en.wikipedia.org/wiki/Distributed_SQL

Tóm tắt một câu: NewSQL (SQL phân tán) là CSDL quan hệ phân tán, thông qua sharding, sao chép Raft, giao dịch phân tán và đồng hồ phân tán dựa trên TrueTime/HLC, giữ được ACID·SQL chuẩn của RDBMS đồng thời đạt khả năng mở rộng theo chiều ngang của NoSQL; điều then chốt là hiểu sự đánh đổi giữa độ trễ·tính nhất quán·độ phức tạp vận hành và áp dụng chọn lọc cho OLTP cốt lõi.