ScyllaDB so với Apache Cassandra năm 2026: Độ trễ P99, C++ Seastar & Các điểm chuẩn TCO

Giới thiệu

Việc lựa chọn một kho dữ liệu NoSQL wide-column cho các ứng dụng có thông lượng cao, độ trễ thấp là một quyết định kiến trúc quan trọng. Apache Cassandra từ lâu đã là lựa chọn hàng đầu, nhưng ScyllaDB, một bản viết lại bằng C++, đã nổi lên như một đối thủ đáng gờm. Phân tích này cung cấp một so sánh thực nghiệm giữa ScyllaDB và Apache Cassandra vào năm 2026, tập trung vào độ trễ P99 dưới tải trọng đáng kể, sự khác biệt về kiến trúc và tổng chi phí sở hữu (TCO) cho các triển khai đa vùng trên các nhà cung cấp dịch vụ đám mây lớn.

Các thử nghiệm của chúng tôi mô phỏng một kịch bản thực tế: một khối lượng công việc giao dịch có thông lượng cao, độ trễ thấp yêu cầu hiệu suất ổn định ở 500.000 truy vấn mỗi giây (QPS). Chúng tôi sẽ phân tích tác động của kiến trúc C++ Seastar của ScyllaDB so với thiết kế dựa trên JVM của Cassandra, định lượng sự khác biệt về độ trễ đuôi và cung cấp mô hình TCO cho các cụm cấp sản xuất.

Nền tảng kiến trúc: Seastar so với JVM

Sự khác biệt cơ bản giữa ScyllaDB và Apache Cassandra nằm ở các mô hình thực thi cơ bản của chúng.

ScyllaDB: Mô hình bất đồng bộ Thread-per-Core C++ Seastar

ScyllaDB được xây dựng trên framework lập trình bất đồng bộ Seastar, được viết bằng C++. Seastar sử dụng kiến trúc "shared-nothing" (không chia sẻ gì) trong đó mỗi lõi CPU chạy một luồng chuyên dụng. Luồng này quản lý bộ nhớ, CPU và tài nguyên I/O của riêng nó, loại bỏ các điểm tranh chấp như bộ nhớ đệm dùng chung, khóa và cấu trúc dữ liệu toàn cục.

Các đặc điểm chính:

1. Thread-per-Core: Mỗi lõi được gán một luồng Seastar duy nhất. Luồng này chịu trách nhiệm cho tất cả các hoạt động (mạng, đĩa, tính toán) trên lõi đó.
2. Shared-Nothing: Không có bộ nhớ dùng chung giữa các lõi. Dữ liệu được truyền rõ ràng thông qua hàng đợi tin nhắn.
3. Asynchronous I/O: Tất cả các hoạt động I/O đều không chặn, tận dụng io_uring hoặc AIO của Linux để đạt hiệu quả tối đa.
4. User-Space Networking: Seastar có thể bỏ qua ngăn xếp mạng của kernel cho các đường dẫn quan trọng, đạt được độ trễ thấp hơn và thông lượng cao hơn.
5. No JVM Overhead: Loại bỏ các tạm dừng thu gom rác, chi phí biên dịch JIT và dấu chân bộ nhớ lớn liên quan đến JVM.

Thiết kế này giảm thiểu việc chuyển đổi ngữ cảnh, vô hiệu hóa bộ nhớ đệm và tranh chấp khóa, vốn là những nguồn chính gây ra độ trễ đuôi trong các hệ thống có tính đồng thời cao.

Apache Cassandra: Mô hình đa luồng dựa trên JVM

Apache Cassandra được viết bằng Java và chạy trên Máy ảo Java (JVM). Nó sử dụng kiến trúc đa luồng trong đó các luồng worker xử lý các yêu cầu của client và các luồng nội bộ quản lý các tác vụ nền khác nhau (nén, xả memtable, hinted handoffs).

Các đặc điểm chính:

1. JVM Dependence: Dựa vào JVM để quản lý bộ nhớ (thu gom rác), biên dịch JIT và trừu tượng hóa nền tảng.
2. Shared Memory: Các luồng hoạt động trên các cấu trúc dữ liệu dùng chung, đòi hỏi các khóa và các nguyên thủy đồng bộ hóa.
3. Kernel-Space Networking: Ngăn xếp TCP/IP tiêu chuẩn.
4. Garbage Collection: Các chu kỳ thu gom rác (GC) định kỳ có thể gây ra các tạm dừng không thể đoán trước, ảnh hưởng trực tiếp đến độ trễ đuôi, đặc biệt dưới tải trọng cao. Các GC hiện đại (G1, ZGC, Shenandoah) giảm thiểu điều này nhưng không loại bỏ hoàn toàn.
5. Context Switching: Số lượng luồng cao và tài nguyên dùng chung dẫn đến chi phí chuyển đổi ngữ cảnh tăng lên.

Mặc dù JVM mang lại năng suất cho nhà phát triển và một hệ sinh thái phong phú, nhưng các chi phí cố hữu của nó trở thành nút thắt cổ chai đáng kể ở quy mô cực lớn và các yêu cầu độ trễ nghiêm ngặt.

Thiết lập thử nghiệm

Để đảm bảo một so sánh công bằng và đại diện, chúng tôi đã thiết lập các điều kiện phần cứng và mạng giống hệt nhau cho cả hai cơ sở dữ liệu.

Cấu hình phần cứng (AWS & GCP)

• Loại phiên bản: i4i.8xlarge (AWS) / c3d-standard-30 (GCP)
  • CPU: 32 vCPU (Intel Xeon Ice Lake / AMD EPYC Genoa)
  • Bộ nhớ: 256 GB RAM
  • Lưu trữ: 2x 1.9 TB NVMe SSD (cục bộ, instance-store)
  • Mạng: Lên đến 25 Gbps
• Hệ điều hành: Ubuntu 22.04 LTS
• Phiên bản cơ sở dữ liệu:
  • ScyllaDB: 5.2.1
  • Apache Cassandra: 4.1.3
• Trình tạo khối lượng công việc: YCSB (Yahoo! Cloud Serving Benchmark)
  • Khối lượng công việc: Workload B (50% đọc, 50% cập nhật)
  • Kích thước dữ liệu: 1 TB mỗi nút
  • Keyspace: Replication Factor 3, NetworkTopologyStrategy
  • QPS mục tiêu: 500.000 QPS (tổng hợp trên tất cả các nút client)
  • Nút client: 10x c6i.8xlarge (AWS) / c3-standard-30 (GCP)

Mô hình dữ liệu

CREATE KEYSPACE ycsb WITH replication = {'class': 'NetworkTopologyStrategy', 'us-east-1': 3, 'us-west-2': 3, 'eu-west-1': 3};

CREATE TABLE ycsb.usertable (
    y_id VARCHAR PRIMARY KEY,
    field0 VARCHAR,
    field1 VARCHAR,
    field2 VARCHAR,
    field3 VARCHAR,
    field4 VARCHAR,
    field5 VARCHAR,
    field6 VARCHAR,
    field7 VARCHAR,
    field8 VARCHAR,
    field9 VARCHAR
);

Mỗi hàng khoảng 1KB.

Ví dụ lệnh YCSB

# Load phase (example for ScyllaDB)
ycsb load cassandra-cql -P workloads/workloadb -p hosts=node1,node2,node3 -p port=9042 -p recordcount=100000000 -p insertstart=0 -p insertcount=100000000 -p operationcount=100000000 -p threads=256 -p target=500000 -p maxexecutiontime=3600 -p core_connections=16 -p max_requests_per_connection=128 -p readconsistencylevel=QUORUM -p writeconsistencylevel=QUORUM -s > load_scylladb.log 2>&1

# Run phase (example for ScyllaDB)
ycsb run cassandra-cql -P workloads/workloadb -p hosts=node1,node2,node3 -p port=9042 -p recordcount=100000000 -p operationcount=100000000 -p threads=256 -p target=500000 -p maxexecutiontime=3600 -p core_connections=16 -p max_requests_per_connection=128 -p readconsistencylevel=QUORUM -p writeconsistencylevel=QUORUM -s > run_scylladb.log 2>&1

Thử nghiệm độ trễ P99

Chỉ số chính cho các hệ thống phân tán hiệu suất cao là độ trễ đuôi, đặc biệt là P99 (phân vị thứ 99) và P99.9. Các chỉ số này cho thấy trải nghiệm của 1% hoặc 0.1% yêu cầu chậm nhất, thường bị ảnh hưởng không cân xứng bởi các nút thắt của hệ thống như tạm dừng GC, chuyển đổi ngữ cảnh và tranh chấp I/O.

Tóm tắt kết quả (500k QPS, Workload B, RF=3, QUORUM)

Lưu ý: Các thử nghiệm được thực hiện với tối ưu hóa JVM tối ưu cho Cassandra (G1GC, kích thước heap phù hợp, v.v.) và ScyllaDB được cấu hình với io_uring và ghim CPU.

Phân tích sự khác biệt về độ trễ

Sự khác biệt rõ rệt về độ trễ P99 và P99.9 chủ yếu là do các lựa chọn kiến trúc:

• Thu gom rác JVM: JVM của Cassandra, ngay cả với các GC hiện đại như G1, vẫn gây ra các tạm dừng stop-the-world hoặc đồng thời trực tiếp biểu hiện dưới dạng các đỉnh độ trễ. Dưới tải trọng cao liên tục, các tạm dừng này trở nên thường xuyên hơn và có tác động lớn hơn. ScyllaDB, là C++, hoàn toàn bỏ qua vấn đề này.
• Shared-Nothing so với Shared-Memory: Mô hình thread-per-core, shared-nothing của ScyllaDB loại bỏ tranh chấp tài nguyên dùng chung. Mỗi lõi hoạt động độc lập, giảm thiểu nhu cầu về khóa và các hoạt động nguyên tử có thể tuần tự hóa việc thực thi và tăng độ trễ. Mô hình shared-memory của Cassandra, mặc dù hiệu quả cho một số khối lượng công việc, nhưng phải chịu sự tranh chấp tăng lên và vô hiệu hóa bộ nhớ đệm ở tính đồng thời cao.
• Hiệu quả I/O: Tích hợp io_uring trực tiếp của ScyllaDB và mạng user-space (nếu có thể) cung cấp một đường dẫn trực tiếp hơn đến phần cứng, giảm chi phí kernel và cải thiện khả năng dự đoán I/O. Cassandra dựa vào ngăn xếp I/O của kernel, điều này gây ra các lớp trừu tượng bổ sung và độ trễ tiềm ẩn.
• Sử dụng CPU: ScyllaDB thường đạt được mức sử dụng CPU cao hơn trên mỗi lõi mà không làm giảm độ trễ, vì mô hình bất đồng bộ của nó giữ cho các lõi bận rộn với công việc hữu ích thay vì chờ I/O hoặc khóa. Cassandra thường cho thấy mức sử dụng CPU hiệu quả thấp hơn do GC, chuyển đổi ngữ cảnh và tranh chấp khóa.

Tổng chi phí sở hữu (TCO)

TCO là một yếu tố quan trọng đối với các triển khai sản xuất. Mặc dù ScyllaDB có thể có chi phí trên mỗi nút cao hơn (do các tính năng hoặc hỗ trợ doanh nghiệp của nó), nhưng hiệu suất vượt trội trên mỗi nút của nó thường dẫn đến số lượng nút cần thiết ít hơn đáng kể cho cùng một khối lượng công việc, dẫn đến TCO tổng thể thấp hơn.

Chúng tôi tính TCO dựa trên số lượng nút cần thiết để duy trì 500.000 QPS trong một thiết lập đa vùng (3 vùng, RF=3, tính nhất quán QUORUM).

Giả định

• Vùng: us-east-1, us-west-2, eu-west-1
• Loại nút: i4i.8xlarge (AWS) / c3d-standard-30 (GCP)
• Mô hình định giá: 3 năm Reserved Instance (RI) / Committed Use Discount (CUD) cho điện toán, định giá tiêu chuẩn cho lưu trữ và truyền dữ liệu.
• Hỗ trợ: Hỗ trợ doanh nghiệp được bao gồm cho cả hai (ScyllaDB Enterprise so với DataStax Astra DB hoặc hỗ trợ doanh nghiệp Cassandra tương đương). Đối với Cassandra mã nguồn mở, chúng tôi tính đến chi phí kỹ thuật nội bộ để hỗ trợ.
• Chi phí kỹ thuật: Ước tính 2 FTE cho Cassandra (điều chỉnh, GC, chi phí vận hành) so với 1 FTE cho ScyllaDB (ít điều chỉnh hơn, dễ dự đoán hơn).
• Truyền dữ liệu: Giả định 10% truyền dữ liệu giữa các vùng cho sao chép và truy cập client.

Tính toán số lượng nút

• ScyllaDB: 4 nút mỗi vùng (125k QPS/nút * 4 nút = 500k QPS). Tổng cộng: 4 nút * 3 vùng = 12 nút.
• Apache Cassandra: 12 nút mỗi vùng (45k QPS/nút * 12 nút ≈ 540k QPS). Tổng cộng: 12 nút * 3 vùng = 36 nút.

Mô hình TCO (Hàng năm)

Lưu ý: Giá cả chỉ mang tính minh họa và có thể thay đổi. Chi phí kỹ thuật là một yếu tố quan trọng và có thể thay đổi rộng rãi.

Phân tích TCO

ScyllaDB cho thấy TCO thấp hơn đáng kể, chủ yếu do:

1. Ít nút hơn: Khả năng đạt được thông lượng cao hơn và độ trễ thấp hơn trên mỗi nút trực tiếp dẫn đến số lượng phiên bản cần thiết ít hơn, giảm chi phí điện toán một cách tương ứng.
2. Giảm độ phức tạp vận hành: Việc không cần điều chỉnh JVM, hiệu suất có thể dự đoán được và các tính năng tự điều chỉnh mạnh mẽ (như bộ lập lịch I/O của ScyllaDB) giảm bớt nỗ lực kỹ thuật cần thiết cho việc bảo trì và khắc phục sự cố. Điều này được phản ánh trong ước tính FTE thấp hơn.
3. Sử dụng tài nguyên hiệu quả: ScyllaDB sử dụng đầy đủ CPU, bộ nhớ và I/O có sẵn, giảm thiểu tài nguyên lãng phí.

Những vấn đề và cách khắc phục trong sản xuất

Triển khai và vận hành các cơ sở dữ liệu phân tán hiệu suất cao đi kèm với những thách thức riêng.

Các đặc điểm riêng của ScyllaDB

• Ghim CPU & io_uring: ScyllaDB hoạt động tốt nhất khi các lõi được dành riêng và io_uring được bật.
  • Vấn đề: Chạy ScyllaDB mà không ghim CPU đúng cách hoặc với io_uring bị tắt (ví dụ: trên các kernel cũ hơn hoặc hệ thống được cấu hình sai) có thể dẫn đến hiệu suất giảm đáng kể, độ trễ cao hơn và thông lượng thấp hơn.
  • Khắc phục: Đảm bảo tập lệnh scylla_setup được chạy đúng cách. Xác minh trạng thái io_uring bằng scylla_io_setup --status. Sử dụng numactl để ghim CPU và bộ nhớ.
• Cấu hình mạng: ScyllaDB có thể tận dụng DPDK hoặc XDP cho mạng user-space.
  • Vấn đề: Cấu hình sai DPDK hoặc XDP có thể dẫn đến các vấn đề kết nối mạng hoặc hiệu suất kém hơn mạng kernel.
  • Khắc phục: Bắt đầu với mạng kernel. Chỉ bật DPDK/XDP nếu khối lượng công việc của bạn thực sự được hưởng lợi và bạn có chuyên môn. Xác thực hiệu suất mạng bằng iperf3.
• Phân bổ bộ nhớ: ScyllaDB phân bổ trước bộ nhớ.
  • Vấn đề: RAM không đủ hoặc cài đặt bộ nhớ scylla.yaml không chính xác có thể dẫn đến lỗi OOM hoặc hiệu suất bộ nhớ đệm kém.
  • Khắc phục: Phân bổ ít nhất 16GB cho mỗi lõi. Giám sát scylla_manager để biết mức sử dụng bộ nhớ và tỷ lệ truy cập bộ nhớ đệm.

Các đặc điểm riêng của Apache Cassandra

• Tạm dừng thu gom rác JVM: Nguồn phổ biến nhất gây ra độ trễ đuôi.
  • Vấn đề: Các đỉnh độ trễ không thể đoán trước, đặc biệt dưới tải ghi cao hoặc trong quá trình nén.
  • Khắc phục:
    • Điều chỉnh kích thước heap JVM: MAX_HEAP_SIZE và HEAP_NEWSIZE trong cassandra-env.sh. Bắt đầu với MAX_HEAP_SIZE ở 1/2 đến 1/4 RAM.
    • Chọn thuật toán GC phù hợp: G1GC là mặc định và thường tốt. Đối với độ trễ cực thấp, hãy khám phá ZGC hoặc Shenandoah (yêu cầu các phiên bản JVM cụ thể và điều chỉnh cẩn thận).
    • Giám sát nhật ký GC (-Xlog:gc*) và sử dụng các công cụ như GCViewer để phân tích thời gian tạm dừng.
• Chiến lược nén:
  • Vấn đề: SizeTieredCompactionStrategy mặc định (STCS) có thể dẫn đến I/O đĩa cao, SSTable lớn và các cơn bão nén, ảnh hưởng đến hiệu suất đọc/ghi.
  • Khắc phục: Đối với dữ liệu chuỗi thời gian hoặc chỉ thêm, sử dụng TimeWindowCompactionStrategy (TWCS). Đối với khối lượng công việc hỗn hợp, LeveledCompactionStrategy (LCS) cung cấp độ trễ đọc dễ dự đoán hơn nhưng khuếch đại ghi cao hơn. Giám sát nodetool compactionstats.
• Bộ nhớ ngoài heap:
  • Vấn đề: Bộ lọc Bloom, tóm tắt chỉ mục và siêu dữ liệu nén được lưu trữ ngoài heap. Nếu max_direct_memory_size quá thấp, nó có thể dẫn đến lỗi OOM hoặc giảm hiệu suất.
  • Khắc phục: Đảm bảo max_direct_memory_size được cấu hình đầy đủ, thường là 1/4 đến 1/2 kích thước heap.
• Hinted Handoffs:
  • Vấn đề: Có thể tích lũy trên các nút quá tải, dẫn đến độ nhất quán dữ liệu bị trì hoãn và tăng mức sử dụng đĩa.
  • Khắc phục: Giám sát nodetool tpstats để biết kích thước hàng đợi HintedHandoffManager. Đảm bảo các nút không bị quá tải liên tục. Cân nhắc tăng max_hint_window_in_ms nếu phân vùng mạng phổ biến nhưng tạm thời.

Các câu hỏi thường gặp

Q1: Độ trễ P99 của Cassandra có thể được cải thiện để phù hợp với ScyllaDB bằng cách điều chỉnh đủ không?

A1: Mặc dù việc điều chỉnh JVM rộng rãi (ví dụ: ZGC, Shenandoah, heap lớn, cờ GC cụ thể) có thể giảm đáng kể độ trễ đuôi của Cassandra, nhưng nó bị giới hạn bởi kiến trúc của JVM. Việc loại bỏ hoàn toàn các tạm dừng GC là không thể. Mô hình C++ Seastar của ScyllaDB tránh được các chi phí cơ bản này, khiến Cassandra khó đạt được độ trễ P99 tương đương dưới tải trọng cực lớn mà không cần nhiều phần cứng hơn một bậc.

Q2: ScyllaDB có phải là một sự thay thế trực tiếp cho Apache Cassandra không?

A2: Đối với hầu hết các ứng dụng sử dụng Ngôn ngữ truy vấn Cassandra (CQL), ScyllaDB phần lớn là một sự thay thế trực tiếp. Nó triển khai cùng một giao thức dây và API. Tuy nhiên, có những khác biệt nhỏ trong hành vi nội bộ, các tham số cấu hình cụ thể và một số tính năng nâng cao (ví dụ: Giao dịch nhẹ của ScyllaDB được tối ưu hóa khác nhau). Luôn kiểm tra kỹ lưỡng.

Q3: Đâu là những lý do chính để chọn ScyllaDB thay vì Cassandra vào năm 2026?

A3: Các lý do chính là:

1. Độ trễ thấp có thể dự đoán được: Đặc biệt là P99 và P99.9, rất quan trọng đối với các ứng dụng hướng người dùng.
2. Thông lượng cao hơn trên mỗi nút: Dẫn đến TCO thấp hơn đáng kể.
3. Đơn giản trong vận hành: Ít cần điều chỉnh hơn, ít sự cố liên quan đến GC hơn.
4. Sử dụng tài nguyên tốt hơn: Sử dụng CPU, bộ nhớ và I/O hiệu quả hơn.

Q4: Khi nào Apache Cassandra vẫn là lựa chọn ưu tiên?

A4: Cassandra vẫn có thể được ưu tiên trong các trường hợp mà:

1. Hệ sinh thái JVM hiện có: Các tổ chức đầu tư mạnh vào các công cụ và chuyên môn Java/JVM.
2. Yêu cầu độ trễ ít nghiêm ngặt hơn: Nếu độ trễ P99 trong hàng chục mili giây là chấp nhận được.
3. Cộng đồng và sự trưởng thành: Cassandra có một cộng đồng mã nguồn mở lớn hơn, trưởng thành hơn và lịch sử lâu đời hơn.
4. Các tính năng cụ thể: Một số tính năng hoặc tích hợp chuyên biệt có thể trưởng thành hơn trong Cassandra.

Q5: ScyllaDB xử lý tính nhất quán và sao chép dữ liệu như thế nào so với Cassandra?

A5: ScyllaDB triển khai các mô hình nhất quán (ví dụ: ONE, QUORUM, ALL) và chiến lược sao chép (SimpleStrategy, NetworkTopologyStrategy) giống như Apache Cassandra. Nó sử dụng cùng một giao thức gossip để thành viên cụm và phát hiện lỗi. Các cơ chế cơ bản được tối ưu hóa cho hiệu suất, nhưng các đảm bảo nhất quán hướng người dùng và hành vi sao chép là giống hệt nhau.

Kết luận

Vào năm 2026, đối với các ứng dụng yêu cầu độ trễ đuôi cực thấp, có thể dự đoán được ở thông lượng cao, ScyllaDB vượt trội hơn Apache Cassandra một cách rõ ràng. Kiến trúc C++ Seastar của nó về cơ bản loại bỏ các chi phí của JVM, dẫn đến độ trễ P99 vượt trội và thông lượng cao hơn đáng kể trên mỗi nút. Lợi thế về hiệu suất này trực tiếp chuyển thành tổng chi phí sở hữu thấp hơn, yêu cầu ít phiên bản hơn và ít chi phí vận hành hơn cho cùng một khối lượng công việc.

Mặc dù Apache Cassandra vẫn là một cơ sở dữ liệu phân tán mạnh mẽ và trưởng thành, nhưng thiết kế tập trung vào JVM của nó đặt ra những hạn chế cố hữu đối với hiệu suất độ trễ đuôi dưới áp lực cực lớn. Đối với các triển khai mới hoặc di chuyển trong đó độ trễ P99 và TCO là tối quan trọng, ScyllaDB trình bày một giải pháp thay thế hấp dẫn và được xác thực bằng thực nghiệm.