Radar公司为提升性能，开发了基于Rust和RocksDB的HorizonDB地理空间数据库，替代了原有的Elasticsearch和MongoDB。HorizonDB整合了多种定位服务，显著提升了处理能力，支持每天处理超过10亿次API调用，并在普通硬件上实现线性扩展，优化了地理编码等服务的响应时间。

标题：我们如何用Rust和RocksDB取代Elasticsearch和MongoDB

在Radar，性能是我们平台的核心特性。我们每天处理来自全球数亿设备的超过10亿次API调用，提供包括地理编码、搜索、路由和地理定位合规性在内的多种地理定位基础设施和解决方案。

随着产品和数据规模的扩大，我们的工程挑战也随之增加。为了支持这一增长，我们开发了HorizonDB，这是一个用Rust编写的地理空间数据库，将多个位置服务整合为一个高性能的二进制文件。HorizonDB能够处理每秒1000次查询（QPS），并保持正向地理编码的中位延迟为50毫秒，反向地理编码的中位延迟小于1毫秒，同时在普通硬件上实现线性扩展。

为何替换MongoDB和Elasticsearch

在HorizonDB之前，我们使用Elasticsearch和微服务处理正向地理编码，MongoDB处理反向地理编码。然而，这种架构的运营和扩展成本高昂：Elasticsearch经常将查询分发到所有分片，并且需要服务协调的批量更新；而MongoDB缺乏真正的批量数据摄入功能，需要过度配置，并且没有可靠的批量回滚机制。

架构设计

我们的设计目标包括：

1. 高效性：服务可以在普通机器上运行，具有可预测的自动扩展能力，并且是所有地理实体的单一数据源。
2. 易操作性：数据资产可以每天多次构建和处理，变更可以轻松部署和回滚，操作简单。
3. 开发者体验：开发者可以在本地运行服务，变更可以轻松编写和测试。

基于这些目标，我们使用RocksDB、S2、Tantivy、FSTs、LightGBM和FastText构建了HorizonDB。数据资产通过Apache Spark预处理，用Rust摄入，并作为版本化资产存储在AWS S3中。

Rust的优势

Rust是一种由Mozilla设计的编译语言，适用于系统编程。我们选择Rust的原因包括：

• 编译和内存安全：Rust的强类型系统和安全的并发模型（如Rayon和Tokio）使我们能够编写高性能代码，同时保持可读性。Rust无需垃圾回收即可轻松管理内存，使我们能够以可预测的延迟管理内存中的大数据索引。
• 高阶抽象：Rust提供了高阶抽象，使团队能够快速移动并清晰地表达逻辑，这对于处理复杂的搜索排名逻辑尤为重要。
• 多线程而非多进程：由于HorizonDB需要从SSD中获取数百GB的数据，使用单进程可以更高效地利用相同的内存地址空间。

RocksDB和S2

RocksDB是一个高性能的嵌入式数据库，而S2是Google的空间索引库，将四叉树投影到球体上，将O(n)的点在多边形查找转换为可缓存的常数时间查找。我们为Google的C++库编写了Rust绑定，并计划开源。

FSTs和Tantivy

FSTs是一种高效字符串压缩和前缀查询的数据结构，我们使用它来缓存数百万条查询路径。Tantivy是一个类似于Lucene的进程内倒排索引库，我们选择它而不是外部服务（如Elasticsearch或Meilisearch）的原因包括搜索质量和操作简单性。

FastText和LightGBM

我们使用FastText模型来提高搜索精度和质量，并通过LightGBM模型对查询意图进行分类和标记，从而优化搜索性能和精度。

Apache Spark

通过Spark，我们能够在不到一小时内处理数亿个数据点，并实现近线性的扩展性。数据写入S3后，我们可以通过Amazon Athena轻松检查结果。

成果

HorizonDB显著改善了我们的地理定位服务的运营和开发效率，实现了成本、性能和可扩展性的全面提升。我们关闭了多个MongoDB集群、一个大型Elasticsearch集群和多个地理微服务，每月节省了数万美元的成本。

我们为HorizonDB的设计决策感到满意，并准备应对未来的扩展需求。我们将在未来的博客文章中详细介绍系统的特定功能设计。

感谢我们的工程师团队，他们使这一系统成为现实。

加入我们

Radar不仅仅是一个API层，我们正在重新思考地理定位，提供最快、最开发者友好的位置堆栈。如果你对这篇博客感兴趣，我们正在招聘优秀的工程人才，欢迎查看我们的招聘页面了解更多信息。

评论内容主要围绕以下几个方面：

1. 对开源和替代Elasticsearch的讨论：

   • 评论1提到Photon作为开源搜索引擎的潜力，认为它在处理拼写错误方面可能带来革命性变化。
     • 引用："It's a mini-revolution in the OSM world, where most apps have a bad search experience where typos aren't handled."
   • 评论2质疑该技术是否开源。
     • 引用："They're not open sourcing it though?"
   • 评论8推荐了Typesense和DuckDB作为Elasticsearch的替代品，认为它们在处理地理数据方面表现优异。
     • 引用："Both Typesense and DuckDB (with their spatial plugin) are excellent geo performance wise."

2. 对技术细节和性能的质疑：

   • 评论6指出文章缺乏细节，如数据分片、索引与服务的延迟时间、节点故障处理等。
     • 引用："This article is lacking detail. For example, how is the data sharded, how much time between indexing and serving, and how does it handle node failure?"
   • 评论10关注系统的扩展性和数据丢失问题。
     • 引用："Would love to know how they scaled it. Also, what happens when you lose the machine and the local db?"

3. 对技术趋势和公司解决方案的观察：

   • 评论4认为设计和博客讨论内部数据存储系统是一个积极的信号，反映了技术趋势的变化。
     • 引用："I find its a good sign that we're back to designing and blogging about in-house data storage systems/ Query engines again."
   • 评论11赞赏公司从现成应用出发，逐步构建最佳解决方案的做法。
     • 引用："Nice... it's cool to see how different companies are putting together best fit solutions."

4. 对替代方案的推荐和个人经验分享：

   • 评论9提到RocksDB和Quickwit作为Elasticsearch的替代方案，并分享了个人使用经验。
     • 引用："I actually used RocksDB to solve many use cases and it's quite powerful and very performant."
   • 评论7认为在没有基准测试的情况下，替代Elasticsearch的声明只是大胆的假设。
     • 引用："Without benchmarks it’s just bold claims we’ll have to ascertain."

总结：评论中对开源、技术细节、性能、技术趋势和替代方案进行了广泛讨论，既有对现有技术的质疑，也有对替代方案的推荐和个人经验的分享。