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

 (radar.com)
4 điểm bởi GN⁺ 2025-08-10 | 1 bình luận | Chia sẻ qua WhatsApp
  • 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
    Quảng cáo

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
    Quảng cáo

  • 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
    Quảng cáo

  • 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

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-08-10
Bình luận trên Hacker News

  • Tôi thấy tiếc vì nội dung khá thiếu và dường như chưa có kế hoạch mã nguồn mở; nếu bạn vô bài này vì đang tìm giải pháp thay thế ES (ElasticSearch), tôi muốn giới thiệu typesense.org và duckdb.org (đặc biệt kèm plugin spatial). Cả hai dịch vụ đều có hiệu năng dữ liệu không gian rất tốt, DuckDB cũng trông phù hợp để dùng thực tế cho dữ liệu ít thay đổi; trong cấu hình cụm/chia shard cũng là mã nguồn mở hoàn toàn. Gợi ý này hoàn toàn dựa trên trải nghiệm sử dụng cá nhân, không liên quan gì khác.

    • Hai dự án này thật sự rất tuyệt; đội của chúng tôi cũng đang dùng DuckDB khá tích cực cho việc kiểm tra data lake và xử lý dữ liệu đơn giản. Sẽ có thêm bài blog giải thích chi tiết các phần khác của hệ thống. Tôi lo rằng một bài viết chứa quá nhiều nội dung sẽ khó đọc nên đã quyết định chia nhỏ nội dung.

    • Tôi luôn biết ơn vì có những dự án mã nguồn mở như vậy, nhưng tích hợp vào dự án của mình không hề dễ. Trước đây tôi từng thử build DuckDB cùng spatial và extension SQLite bằng liên kết tĩnh, nhưng do ký hiệu (symbol) SQLite của các phiên bản khác nhau nên build bị lỗi và công việc khá mệt.

    • Chẳng phải DuckDB chưa có sharding hoặc clustering sao? Nó cũng không có server riêng (ngoại trừ HTTP Server Extension).

    • Typesense có hiệu năng thực sự tuyệt vời, và trải nghiệm phát triển cũng rất hài lòng.

    • Không biết nên mã nguồn mở cái gì, có phải mã Rust không; họ tuyên bố là DB nhưng cảm giác như đã mô tả cả một stack.

  • Cảm thấy buồn cười khi trang tuyển dụng nhấn mạnh 'văn hóa làm việc tại văn phòng' như lợi ích hàng đầu; tôi thật sự tò mò tại sao việc đi lại lại được xem là lợi ích.

    • Việc đi làm tại chỗ hay làm việc từ xa không chỉ là thời gian di chuyển; còn nhiều yếu tố khác như môi trường làm việc, cân bằng công việc–cuộc sống. Trải nghiệm của tôi là khi thời gian di chuyển dưới 30 phút và có thể đi bộ hoặc đạp xe thì rất thú vị: vừa tập thể dục, vừa sắp xếp lại suy nghĩ, giúp chuyển đổi tâm lý giữa nhà và công việc. Khi làm việc từ xa hoàn toàn năm 2020, dần dần việc làm và nghỉ ngơi cùng một không gian trở nên khó khăn hơn, nên mỗi ngày sau giờ tan làm tôi đi bộ khoảng một tiếng để phục hồi tinh thần. Tuy nhiên, những lần đi lại hơn một giờ bằng giao thông công cộng hoặc lái xe trên xa lộ thì thật mệt mỏi.

    • Tôi nghĩ nếu nói 'văn hóa văn phòng' có thật sự là điểm cộng thì cần có cơ hội học hỏi với người giỏi, cơ hội kết bạn, đồ ăn/thức uống miễn phí, máy DDR v.v. Trong trải nghiệm văn phòng gần nhất, các lợi ích đó hầu như không có; bầu không khí giống như mở rộng quy mô làm việc tại nhà.

    • Có thể có người thích đi làm văn phòng; mỗi người một sở thích.

    • Tôi thích đi làm bằng phương tiện đi lại hơn là làm từ xa; nghĩa là có người rõ ràng coi việc đi lại là một lợi ích.

  • Tôi tò mò không biết hệ thống này có thể giúp gì cho Photon, engine ElasticSearch/OpenSearch mã nguồn mở cho dữ liệu OSM (OpenStreetMap) hay không; hầu hết ứng dụng OSM có trải nghiệm tìm kiếm kém và rất yếu khi gõ sai chính tả, nhưng Photon đã mang lại một thay đổi nhỏ cho vấn đề này, liên kết GitHub của Photon

    • Tôi nghĩ trong trường hợp này một hệ thống dùng LMDB sẽ phù hợp hơn RocksDB; hiện OSM Express đã dùng LMDB rồi, liên kết wiki OSM Express

  • Đó là một ý kiến hơi meta, nhưng tôi rất vui khi thấy xu hướng viết về việc thiết kế kho dữ liệu và công cụ truy vấn nội bộ đang trở nên sôi nổi trở lại; hồi giữa những năm 2010 đã từng có cơn sốt như vậy, dạo gần đây thì tập trung nhiều vào AI.

    • Tôi nghĩ cơn sốt đó không hẳn vì AI; mà vì cuối cùng người ta nhận ra phần lớn (giải pháp) ấy không thực sự hữu ích. Với việc tinh chỉnh hoặc mở rộng hệ thống hiện có đã có thể đạt đủ hiệu năng, nên hầu như không cần một stack riêng biệt quá chuyên biệt. Một hệ thống lưu trữ/truy vấn nội bộ không nhằm thương mại hóa cuối cùng chỉ là biểu hiện của hội chứng NIH (Not Invented Here) của những công ty có đủ nguồn lực.

    • NoSQL và các cơ sở dữ liệu thay thế từng bùng lên như một trào lưu rồi sau đó phai dần khi mọi người nhận ra rằng đa phần doanh nghiệp chỉ cần PostgreSQL một mình là đủ.

    • Tôi không chắc còn nhiều điều cần đổi mới nữa hay không; tôi muốn các sản phẩm đáng tin cậy, đã được kiểm chứng hơn là các kho dữ liệu mang tính thí nghiệm.

  • Tôi thấy kỳ lạ khi tiêu đề bài viết có chứa tên ngôn ngữ "Rust"; độc giả có thể bối rối không biết Rust đang thay thế gì — ElasticSearch hay MongoDB.

    • Bài viết này thiếu chi tiết quá nhiều; ví dụ như cách chia shard dữ liệu, độ trễ giữa indexing và dịch vụ, xử lý node lỗi, độ trễ trong hệ thống phân tán và nhiều nội dung cốt lõi khác còn thiếu.

  • Với góc nhìn trong lĩnh vực tìm kiếm, tôi đang theo dõi thú vị việc ngày càng có nhiều công ty đặt mục tiêu 'thay thế ElasticSearch'.

    • Tôi là tác giả bài viết! Từ góc độ vận hành, sau khi nhận ra có thể chuyển bài toán 'hệ thống phân tán' sang 'hệ thống monolithic', tôi cảm thấy gần đây phần cứng đã đủ khả thi nên chọn các hệ thống lưu trữ nhúng như RocksDB, Tantivy. Nhờ memory mapping, chúng tôi còn có thể đáp ứng nhu cầu bao phủ toàn cầu; và trong môi trường cloud thì việc mở rộng RAM cũng rất linh hoạt. Backfill và cập nhật dữ liệu được xử lý đơn giản bằng cách reindex toàn bộ bằng cùng một binary trên node mới rồi gửi lên S3, không cần theo dõi trạng thái riêng giữa ES/Mongo nữa.

    • Tôi đã nhiều lần thấy công sức và thời gian để vận hành, quản trị một cụm ElasticSearch lớn hơn nhiều so với một cơ sở dữ liệu vận hành thực tế. Vì vậy, trong nhiều trường hợp tôi có xu hướng muốn dùng giải pháp thay thế đơn giản hơn, cung cấp ít tính năng hơn ES đầy đủ nhưng ít hay bị hỏng hơn.

  • Tôi thích thú khi thấy nhiều công ty phối hợp ra giải pháp phù hợp nhất cho họ, đặc biệt là họ bắt đầu bằng cách dùng các công cụ mã nguồn mở thương mại thay vì tự phát triển từ đầu. Nhân tiện, Quickwit tôi biết qua Tantivy đã thu hút sự chú ý của tôi; nó cho cảm giác khá giống ES dựa trên Lucene, liên kết GitHub của Quickwit

    • chính là tantivy :)

  • Rocks là nhánh của Level, và Level nổi tiếng với các lỗi như hỏng dữ liệu; dù cả hai đều đã được dùng nhiều trong production, khi tôi từng dùng Level thì đội vận hành đã rất khổ sở xử lý lỗi để duy trì dịch vụ. Những bài đăng blog của công ty kiểu này hiếm khi nói thẳng về nhược điểm hay sự cố nghiêm trọng của stack công nghệ mới, và cả Tech Talk của 'big name company' cuối cùng cũng là quảng cáo câu chuyện của chính họ.

    • RocksDB đã tách khỏi LevelDB từ lâu và hiện đã trải qua cải tiến lớn trong cả công nghiệp lẫn học thuật; theo tôi, nó không còn là một cơ sở dữ liệu kiểu toy như LevelDB nữa. Có thể còn tồn tại một vài nhược điểm chưa phát hiện, nhưng khả năng xuất hiện vấn đề nghiêm trọng ở RocksDB tôi cho là thấp.

    • Kinh nghiệm của tôi lại khác: trong 4 năm qua, tôi đã chạy RocksDB trên hàng nghìn máy chủ (mỗi máy vài terabyte dữ liệu) mà chưa từng gặp lỗi nào do chính RocksDB.

  • Tôi đã bấm vào bài này vì từ khóa Elasticsearch và ngạc nhiên khi trước giờ chưa biết đến radar.com; tôi quan tâm vì thấy có tính năng autocomplete ở mức giá phù hợp với nhu cầu của tôi.