Building a New Rust Driver for ScyllaDB's DynamoDB API – with 58% More Throughput

ScyllaDB · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài nhà cung cấp; dự án sinh viên (Đại học Warsaw) hợp tác với ScyllaDB. Benchmark do chính họ chạy trên cụm nhỏ (3 node i3.xlarge); mọi con số là theo ScyllaDB.

Bối cảnh

• Alternator là API tương thích DynamoDB của ScyllaDB. Dev Rust trước đó dùng SDK DynamoDB chuẩn của AWS. SDK đó thiết kế cho dịch vụ managed sau một endpoint duy nhất (AWS tự định tuyến phía sau), nên khi trỏ vào ScyllaDB thì mọi request rơi vào một node: node đó quá tải và thành điểm hỏng chung, các node khác ngồi chơi.
• Driver cho Java, Python, Go đã giải quyết cùng một cách: giữ API của SDK, học topology cụm ở dưới, định tuyến mỗi request tới một node phục vụ được. Rust là ngôn ngữ tiếp theo.

Thay đổi chính

• Bọc SDK chính thức (aws-sdk-dynamodb) và chèn logic qua Interceptor của SDK, nên ứng dụng chỉ đổi crate và builder, phần còn lại giữ nguyên; có thể dùng song song hai driver.
• Cân tải phía client trong phạm vi cấu hình (cluster/datacenter/rack), hai chiến lược:
  • Round-robin (mặc định): xoay vòng các node sống.
  • Key affinity: mỗi partition key luôn đi tới cùng một coordinator. Khuyến nghị cho workload nặng LWT (lightweight transaction cần đồng thuận giữa replica), vì cùng coordinator thì ít phối hợp và ít tranh chấp hơn.
• Bỏ header thừa mà SDK AWS thêm cho môi trường AWS: giảm 45% lượng header gửi đi. Nén request (gzip/zlib) theo ngưỡng kích thước body, tắt mặc định.
• Latte (công cụ benchmark Rust của ScyllaDB, kịch bản viết bằng Rune) được thêm hỗ trợ Alternator bằng conditional compilation (Cargo feature) để không phải refactor gần như mọi file nếu dùng trait; tách logic cql và alternator thành hai binary.

Kết quả (theo ScyllaDB)

• Throughput tối đa: driver mới làm bão hoà cả cụm với cả hai chiến lược, cao hơn SDK AWS khoảng 58%. Ghi cuối cùng vẫn chạm mọi node (RF=3), nhưng đọc thì coordinator tự phục vụ được, nên dồn vào một node bỏ phí phần lớn cụm.
• Latency khi giới hạn 30.000 ops/s: mức đủ làm một node quá tải nhưng chưa làm cả cụm quá tải. SDK AWS tăng latency mạnh, driver mới giữ thấp, nhất là p99.
• Hot partition với LWT (99% request vào 10% key của một nhóm nhỏ partition): round-robin tệ hơn cả SDK AWS vì rải request của cùng một key nóng qua nhiều coordinator, tăng tranh chấp. Key affinity tốt nhất.
• Benchmark công cụ benchmark: YCSB chỉ đạt khoảng 78% throughput của node ScyllaDB vì nghẽn CPU ở máy tải, trong khi Latte bão hoà được với khoảng nửa CPU. Khi đo latency có tính coordinated omission (thời gian từ lúc request đáng lẽ bắt đầu), trung bình của YCSB cao gấp hơn 6 lần, p99 gấp 160 lần Latte.

Vì sao

• SDK của dịch vụ managed mặc định rằng phía server tự cân tải; khi đổi sang DB tự vận hành tương thích API, giả định đó không còn đúng và client phải biết topology (Chọn database theo workload).
• Với key nóng cần đồng thuận, rải đều tải lại làm tranh chấp tệ hơn; đôi khi "dồn về một chỗ" mới là đúng (Hot partition và thundering herd).

Bài học cho SWE

• Tương thích API không có nghĩa tương đương hiệu năng: kiểm cả các giả định ngầm của client (một endpoint, header, retry).
• Chọn chiến lược định tuyến theo workload: round-robin cho tải đều, affinity theo key cho giao dịch tranh chấp trên key nóng.
• Trước khi kết luận DB là nút thắt, kiểm máy sinh tải: công cụ benchmark nghẽn CPU sẽ báo sai cả throughput lẫn latency. Đo latency phải tính coordinated omission.
• Bọc SDK chính thức thay vì viết lại giúp migrate rẻ (đổi import và cấu hình).

Liên quan

• ScyllaDB 2026 · Expedia 2018 · Medium 2015
• Yahoo 2015
• Hot partition và thundering herd · Chọn database theo workload