Thông báo gần đây của Radar về HorizonDB, cơ sở dữ liệu không gian địa lý tùy chỉnh được xây dựng bằng Rust và RocksDB, đã khơi mào cuộc thảo luận sôi nổi trong cộng đồng các nhà phát triển về tính khả thi của việc thay thế các giải pháp đã được thiết lập như Elasticsearch và MongoDB. Công ty tuyên bố hệ thống mới của họ xử lý được 1.000 truy vấn mỗi giây trên mỗi lõi trong khi duy trì thời gian phản hồi dưới một mili giây cho việc mã hóa địa lý ngược.
Tuyên bố hiệu suất của HorizonDB:
- 1.000 QPS trên mỗi lõi
- Độ trễ trung vị của forward geocoding: 50ms
- Độ trễ trung vị của reverse geocoding: <1ms
- Mở rộng tuyến tính trên phần cứng thông dụng
- Xử lý hơn 1 tỷ lượt gọi API mỗi ngày
![]() |
---|
HorizonDB của Radar tuyên bố có các chỉ số hiệu suất cao trong các truy vấn không gian địa lý |
Cộng đồng đặt câu hỏi về các tuyên bố độ tin cậy
Cộng đồng nhà phát triển đã nêu lên những lo ngại đáng kể về việc thiếu chi tiết kỹ thuật trong thông báo của Radar. Nhiều người đang đặt câu hỏi về các khía cạnh cơ bản của kiến trúc hệ thống mà không được đề cập trong bài đăng gốc. Thông tin quan trọng bị thiếu bao gồm cách dữ liệu được phân phối trên nhiều máy chủ, điều gì xảy ra khi phần cứng gặp sự cố, và hệ thống đảm bảo không mất dữ liệu trong thời gian ngừng hoạt động như thế nào.
Những lo ngại này làm nổi bật sự hoài nghi rộng rãi hơn về các giải pháp cơ sở dữ liệu tùy chỉnh. Trong khi Radar khoe khoang những con số hiệu suất ấn tượng, các nhà phát triển có kinh nghiệm biết rằng thử thách thực sự đến khi các hệ thống đối mặt với những sự cố không mong muốn hoặc cần mở rộng quy mô vượt ra ngoài thiết kế ban đầu.
Các giải pháp thay thế thu hút sự chú ý
Cuộc thảo luận đã thu hút sự chú ý đến các giải pháp mã nguồn mở hiện có có thể mang lại lợi ích tương tự mà không cần sự phức tạp của việc xây dựng từ đầu. Typesense và DuckDB đã nổi lên như những gợi ý phổ biến, với các nhà phát triển ca ngợi hiệu suất của chúng cho các truy vấn không gian địa lý và trạng thái sẵn sàng cho sản xuất.
Cả hai đều hoàn toàn mã nguồn mở bao gồm cả thiết lập phân cụm/phân mảnh.
DuckDB, đặc biệt, đã được công nhận về khả năng plugin không gian, đặc biệt cho các ứng dụng mà dữ liệu không thay đổi thường xuyên. Tuy nhiên, một số nhà phát triển đã lưu ý những thách thức tích hợp khi cố gắng kết hợp nhiều công nghệ cơ sở dữ liệu trong một dự án duy nhất.
Các Lựa Chọn Thay Thế Mã Nguồn Mở Được Đề Cập:
- Typesense: Công cụ tìm kiếm toàn văn với khả năng địa lý
- DuckDB: Cơ sở dữ liệu phân tích với plugin không gian
- Photon: Công cụ tìm kiếm OpenStreetMap sử dụng Elasticsearch
- Quickwit: Lựa chọn thay thế Elasticsearch cho quản lý log
Sự chia rẽ kinh nghiệm Elasticsearch
Có lẽ khía cạnh thú vị nhất của cuộc thảo luận cộng đồng là sự chia rẽ rõ rệt trong kinh nghiệm Elasticsearch. Trong khi Radar trích dẫn độ phức tạp vận hành như một lý do chính để rời khỏi Elasticsearch, một số nhà phát triển đã chia sẻ những kinh nghiệm trái ngược về việc vận hành các cụm Elasticsearch ổn định với chi phí bảo trì tối thiểu.
Một nhà phát triển báo cáo quản lý 12 nút với 200 triệu tài liệu mỗi nút, hầu như không yêu cầu bảo trì tích cực nào ngoài giám sát cơ bản. Điều này cho thấy danh tiếng phức tạp của Elasticsearch có thể liên quan nhiều hơn đến cách tiếp cận triển khai hơn là những hạn chế vốn có của hệ thống.
So sánh Technology Stack:
Stack trước đây | HorizonDB Stack |
---|---|
Elasticsearch (forward geocoding) | Rust + RocksDB |
MongoDB (reverse geocoding) | Tantivy (search) |
Nhiều microservices | S2 (spatial indexing) |
- | FSTs (string compression) |
- | LightGBM + FastText (ML) |
Sự đánh đổi giữa đổi mới và ổn định
Cuộc trò chuyện rộng hơn chạm đến một căng thẳng cơ bản trong các lựa chọn công nghệ. Trong khi các giải pháp tùy chỉnh có thể mang lại những cải thiện hiệu suất ấn tượng và phù hợp hoàn hảo cho các trường hợp sử dụng cụ thể, chúng cũng đưa ra những rủi ro xung quanh bảo trì dài hạn, kiến thức của nhóm, và độ tin cậy của hệ thống.
Sự hồi sinh của phát triển cơ sở dữ liệu tùy chỉnh đại diện cho cả một cơ hội và thách thức cho ngành công nghiệp. Các công ty ngày càng sẵn sàng đầu tư vào các giải pháp chuyên biệt khi các công cụ hiện có không đáp ứng chính xác nhu cầu của họ, nhưng cách tiếp cận này đòi hỏi nguồn lực kỹ thuật và chuyên môn đáng kể mà nhiều tổ chức thiếu.
Cuộc tranh luận xung quanh HorizonDB cuối cùng phản ánh những câu hỏi lớn hơn về khi nào nên xây dựng so với mua, và liệu những cải thiện hiệu suất từ các giải pháp tùy chỉnh có biện minh cho sự phức tạp và rủi ro bổ sung mà chúng đưa ra hay không.
Tham khảo: How we replaced Elasticsearch and MongoDB with Rust and RocksDB
![]() |
---|
Hiểu về chỉ mục đảo ngược và những tác động của nó trong công nghệ cơ sở dữ liệu |