Cách thay thế Elasticsearch và MongoDB bằng Rust và RocksDB

• Radar cung cấp hạ tầng thông tin địa lý xử lý hơn 1 tỷ yêu cầu API mỗi ngày và đã chuyển từ Elasticsearch và MongoDB hiện tại sang HorizonDB tự phát triển để giải quyết vấn đề hiệu năng và khả năng mở rộng
• HorizonDB được xây dựng bằng Rust và là cơ sở dữ liệu thông tin địa lý hiệu năng cao kết hợp nhiều công cụ mã nguồn mở như RocksDB, S2, Tantivy, FST, LightGBM, FastText
• Trong kiến trúc trước đây, chi phí mở rộng và độ phức tạp của Elasticsearch và MongoDB khiến việc vận hành trở nên khó khăn
• HorizonDB hoạt động theo kiến trúc một tiến trình duy nhất đa luồng, giúp đạt được giảm chi phí, cải thiện hiệu năng và độ tin cậy cao
• Nhìn chung, năng suất phát triển và hiệu quả vận hành được cải thiện đáng kể, cho phép tích hợp nhanh chóng dữ liệu hoặc tính năng mới
• Dữ liệu được tiền xử lý bằng Apache Spark rồi lưu theo phiên bản trên AWS S3, giúp lập trình viên dễ dàng chạy và thử nghiệm ngay tại môi trường local
• Nhờ đó, nhóm đã đóng cụm Mongo và Elasticsearch, giảm chi phí đáng kể và cải thiện tốc độ phát triển tính năng cùng hiệu quả xử lý dữ liệu

---

Giới thiệu và bối cảnh

• Radar là nền tảng hạ tầng định vị địa lý toàn cầu, xử lý hơn 1 tỷ API call mỗi ngày từ hàng trăm triệu thiết bị
  • Các API chính gồm Geocoding, Search, Routing, Geolocation compliance
• Khi dữ liệu và sản phẩm mở rộng, bài toán hiệu năng, khả năng mở rộng và chi phí trở nên cấp bách
• Do đó, Radar triển khai HorizonDB viết bằng Rust để cung cấp nhiều chức năng vị trí trong một binary hiệu năng cao duy nhất
  • Xử lý 1.000 QPS mỗi lõi
  • Độ trễ trung bình geocoding xuôi là 50ms, reverse geocoding <1ms
  • Mở rộng tuyến tính trên phần cứng phổ thông

Hạn chế của hệ thống cũ

• Cấu trúc trước đây: geocoding xuôi chạy trên Elasticsearch, geocoding ngược chạy trên MongoDB
• Vấn đề:
  • Elasticsearch phân phối truy vấn trên tất cả shard và cần cập nhật theo batch theo chu kỳ
  • MongoDB khó xử lý batch khối lượng lớn, phân bổ tài nguyên quá mức và thiếu chức năng rollback ổn định

Mục tiêu kiến trúc của HorizonDB

• Hiệu quả - Chạy trên phần cứng phổ biến, tự động mở rộng dự đoán được, đóng vai trò nguồn dữ liệu duy nhất cho mọi thực thể địa lý
• Vận hành - Xây dựng và xử lý tài sản dữ liệu nhiều lần trong ngày, thay đổi và rollback dễ dàng, đơn giản hóa vận hành
• Trải nghiệm phát triển - Có thể chạy trên môi trường local, việc thay đổi và thử nghiệm trở nên dễ dàng

Công nghệ sử dụng

RocksDB, S2, Tantivy, FSTs, LightGBM, FastText và nhiều mã nguồn mở khác được sử dụng, dữ liệu sau khi tiền xử lý bằng Apache Spark sẽ được lưu dưới dạng tệp phiên bản hóa trên S3 trong Rust

• Rust

  • Ngôn ngữ lập trình hệ thống do Mozilla phát triển
  • Đảm bảo an toàn khi biên dịch và quản lý bộ nhớ, có thể quản lý bộ nhớ chỉ mục lớn dự đoán được mà không cần garbage collection
  • Hỗ trợ null handling, pattern matching và các trừu tượng cấp cao, giúp biểu diễn logic xếp hạng truy vấn phức tạp dễ dàng hơn
  • Tối ưu cho việc xử lý hàng trăm GB dữ liệu trên SSD với quy trình đơn đa luồng

• RocksDB

  • Kho lưu trữ in-process dựa trên cây LSM hiệu năng cao
  • Đáp ứng ở mức micro giây, tốc độ ổn định ngay cả với dữ liệu lớn

• S2

  • Thư viện chỉ mục không gian của Google chia bề mặt Trái Đất thành các ô để tăng tốc truy vấn điểm-đa giác
  • Radar tự xây dựng binding Rust cho thư viện S2 C++, dự kiến sẽ mở mã nguồn trong thời gian tới

• FSTs (Finite State Transducers)

  • Cấu trúc dữ liệu nén chuỗi hiệu quả và tìm kiếm theo tiền tố
  • Tận dụng việc 80% truy vấn là “happy path” có tính quy tắc, cho phép lưu trữ cache hàng triệu tuyến đường chỉ với vài MB RAM

• Tantivy

  • Thư viện chỉ mục ngược in-process tương tự Lucene
  • Lý do chọn thay cho dịch vụ bên ngoài như Elasticsearch trước đây:
    • Chất lượng tìm kiếm - Ứng phó nhanh với xử lý tìm kiếm nâng cao như mở rộng từ khóa động mà không có độ trễ giao tiếp UML
    • Đơn giản hóa vận hành - Xử lý trong một tiến trình duy nhất, chỉ số lớn cũng có thể mở rộng dễ dàng nhờ memory mapping

• FastText

  • Sử dụng mô hình FastText được huấn luyện trên corpus nội bộ và log để tạo biểu diễn vector từ, phục vụ ứng dụng ML
  • Mạnh mẽ với lỗi chính tả và từ ngoài từ điển nhờ tận dụng tương đồng ngữ nghĩa giữa các vector lân cận để đạt hiểu ngữ nghĩa tìm kiếm

• LightGBM

  • Sử dụng nhiều mô hình LightGBM cho phân loại ý định truy vấn, gắn thẻ thuộc tính trong truy vấn
  • Ví dụ: truy vấn khu vực như “New York” sẽ bỏ qua tra cứu địa chỉ, truy vấn như “841 Broadway” sẽ bỏ qua tìm kiếm POI/khu vực

• Apache Spark

  • Xử lý hàng trăm triệu điểm dữ liệu trong chưa đến 1 giờ, liên tục tối ưu công việc để tăng tốc join/aggregation
  • Dữ liệu cuối cùng được lưu trên S3, cho phép khám phá kết quả dựa trên SQL bằng Amazon Athena hoặc DuckDB

Kết quả sau khi triển khai HorizonDB

• Dịch vụ nhanh hơn đáng kể và vận hành đơn giản hơn, độ tin cậy được cải thiện
• Đội phát triển có thể triển khai và đánh giá tính năng cùng nguồn dữ liệu mới trong vòng một ngày
• Giảm hàng chục nghìn USD mỗi tháng nhờ ngừng các cụm quy mô lớn như Mongo, Elasticsearch và nhiều microservice

• Radar đã hoàn tất chuẩn bị để đối phó với mở rộng quy mô lớn trong tương lai. Quá trình thiết kế chi tiết cho một số tính năng cụ thể sẽ được giới thiệu trong blog sắp tới