ハクソク

世界を動かす技術を、日本語で。

ElasticsearchとMongoDBをRustとRocksDBに置き換えた方法

290日前原文(radar.com)

概要

  • Radar は毎日10億件以上のAPIコールを処理する高性能なジオロケーション基盤を提供
  • スケーラビリティ課題を解決するため、 Rust製地理空間DB「HorizonDB」 を開発
  • 旧来のMongoDBやElasticsearchを廃止し、コスト・性能・運用性を大幅向上
  • RocksDB/S2/Tantivy/LightGBM/FastText/Spark 等の技術を活用したアーキテクチャ
  • HorizonDB導入により、開発効率と信頼性も大幅向上

Radarの地理空間基盤とパフォーマンス重視の設計

  • Radar はグローバルで数億台のデバイスから毎日10億件超のAPIコールを処理

    • ジオコーディング （順方向・逆方向・IPベース）API
    • サーチ （住所補完・住所バリデーション・場所検索）API
    • ルーティング （距離・マトリクス・最適化・経路マッチング・案内）API
    • ジオロケーションコンプライアンス （管轄検出・国境距離・規制除外ゾーン等）

  • スケール拡大 に伴うエンジニアリング課題の顕在化

    • パフォーマンスとコスト最適化の必要性

HorizonDB開発の背景と目的

  • MongoDB/Elasticsearch による従来構成の課題

    • Elasticsearch：全シャードへのクエリ拡散、バッチ更新の複雑さ
    • MongoDB：バッチ取り込み非対応、過剰プロビジョニング、ロールバック困難

  • HorizonDB の開発目標

    • 効率性 ：汎用マシンで稼働、予測可能なオートスケーリング、単一の真実ソース
    • 運用性 ：データアセットの頻繁なビルド・ロールバックが容易、シンプルな運用
    • 開発体験 ：ローカル実行・テストが容易、迅速な変更適用

  • HorizonDB の特徴

    • 1コアあたり1,000QPS、順方向ジオコーディング中央値50ms、逆方向は1ms未満
    • 汎用ハードウェアで線形スケール

技術スタックと各技術の役割

  • Rust

    • コンパイル＆メモリ安全性、ガーベジコレクション不要
    • 高次抽象 で複雑なロジックも簡潔に記述
    • マルチスレッド単一プロセス で大容量データ効率利用

  • RocksDB

    • 高速なキー・バリュー型ストレージエンジン

  • S2 （Google製空間インデックス）

    • 球面上のクアッドツリー投影で高速な空間検索
    • Rustバインディングを自社開発、今後OSS化予定

  • FSTs （Finite State Transducers）

    • 文字列圧縮＆プレフィックス検索に特化したデータ構造
    • クエリの80%を効率的にキャッシュ、数MBで数百万件のパスを格納

  • Tantivy

    • Lucene類似のインプロセス倒立インデックス
    • 検索品質向上・運用簡素化・メモリマッピングで大規模インデックスも効率的

  • FastText

    • クエリ語彙の意味的ベクトル化、タイプミス耐性、未知語対応
    • 検索精度とMLアルゴリズムの意味理解向上

  • LightGBM

    • クエリ意図分類・構造化による検索性能・精度向上
    • 例：地域名クエリは住所検索スキップ、住所指定はPOI検索スキップ

  • Apache Spark

    • 数億件規模データを1時間未満で処理、ほぼ線形スケール
    • S3出力データはAmazon AthenaやDuckDBで即時検証可能

HorizonDB導入後の成果

  • サービスの 高速化・運用簡素化・信頼性向上
  • 新機能・データ変更 への迅速な対応が可能に
  • MongoDB/Elasticsearch/複数マイクロサービス の廃止で月数万ドル規模のコスト削減
  • 今後のスケールにも対応可能な設計
  • 開発チーム（Bradley Schoeneweis, Jason Liu, Jacky Wang, Binh Robles, Greg Sadetsky, David Gurevich, Felix Li）への謝意

採用情報・今後の展望

  • Radar はAPIだけでなくSDK・マップ・DB・インフラ全体で最速＆開発者フレンドリーな位置情報基盤を再設計
  • エンジニア採用強化中、興味ある方は Jobsページ 参照

Hackerたちの意見

これがOSMデータ用のオープンソースElasticSearch/OpenSearch検索エンジン「Photon」に役立つかもね。OSMの世界では、ほとんどのアプリが誤字をうまく処理できない悪い検索体験を提供してるから、これはちょっとした革命だよ。 https://github.com/komoot/photon

でも、オープンソースにはしないのかな？

└

そうみたいだけど、彼らがまとめたツールの良い紹介記事だね。誰かがコピーしてオープンソースにしてくれるといいな… :)

└

今はちょっと難しいかな、プロプライエタリなデータがたくさんあるし、そのロジックもそれに従ってるから。OSMデータをインデックスして提供できる状態に持っていけることを願ってるけど、それには時間がかかるだろうね。とはいえ、現在Google S2のRustバインディングをオープンソース化する作業を進めてるよ。これは逆ジオコーダーを書くのがとても簡単になるジオハッシングライブラリで、ポリゴン内のポイントやポリゴンの交差の観点からも使えるよ。

検索の分野にいる者として、どれだけの企業が「Elasticsearchを置き換えよう」としているかっていうのは面白いよね。

└

自分の経験では、Elastic Searchクラスターの管理や運用にかかる手間は、プライマリデータストアよりもかなり多い気がするんだよね。特にプライマリデータストアがRDBMSの場合はちょっと変だなって思う。ESの機能の一部を使った、もっとシンプルで堅牢なソリューションを使いたいな。

└

ここで作者です！「分散システム」の問題を「モノリシックシステム」に変えることにすごく意欲的で、今のハードウェアでそれが実現できると思ったから、RocksDBやTantivyみたいなプロセス内の埋め込みストレージシステムを選んだんだ。メモリマッピングのおかげで、グローバルカバレッジでもかなり進められる。特にクラウドで運用しているから、RAMを追加するのも簡単だしね。バックフィルやデータの更新も簡単で、ESやMongoに何が入っているかを考えずに「不変」の方法で実行できる。別のノードで同じバイナリで再インデックスして、最終的なアセットをS3に送るだけだよ。

ちょっとメタな話だけど、また社内データストレージシステムやクエリエンジンの設計やブログを書くようになったのは良い兆しだと思う。2010年代にはこれが爆発的に増えたけど、最近はAIに焦点を当てるようになった気がする。

└

いいの？この分野で何を革新する余地が残ってるの？実験的なデータストアはあんまり欲しくないな。もっと堅実なものが欲しい。

└

AIのせいで遅くなったんじゃなくて、ほとんど無意味だってわかったからだよ。通常、既存のシステムを調整したり、別の方法でスケールさせたりすることで、パフォーマンスがマッチするような高度に専門化されたスタック。自社のストレージやクエリシステムは、単独で売られている製品じゃなくて、エンジニアリングリソースが余ってる会社のNIH症候群だね。

この記事は詳細が足りないね。例えば、データはどうシャーディングされてるのか、インデックス作成から提供までの時間はどれくらいか、ノードの障害にどう対処するのか、他の分散システムに関する質問もあるし。レイテンシーはどう比較されるの？とかさ。

詳細はちょっと薄いけど、オープンソースにはならなさそうだね。でも、「ESの代わりになるもの」を探してる人がこの投稿をクリックしたなら、https://typesense.org/ と https://duckdb.org/（その空間プラグイン付き）は、地理的なパフォーマンス的に素晴らしいよ。特に後者は、データがあまり変わらない時には本当にプロダクション向けって感じ。どちらも完全にオープンソースで、クラスターやシャーディングのセットアップもできる。全く関係ないけど、すごく満足してる。

└

Typesenseはマジで凄い！開発体験もかなり良いよ。

└

これらは素晴らしいね。こういうプロジェクトがオープンソースであることに永遠に感謝してる。ただ、自分のプロジェクトに統合するのは難しいと感じることもある。前に、duckdbとその空間プラグイン、SQLiteの拡張を静的にリンクしてコンパイルしたものを作ろうとしたんだけど、ビルドが失敗して、両方が異なるバージョンのSQLiteシンボルを必要としていることに気づいて、ちょっと手に負えなくなった。

└

これらは素晴らしいプロジェクトだね。私たちはDuckDBを使ってデータレイクを調査したり、素早くデータを整形したりしてる。今後、システムの異なる部分をもっと詳しく説明するブログ投稿もいくつか予定してるよ。あまりに密度が高いと読みづらくなるんじゃないかと心配してたからね。

└

Typesenseは製品として素晴らしい（ホスティングされたクラスター）。カスタマーサポートも最高だよ。

└

何をオープンソースにするのかよくわからないな。Rustのコード？DBって呼んでるけど、全体のスタックを説明してるよね。

└

DuckDBって、シャーディングやクラスタリングが全然ないの？サーバーもないし（HTTPサーバー拡張を除けば）。

いいね… いろんな会社がそれぞれの最適なソリューションを組み合わせてるのを見るのは面白い。少なくとも、カスタムソリューションに飛びつく前に、オフ・ザ・シェルフのアプリから始めたのは良かったと思う。Quickwitは面白そうだね、Tantivityのリファレンス経由で見つけたよ。ESとLuceneの組み合わせみたい。1. https://github.com/quickwit-oss/quickwit

└

それ、Tantivyだよ :)

Elasticsearchに惹かれてクリックしたけど、radar.comを知らなかったのが不思議。ちょうど必要なオートコンプリートが手頃な価格であるんだよね。

HorizonDBを探してたら、GitHubでPythonプロジェクトを見つけた。おそらくクローズドソースの*aasだけかな？

RocksはLevelのフォークで、Levelはデータ破損やバグで有名だよね。どちらも「プロダクションスケールで動く」けど、私がLevelを使ってた時は、サービスを維持するためにLevelを修復するのにどれだけ苦労したか、誰も公に話してなかった。こういう広告を見ると（これらの投稿は企業の広告だよ）、新しいスタックの全貌、特に欠点や深刻さについては本当のことを言わない。大手企業の人たちのテックトークも同じで、物語を売ってるだけなんだよね。

└

RocksDBはずいぶん前にLevelDBから分岐して、業界と学界の両方で広範な作業が行われてきたよ。LevelDBみたいなおもちゃのデータベースじゃない。彼らが隠してると言われている問題についてはわからないけど、RocksDBから来る可能性は低いと思う。

└

私の経験とは違うな。4年間、数千台のマシンでRocksDBを運用してきたけど、それぞれテラバイトのデータを保存してるのに、RocksDBが原因で正確性の問題を見たことは一度もないよ。