RocksDB là gì? Kho khóa-giá trị nhúng

RocksDB là gì?

RocksDB là kho khóa-giá trị bền vững, có thể nhúng và được tối ưu hóa cho lưu trữ tốc độ cao. Nó nhận khóa và giá trị dưới dạng các mảng byte tùy ý, duy trì thứ tự sắp xếp và lưu trữ bền vững trên đĩa.

Điều quan trọng nhất cần hiểu ngay từ đầu là RocksDB là một thư viện chứ không phải máy chủ. Không có tiến trình để kết nối, không có cổng để mở và không có ngôn ngữ truy vấn để học.

RocksDB tích hợp với ứng dụng và chạy bên trong tiến trình của ứng dụng đó, đọc và ghi tệp trên đĩa cục bộ. Đây là yếu tố giúp RocksDB hoạt động nhanh—không có bước truyền qua mạng giữa mã ứng dụng và dữ liệu mà mã đó xử lý. RocksDB tối giản vì chủ đích để việc sao chép, phân mảnh và truy vấn cho hệ thống được xây dựng bên trên đảm nhiệm.

Nói đơn giản, RocksDB là một công cụ lưu trữ—thành phần cốt lõi để xây dựng các cơ sở dữ liệu như TiDB và YugabyteDB.

RocksDB có giống LevelDB không?

Không, nhưng chúng bắt nguồn từ cùng một cơ sở mã. RocksDB ra đời vào năm 2012 dưới dạng một nhánh của LevelDB, kho khóa-giá trị gọn nhẹ do Jeff Dean và Sanjay Ghemawat viết tại Google.

LevelDB được xây dựng cho các môi trường quy mô nhỏ (ví dụ: backend IndexedDB của trình duyệt hoặc một thiết bị nhúng đơn lẻ), với nhiều quyết định thiết kế phù hợp cho các môi trường này, bao gồm nén dữ liệu đơn luồng, sử dụng bộ nhớ thận trọng và ít cần tinh chỉnh.

Các kỹ sư tại Facebook, nay là Meta, đã sử dụng nền tảng đó và xây dựng lại cho khối lượng công việc máy chủ. Mục tiêu là khai thác tối đa phần cứng hiện đại trong khi xử lý các tập dữ liệu lớn hơn bộ nhớ rất nhiều dưới áp lực ghi liên tục.

RocksDB được mở mã nguồn vào năm 2013 và kể từ đó đã khác biệt đáng kể so với LevelDB, với các tính năng như nén dữ liệu đa luồng, họ cột, giao dịch, sao lưu, toán tử hợp nhất, các kiểu nén dữ liệu có thể thay thế và một danh sách tùy chọn tinh chỉnh nổi tiếng là rất dài.

LevelDB và RocksDB có nhiều nét tương đồng, nhưng việc coi chúng là hai công cụ có thể thay thế lẫn nhau đã không còn hợp lý từ một thập kỷ trước.

RocksDB hoạt động như thế nào?

RocksDB được xây dựng trên cây hợp nhất có cấu trúc nhật ký (cây LSM), một cấu trúc dữ liệu đánh đổi sự đơn giản khi đọc để lấy thông lượng ghi.

Về cơ bản, các thao tác ghi đến được đưa vào một bộ đệm trong bộ nhớ gọi là memtable. Đồng thời, các thao tác ghi được nối thêm vào nhật ký ghi trước trên đĩa để đảm bảo độ bền dữ liệu.

Khi memtable đầy, nó được đóng băng và đẩy xuống đĩa dưới dạng một tệp bất biến đã sắp xếp, gọi là Bảng Chuỗi Đã Sắp xếp (SST). Các tệp SST tích lũy thành một hệ thống phân cấp theo tầng, còn một tiến trình nền gọi là nén dữ liệu liên tục hợp nhất chúng, loại bỏ các giá trị đã bị ghi đè và các khóa đã bị xóa để duy trì một cấu trúc gọn gàng, có thứ tự và bền vững.

Thao tác đọc kiểm tra memtable trước, sau đó lần lượt đi xuống các tầng tệp SST. Bộ lọc Bloom cho phép RocksDB bỏ qua những tệp chắc chắn không thể chứa khóa, còn bộ nhớ đệm khối giữ dữ liệu được truy cập thường xuyên trong bộ nhớ, nhờ đó hầu hết thao tác đọc chỉ cần chạm đến một hoặc hai tệp.

Cây LSM khác cây B như thế nào?

Cây B, cấu trúc được hầu hết cơ sở dữ liệu truyền thống sử dụng, cập nhật dữ liệu tại chỗ, nghĩa là các thao tác ghi ngẫu nhiên nằm rải rác trên đĩa. Cây LSM nối thêm và xử lý theo lô, tạo ra các thao tác ghi tuần tự lớn—đúng với nhu cầu của SSD và những khối lượng công việc có tốc độ nạp dữ liệu cao. Sự đánh đổi ở đây là giá trị hiện tại của một khóa có thể nằm trên nhiều tệp, vì vậy cần nén dữ liệu, bộ lọc Bloom và bộ nhớ đệm để kiểm soát sự đánh đổi đó.

Mọi quyết định thiết kế trong cây LSM cuối cùng đều phải cân bằng ba áp lực:

• Khuếch đại ghi
• Khuếch đại đọc
• Khuếch đại không gian

Cải thiện bất kỳ hai yếu tố nào thường sẽ làm yếu tố thứ ba trở nên tệ hơn.

Tam giác này là mô hình tư duy quan trọng nhất để hiểu cách tinh chỉnh RocksDB.

RocksDB được dùng để làm gì?

RocksDB được sử dụng ở bất cứ đâu ứng dụng cần kho khóa-giá trị có thứ tự, tốc độ cao và bền vững trên đĩa cục bộ mà không phải chịu chi phí vận hành một máy chủ cơ sở dữ liệu riêng. Các ví dụ cụ thể giúp làm rõ mô hình này hơn là những danh mục chung chung.

Kafka Streams lưu trạng thái của từng tác vụ xử lý—các phép tổng hợp đang chạy, phép nối và phép tính theo cửa sổ—trong một kho RocksDB cục bộ. Nhờ đó, trạng thái có thể lớn hơn bộ nhớ và vẫn tồn tại sau khi khởi động lại mà không cần thêm một vòng truyền qua mạng cho mỗi lần tra cứu.

ZippyDB của Meta bao bọc RocksDB bằng một lớp sao chép, cơ chế quản lý phân mảnh và các dịch vụ cấu hình để cung cấp một kho khóa-giá trị phân tán được quản lý hoàn toàn, với sự phân công rõ ràng: RocksDB đảm nhiệm lưu trữ, còn mọi thành phần mang chức năng của máy chủ đều được xây dựng xung quanh nó.

Lớp lưu trữ của TiDB chạy RocksDB trên mọi node để làm công cụ nền tảng cho cơ sở dữ liệu SQL phân tán, mã hóa cấu trúc bảng vào các tiền tố khóa để việc quét một bảng trở thành một lần đọc liên tục trên các khóa đã sắp xếp.

Mọi validator Solana dựa trên Agave đều ghi sổ cái vào RocksDB, sử dụng slot làm khóa để dữ liệu sổ cái liên tiếp nằm liền kề nhau trên đĩa.

Hai ví dụ cuối đặc biệt thú vị vì khóa được lưu theo thứ tự sắp xếp—theo byte theo mặc định hoặc theo một bộ so sánh tùy chỉnh—giúp quét phạm vi và tra cứu theo tiền tố trở nên hiệu quả.

Một phần đáng kể trong thiết kế schema thực tế của các hệ thống dùng RocksDB làm nền tảng tập trung vào việc khai thác thứ tự này.

Ai sử dụng RocksDB?

Ngoài các hệ thống kể trên, RocksDB là nền tảng cho mọi hệ thống cần một công cụ lưu trữ nhúng, đã được kiểm chứng thực tế và tối ưu cho thao tác ghi. Các đội ngũ chọn RocksDB vì họ được thừa hưởng một thập kỷ Meta củng cố nó trong môi trường production thay vì phải tự viết từ đầu.

Đáng chú ý:

• Kafka Streams sử dụng RocksDB làm công cụ mặc định cho các kho trạng thái
• Apache Flink cung cấp một backend trạng thái RocksDB cho trạng thái có điểm kiểm tra quá lớn để lưu trong bộ nhớ
• MyRocks nhúng RocksDB làm công cụ lưu trữ MySQL, được phát triển tại Meta để giảm dung lượng lưu trữ cho một số cụm MySQL lớn nhất hiện có
• Lớp lưu trữ của TiDB, TiKV, sử dụng RocksDB với các phiên bản riêng biệt cho nhật ký Raft và dữ liệu khóa-giá trị
• Kho tài liệu của YugabyteDB, DocDB, sử dụng RocksDB
• BlueStore của Ceph sử dụng RocksDB cho metadata của kho đối tượng
• ArangoDB đã sử dụng RocksDB làm công cụ lưu trữ mặc định kể từ phiên bản 3.4 và là công cụ duy nhất kể từ phiên bản 3.7

RocksDB chủ yếu được sử dụng cho khối lượng công việc ghi nhiều, lớn hơn bộ nhớ trên SSD—điểm mà chúng ta sẽ quay lại ở phần sau của bài viết.

Solana sử dụng RocksDB như thế nào?

Solana là blockchain Proof of Stake có hiệu năng cao và độ trễ thấp, nổi tiếng nhờ tập trung vào tốc độ, hiệu quả và các ứng dụng tiêu dùng. Sổ cái của Solana nằm trong RocksDB. Client validator Agave lưu sổ cái trong Blockstore, một thành phần chứa cơ sở dữ liệu RocksDB được chia thành các không gian khóa độc lập và có thể tinh chỉnh.

Các họ cột riêng biệt lưu dữ liệu shred và mã sửa lỗi shred (tức các đơn vị dữ liệu sổ cái thô khi chúng đến qua mạng), trạng thái giao dịch, chỉ mục từ địa chỉ đến chữ ký và nhiều metadata khác.

Mô hình ghi của validator cực đoan so với hầu hết khối lượng công việc cơ sở dữ liệu. Cụ thể, validator phải liên tục tiếp nhận shred, được đánh khóa bằng số slot tăng gần như đơn điệu, ở tốc độ tối đa của đường truyền mạng, mãi mãi. Một kho lưu trữ sổ cái chưa cắt tỉa có dung lượng vượt xa hàng trăm terabyte và tăng thêm ít nhất hàng chục terabyte mỗi năm.

Với cơ chế nén dữ liệu theo tầng, các họ cột shred tạo ra lượng công việc nén dữ liệu nền lớn đến mức validator bắt đầu gặp tình trạng đình trệ ghi. Đây là cơ chế tích hợp của RocksDB nhằm làm chậm quá trình tiếp nhận dữ liệu khi nén dữ liệu không theo kịp.

Khoảng năm 2021, các họ cột shred được chuyển sang nén dữ liệu FIFO, một kiểu tối giản chỉ xóa tệp cũ nhất khi đạt giới hạn kích thước. FIFO thường không an toàn cho các khối lượng công việc thông thường. Tuy nhiên, vì khóa shred đến theo thứ tự slot gần như đơn điệu, validator có thể xóa tệp cũ nhất vì tệp đó chứa các slot cũ nhất. Cách này gần như hoàn toàn khớp kiểu nén dữ liệu với đặc điểm của khối lượng công việc.

Các bước tối ưu hóa nén dữ liệu theo tầng sau đó đã giảm mức khuếch đại I/O đến mức FIFO không còn mang lại lợi thế nào. Vì vậy, luồng FIFO đã bị ngừng hỗ trợ vào tháng 6 năm 2024 và bị xóa vào tháng 11 cùng năm.

Firedancer, client validator Solana của Jump Crypto được viết bằng C, loại bỏ hoàn toàn RocksDB để sử dụng một lớp lưu trữ nội bộ được xây dựng chuyên biệt.

Liệu một công cụ lưu trữ được xây dựng từ đầu có thể vượt qua một thập kỷ củng cố và tinh chỉnh RocksDB hay không vẫn là một câu hỏi mở thú vị trong lĩnh vực kỹ thuật validator.

Khi nào RocksDB không phải là công cụ phù hợp?

RocksDB không phù hợp trong nhiều trường hợp hơn mức độ phổ biến của nó gợi ý. Phạm vi tinh chỉnh cực kỳ rộng, với hàng trăm tùy chọn có sự tương tác khó nhận thấy, vì vậy cấu hình sai là kết quả thường gặp chứ không phải ngoại lệ.

Tệ hơn nữa, các thiết lập mặc định của RocksDB chỉ hợp lý chứ không tối ưu. Vì vậy, nhà phát triển cần hiểu những đánh đổi về khuếch đại đã nêu ở trên để đạt được mức cải thiện hiệu năng thực sự. Hoạt động nạp dữ liệu nặng kéo dài có thể vượt quá tốc độ nén dữ liệu nền, gây đình trệ ghi—thường xảy ra đúng lúc hệ thống bận rộn nhất.

Ngoài ra, RocksDB là một thư viện chứ không phải máy chủ. Mọi thứ mà một máy chủ cơ sở dữ liệu thông thường cung cấp (ví dụ: sao chép, phân mảnh, sao lưu, kiểm soát truy cập, lớp truy vấn và công cụ vận hành) đều phải được tự xây dựng.

Đặc điểm của khối lượng công việc cũng có ảnh hưởng rất lớn.

RocksDB là một công cụ hướng hàng, chuyên tra cứu điểm và quét phạm vi. Khối lượng công việc phân tích cần quét những vùng dữ liệu rộng và tổng hợp trên nhiều cột sẽ phù hợp hơn với một kho dạng cột như ClickHouse.

Không điều nào trong số này là lý do để tránh RocksDB. Thay vào đó, đây là lý do để lựa chọn nó một cách có chủ đích. Tại Helius, chúng tôi đã trực tiếp đánh giá những rủi ro này khi thiết kế lại lớp lưu trữ dài hạn và vẫn chọn RocksDB, vì khối lượng công việc có đúng đặc điểm mà RocksDB được xây dựng để xử lý: tra cứu điểm và quét phạm vi hẹp trên một tập dữ liệu lớn với lượng dữ liệu nối thêm cao.

Kết luận

RocksDB là kho khóa-giá trị bền vững, có thứ tự và có thể nhúng, đánh đổi sự tiện lợi trong vận hành để lấy hiệu năng thuần túy trên đĩa cục bộ. RocksDB bắt nguồn từ LevelDB, được Meta củng cố cho SSD và máy đa lõi, và hiện nằm bên trong nhiều hệ thống trên toàn thế giới—từ bộ xử lý luồng và cơ sở dữ liệu SQL phân tán đến cụm lưu trữ và sổ cái của Solana.

Nếu việc xây dựng các hệ thống RocksDB hiệu năng cao ở quy mô lớn khiến bạn hào hứng, hãy tham gia xây dựng cùng chúng tôi.

Solana đang chạy đua để trở thành lớp quyết toán cho tài chính toàn cầu, và cơ sở hạ tầng bên dưới vận hành bằng chính những cơ chế mà loạt bài này mô tả. Hãy giải quyết những bài toán hệ thống khó trên một số phần cứng tốt nhất có thể mua được, ở quy mô toàn cầu.

Chúng tôi đang tuyển dụng cho nhiều vị trí trong đội ngũ kỹ thuật. Xem tất cả vị trí đang tuyển tại helius.dev/careers.