Tại sao Meta phải tự xây dựng RocksDB thay vì dùng database có sẵn

Khi các kỹ sư của Meta đối mặt với quy mô không tưởng của hàng tỷ người dùng tạo ra hàng nghìn tỷ sự kiện mỗi ngày, họ đã đi vào ngõ cụt. Các hệ quản trị cơ sở dữ liệu có sẵn rất mạnh mẽ, nhưng lại không được thiết kế cho nhu cầu ghi log thời gian thực và hạ tầng dữ liệu khổng lồ của Facebook. Đó là lý do RocksDB ra đời: một key-value store embedded hiệu năng cao được thiết kế để chịu được tải ở quy mô Facebook.

Đây là câu chuyện về lý do tại sao Meta tự xây dựng lớp cơ sở dữ liệu của riêng mình, và những bài học mà các kỹ sư có thể rút ra từ quyết định này.

Thách thức cốt lõi: Logging ở quy mô lớn

Hạ tầng của Facebook không chỉ đơn thuần là hiển thị News Feed, mà còn phải tiếp nhận một lượng log khổng lồ từ:

Lượt like, comments, clicks.
Giám sát hệ thống Real-time.
Các sự kiện theo dõi ads.

Các cơ sở dữ liệu quan hệ truyền thống thì quá nặng nề, trong khi các key-value store hiện có lại thiếu các tùy chỉnh về hiệu năng hoặc tiêu tốn quá nhiều bộ nhớ RAM.

Thứ họ cần là một giải pháp có:

Write-heavy optimization: Vì log chủ yếu là append-only, write throughput là yếu tố quan trọng nhất.
Lưu trữ hiệu quả: Dữ liệu chính phải nằm trên SSD, không phải trong RAM.
Embedded: Nó phải là một thư viện được tích hợp trực tiếp vào ứng dụng, chứ không phải một dịch vụ chạy riêng biệt.

Tại sao không phải LevelDB

LevelDB của Google là một điểm khởi đầu tự nhiên. Nó đơn giản, có thể nhúng, và sử dụng kiến trúc LSM-tree (Log-Structured Merge Tree). Tuy nhiên, LevelDB có những hạn chế cố hữu:

Hiệu năng multi-threaded write kém.
Gặp tình trạng nghẽn cổ chai ở quá trình compaction khi chịu tải nặng.
Hạn chế về khả năng cấu hình để tối ưu cho phần cứng.

Meta cần nhiều knobs, nhiều parallelism, và khả năng đảm bảo an toàn dữ liệu.

RocksDB ra đời

Về cơ bản, RocksDB chính là LevelDB được steroids là được viết lại để xử lý các workload khắc nghiệt. Một số tính năng định hình nên RocksDB:

Compaction đa luồng để ngăn chặn tình trạng write stalls.
Column Families để tổ chức dữ liệu hiệu quả hơn.
Block Cache để tăng tốc độ hot reads data.
Backend lưu trữ có thể Pluggable để tối ưu cho SSD và các phần cứng hiện đại.

Để thấy rõ sự khác biệt về triết lý thiết kế, hãy xem qua so sánh cấu trúc mã nguồn một cách sơ lược:

// Cấu trúc LevelDB (tối giản)
leveldb/
├── db/db_impl.cc      // Xử lý ghi đơn luồng
├── table/builder.cc   // Tạo SSTable cơ bản
└── util/env.cc

// Cấu trúc RocksDB (module hóa)
rocksdb/
├── db/db_impl_write.cc // Logic ghi đa luồng
├── table/
│   ├── block_based_table_factory.cc
│   └── two_level_iterator.cc
├── options/
│   └── db_options.cc  // Nhiều tùy chỉnh hơn
└── utilities/
    ├── transactions/
    └── backupable_db.cc

Có thể thấy RocksDB đã module hóa các thành phần quan trọng như compaction và các định dạng table, cho phép kiểm soát và tinh chỉnh ở mức độ sâu hơn nhiều.

Cách RocksDB xử lý một yêu cầu ghi

Luồng ghi dữ liệu trong RocksDB diễn ra như sau:

Request → MemTable (RAM) → Flush → SSTable (disk, immutable) → Compaction → L0 → L1 → ... → Ln

Mỗi bước compaction sẽ hợp nhất các file SSTable nhỏ thành các file lớn hơn, giúp giảm thiểu khuếch đại đọc (read amplification) và dọn dẹp dữ liệu đã xóa.

Những con số ấn tượng

Trong các bài kiểm tra nội bộ của Meta, kết quả rất ấn tượng:

Writes/sec: RocksDB đạt throughput cao hơn tới 100 lần trên SSD so với LevelDB.
Latency: Độ trễ ghi ở p99 giảm khoảng 70% dưới điều kiện tải tương tranh cao.
Space Amplification: Khả năng tùy chỉnh compaction giúp giảm đáng kể dung lượng đĩa bị lãng phí

Bài học

Quyết định của Meta làm nổi bật một sự thật thường bị bỏ qua: đôi khi, hạ tầng ở quy mô lớn đòi hỏi custom tools. Trong khi hầu hết các công ty có thể dựa vào PostgreSQL hoặc Cassandra, Meta cần quyền kiểm soát ở cấp độ phần cứng, luồng xử lý và bộ nhớ đệm mà các giải pháp có sẵn không thể cung cấp. Kể từ khi ra đời, RocksDB đã trở thành một dự án mã nguồn mở được sử dụng rộng rãi, là nền tảng cho các hệ thống tại LinkedIn, Pinterest, Yahoo, và nhiều công ty công nghệ lớn khác.