Perplexity tự phát triển CobbleDB bằng Rust, thay thế DynamoDB và giảm độ trễ truy vấn gấp 5 lần

Perplexity vừa công bố quá trình chuyển đổi hạ tầng tìm kiếm của mình khỏi Amazon DynamoDB sang CobbleDB — một kho lưu trữ khóa-giá trị (key-value store) do chính công ty phát triển bằng ngôn ngữ Rust. Đây là bước đi cho thấy xu hướng ngày càng rõ của các công ty công nghệ lớn: tự xây dựng giải pháp hạ tầng thay vì phụ thuộc hoàn toàn vào dịch vụ đám mây của bên thứ ba.

Vì sao Perplexity rời bỏ DynamoDB?

DynamoDB là dịch vụ cơ sở dữ liệu NoSQL được quản lý hoàn toàn bởi AWS, nổi tiếng với khả năng mở rộng linh hoạt và độ ổn định cao. Tuy nhiên, với đặc thù của một công cụ tìm kiếm AI, Perplexity phải xử lý những lô tài liệu (document batch) có kích thước rất lớn.

Khi khối lượng dữ liệu và truy vấn tăng vọt, mô hình của DynamoDB bắt đầu bộc lộ hạn chế:

• Độ trễ tăng khi phải xử lý các lô tài liệu lớn
• Chi phí lưu trữ và truy vấn leo thang theo quy mô
• Khó tối ưu cho các mẫu truy cập đặc thù của hệ thống tìm kiếm

Đây là bài toán quen thuộc mà nhiều startup gặp phải khi mở rộng: giải pháp tổng quát của nhà cung cấp đám mây không còn phù hợp với nhu cầu chuyên biệt ở quy mô lớn.

CobbleDB: Giải pháp tự phát triển bằng Rust

Thay vì tiếp tục chịu đựng những hạn chế này, Perplexity quyết định xây dựng CobbleDB — một key-value store chuyên dụng viết bằng Rust.

Việc chọn Rust không phải ngẫu nhiên. Ngôn ngữ này mang lại:

• Hiệu năng cao gần với C/C++ nhưng an toàn hơn về bộ nhớ
• Kiểm soát bộ nhớ chặt chẽ nhờ hệ thống ownership, giảm thiểu lỗi rò rỉ bộ nhớ
• Khả năng xử lý đồng thời (concurrency) tốt, phù hợp với hệ thống chịu tải cao

Kết quả đạt được rất đáng chú ý: độ trễ truy vấn giảm tới 5 lần so với trước đây, đồng thời chi phí lưu trữ đám mây cũng được cắt giảm đáng kể.

Việc tự xây dựng hạ tầng lưu trữ giúp Perplexity kiểm soát hoàn toàn đường đi của dữ liệu, từ đó tối ưu cho đúng mẫu truy cập mà hệ thống tìm kiếm cần — điều mà một dịch vụ đa dụng như DynamoDB khó làm được.

Kiến trúc mới vận hành hiệu quả ra sao?

Theo mô tả, kiến trúc mới của Perplexity hỗ trợ lưu lượng truy vấn cao một cách hiệu quả hơn, trong khi vẫn đảm bảo xử lý khối lượng lớn tài liệu trong môi trường sản xuất thực tế.

Các cải thiện chính bao gồm:

• Giảm độ trễ khi phục vụ các truy vấn tìm kiếm
• Giảm chi phí lưu trữ nhờ thiết kế chuyên biệt
• Xử lý lô tài liệu lớn mượt mà hơn so với trước
• Duy trì ổn định dưới áp lực lưu lượng production

Ý nghĩa với cộng đồng công nghệ và doanh nghiệp Việt Nam

Câu chuyện của Perplexity phản ánh một xu hướng đáng chú ý: khi quy mô đủ lớn, tự xây dựng hạ tầng chuyên biệt có thể mang lại hiệu quả vượt trội so với việc dùng dịch vụ đám mây tổng quát.

Với các đội ngũ kỹ thuật tại Việt Nam, đặc biệt là các startup đang tăng trưởng nhanh, đây là bài học đáng tham khảo:

• Đánh giá lại chi phí đám mây khi hệ thống đạt quy mô lớn — hóa đơn AWS, GCP có thể tăng nhanh hơn dự kiến
• Cân nhắc Rust cho các thành phần hạ tầng chịu tải cao, nhờ sự kết hợp giữa hiệu năng và an toàn bộ nhớ
• Không vội vàng tự xây dựng — chỉ nên làm khi giải pháp sẵn có thực sự trở thành nút thắt cổ chai

Tuy nhiên, việc tự phát triển một key-value store đòi hỏi nguồn lực kỹ thuật đáng kể và đội ngũ giàu kinh nghiệm. Với phần lớn doanh nghiệp vừa và nhỏ, các dịch vụ đám mây được quản lý vẫn là lựa chọn hợp lý cho tới khi đạt được quy mô tương xứng.

Trường hợp của Perplexity cho thấy một điều: ở đỉnh cao của cuộc chơi hạ tầng, khả năng tự chủ công nghệ trở thành lợi thế cạnh tranh thực sự — vừa về hiệu năng, vừa về chi phí.