Tantivyの作成者、Paul Masurel氏との対談

Tantivyの作成者、Paul Masurel氏との対談

［画像: James Blackwood-Sewellのヘッドショット］

James Blackwood-Sewell 著 2026年4月2日

［画像: Paul Masurel氏との対談］

フルテキスト検索の歴史のほとんどにおいて、それは一つのライブラリ、すなわちApache Luceneと同義でした。Javaで書かれ、20年以上にわたって実証されてきたLuceneは、Elasticsearch、Solr、そして今日の業界が依存する多くの検索インフラストラクチャを支えています。それは、問題は解決された、基本を再考する余地はないと思わせるようなプロジェクトです。

そこに2017年、Tantivy というRustライブラリがGitHubに登場しました。検索エンジンの理解と新しいお気に入りの言語を試したい一人の開発者によって構築されたこのライブラリは、小さく、高速で、断固としてモジュール化されていました。数年のうちに、それはQuickwit、ParadeDB、LNX、そして数多くの検索製品のエンジンとなり、Luceneチーム自身との本物のパフォーマンス協力関係を spark しました。

その開発者がPaul Masurel氏です。Tantivyを作成した後、Paul氏は2020年にQuickwitを共同設立し、その上にクラウドネイティブなログ検索エンジンを構築しました。Quickwitは2024年にDatadogに買収され、Paul氏は現在、大規模な検索インフラストラクチャに取り組んでいます。私たちは彼と、Tantivyの起源、その設計思想、Luceneとの競争（および協力）の経験、そしてこれまでに学んだ教訓について語り合いました。

起源

あなたはキャリアの多くを検索インフラストラクチャの再構築に費やしてきました。検索システムに最初に興味を持ったきっかけは何ですか？

私の検索エンジンとの関わりは、Exaleadという小さなフランスのエンタープライズ検索会社で始まりました。当時はフロントエンドエンジニアでした。コアチームの一員ではなかったことから、私のフラストレーションが募っていったのだと思います。長く熟成されたフラストレーションは、私の意見では過小評価されている原動力です。

Tantivyの構築

Paul氏のフラストレーションはすぐに、日本でのIndeedでの検索製品のバックエンドエンジニアとしての仕事につながりましたが、そこで彼はコア検索エンジン自体に取り組んでいました。しかし、ゼロから何かを構築するという考えが彼を惹きつけ続けていました。2016年の長距離フライトがきっかけとなりました。最初のバージョンは「少しおかしな」もので、数ヶ月の余暇しかかかりませんでしたが、アイデアが実現可能であることを証明するには十分でした。

なぜゼロから検索エンジンを構築することにしたのですか？また、Rustはそのアーキテクチャを形作りましたか？

2016年の東京からパリへのフライト中にRustの書籍を読みました。C++に非常に慣れていたので、すべてのアイデアが私にとって非常に魅力的でした。私はすぐにexercism.ioのRustトラックを終え、IO、エラー管理、マルチスレッディングを伴う実際のプロジェクトでこの言語を試したいと思いました。どのプロジェクトを選ぶべきだったでしょうか？

当時、私はIndeedの検索品質チームで働いていました。私たちの検索エンジンはLucene 2.4をベースにしていました。検索エンジンを構築することは、検索エンジンに関する私の理解を試し、実際のプロジェクトでRustを試すための完璧な方法でした。

Rustはコードの整理方法に影響を与えましたが、アーキテクチャを形作ったとは言いません。Luceneこそが真のインスピレーションです。

Paul氏はLuceneの代替品を構築することを目指していたわけではありません。彼は、開発者が実際に所有できるほど小さなものを作ることを目指していました。彼はRustで5年間のC++よりも2週間で生産性が向上したと述べ、「他のどの言語でも経験したことのない、コードがバグっていないというレベルの自信」を経験したと語っています。

アーキテクチャ的には、TantivyはLuceneのモデルに従っています。つまり、サーバーではなくライブラリです。インデックス作成、圧縮、検索を処理しますが、分散とオーケストレーションはそれを埋め込むシステムに任せます。

特定のトレードオフや優先事項に焦点を当てましたか？

当初はプロジェクトを小さく、しかしモジュール化しておきたかったのです。バッテリーは含まれていますが、最小限です。

私のターゲットは、検索が製品の中心であり、市販のソリューション（Elasticsearchなど）を使用するのではなく、最終的には独自のエンジンを構築するような企業でした。通常、そのような企業はLucene、つまりJavaを使用する必要がありました。Tantivyがそれらの企業にとって良い代替手段になると考えました。

このため、Tantivyを機能豊富ではなく、小さくモジュール化しておきたかったのです。Tantivyがどれほど洗練されても、これらのユーザーは独自のトークナイザーや独自のクエリパーサーをプラグインできることを望むでしょう。

今日、Tantivyのユーザーはあらゆるサイズと形状です。ライブラリをシンプルに保つために、ニッチな機能を追加するPRを拒否することもありますし、それらの機能をTantivyの外部で実装できるようにするPRを好みます。しかし、一般的に、この原則は以前ほど強くはありません。

ベンチマークゲーム

Tantivyが他の検索エンジンと競争力があるだけでなく、多くの場合それを上回ることがすぐに明らかになりました。Tantivyは内部で、ターム辞書に有限状態トランスデューサ、逆インデックスにSIMDアクセラレーテッド圧縮、そしてメモリ使用量を驚くほど低く抑えるメモリマップドI/Oレイヤーを使用しています。その結果、利用可能なRAMよりも大きなインデックスを楽に処理できるライブラリが誕生しました。

IndeedのPaul氏の上司であるJason Wolfe氏は、TantivyがLuceneの2倍高速であることが多いことを示した再現可能なベンチマークスイートであるSearch Benchmark, the Game を作成しました。長年にわたり、このベンチマークは両プロジェクト間で本物の往復運動を引き起こしました。LuceneのコミッターであるAdrien Grand氏は、「Why is Tantivy Faster than Lucene?」とフォローアップ分析 を公開し、その後Luceneはギャップをほとんどの領域 で埋めるパッチを投入しました。

TantivyとLuceneの間のこの猫とネズミのゲームは続くと思いますか？

まず、そのベンチマークについて少し話しましょう。私たちはそれを正直で再現可能にしたく、Tantivyのパフォーマンスがどこで不足しているかを見つけるのに役立つように設計しました。

Luceneの開発者は純粋な好奇心を持ってこれに取り組みました。Adrien Grand氏（当時Elastic所属）とMike McCandless氏（Amazon）は、Luceneのパフォーマンスを改善する方法を調査するためにこれを使用しました。私たちは両プロジェクトの利益のためにコミュニケーションチャネルを開いたままにしていました。Tantivyに触発されたいくつかのパッチがLuceneに組み込まれました。その後、AdrienはLuceneの検索パフォーマンスを改善するための新しい最適化を見つけ続けました。彼は進捗状況を私たちと共有し、TantivyのGitHubにチケット を残しました。私たちはそれらを実装するのに遅れをとっています。今日、Luceneは多くの場所でTantivyを上回っています。全体として、両プロジェクトはこの協力から恩恵を受けました。

さて、この質問を少し乗っ取って、私の石鹸箱に飛び乗ります。ソフトウェアにおける競争の本質について、人々は間違った考えを抱くことがあります。もちろん、QuickwitとTantivyはElasticsearchとLuceneと競合するプロジェクトです。しかし、競争は確執に翻訳される必要はありません — 特にオープンソースでは。

Tantivyを通じて、私は多くの企業と交流してきました。そのかなりの数が、「成功するまで偽装しろ」という格言を、ちっぽけさと偽善の文化に変えています。私はLuceneとElasticがどれほど特別であるか、そして彼らと競争できたことがどれほど幸運であったかを本当に感謝しています。

オープンソースの生活

オープンソースの検索空間がどれほど部族主義的になるかを考えると、Paul氏のLuceneへの敬意は際立っています。しかし、オープンソースには独自の課題が伴います。Tantivyの採用が拡大するにつれて、その維持の重さも増しました。

Tantivyの規模のオープンソースプロジェクトを維持するのは簡単ではありません。その成長を導く上で最も困難だった課題は何ですか？

貢献をレビューすること、そして時にはそれらを断ることは、最も難しい部分だと思います。私はオープンソースとプロプライエタリの両方のコードをたくさんレビューします。PRをマージすべきか、改善すべきか、あるいは却下すべきかを決定するのは非常に困難です。多くの貢献者はオープンソースに貢献するというアイデアに興奮しており、実際の問題を解決しない機能、Tantivyの外部に保持されるべき機能、過剰な複雑さを導入する機能、あるいは単に品質が不十分な機能などを提出する可能性があります。

コードをレビューするたびに、私は以下のように引き裂かれます。

• プロジェクトがひどい状態に漂流するのを防ぐ責任
• 人々を喜ばせたいという願望
• Quickwitの利益
• ニヒリストの論文：結局のところ、コードの品質は主観的です
• 時間管理とコンテキストスイッチに必要なエネルギー

Quickwitが買収されて以来、PRをレビューするための時間とエネルギーを見つけることがさらに困難になりました。多くの開発者と同様に、私は複数の問題を並行して処理することに苦労しており、Datadogでの私の仕事はすでにその点で非常に挑戦的です。

その緊張にもかかわらず、Tantivyを取り巻くエコシステムは、Paul氏が当初設計したものを超えるものに成長しました。彼がLuceneから借用したライブラリのみのアーキテクチャは、その最大の資産であることが証明されました。Tantivyはインデックス作成と検索を処理しますが、ノード間でどのようにシャード化、レプリケート、調整するかについては沈黙しているため、下流のプロジェクトはそれを根本的に異なる方法でラップできます。独自の検索エンジンを構築したい企業向けのライブラリとして始まったものが、現在ではスケーラブルなログ検索、タイプミス許容ルックアップ、エッジデータベース、Postgres内のトランザクション検索など、非常に異なる目標を持つ製品の基盤となっています。

Tantivyは現在、Quickwit、LNX、ParadeDB、Tursoなどの基盤となっています。上流への貢献や設計アイデアの流れを見てきましたか？

誰かが、まるでどこからともなく、geo search のサポートを貢献しました。これは私たちがしばらく追加したかったものです。PRは大きいですが、その品質は非常に印象的です。最終的にマージする時間が見つかることを願っています。

ParadeDBも最近、素晴らしいPRと深いアイデアを積極的に貢献しています。

Tantivyの物語は飛行機の中のあなたから始まりましたが、長年にわたって多くの人々が関わってきました。あなたのビジョンを形作るのに貢献した他の人は誰ですか？

まず、仲間のQuickwiotsです！特に、Pascal (@pseitz) と Trinity (@trinity-1686a) はTantivy自体に強い影響を与えたでしょう。Quickwitの外では、最近Stu (@Stuhood) が非常に影響力がありました。Harrison (@ChillFish8) も思い浮かびます。しかし、Evance、Pasha、Shikhar、Druなど、多くの他の人々も助けてくれました。

フランスには「無名戦士の墓」という記念碑があります。アイデア、良い言葉、質問への回答を提供して貢献し、そして姿を消す大勢の人々を祝うべきです。彼らの流れは、特に初期において、プロジェクトを存続させました。

Quickwitまで質問を広げると、私はAdrien とアーキテクトキャップを共有し、Francois がプロダクトオーナーでした。

Tantivyの採用があなたを驚かせたことはありますか？それが「成功した」と気づいた瞬間はありましたか？

Tantivyの採用はゆっくりと着実です。それは私の娘の成長を見守るようなものです。私の両親は彼女を見るたびに驚きますが、私は彼女の成長を「見ません」。彼女が私が聞いたことのない言葉を使ったり、私には新しい考えを表現したり、新しいことに興味を持ったりする時に気づきます。

Tantivyにとって、本当の兆候はエキゾチックなバグレポートです。例えば、誰かが64ビットナノ秒の日時表現でのオーバーフローを報告しました。彼らはSF文学のイベントをインデックス化していました。

Quickwit

作成者が完全に追跡できなくなったライブラリは、通常、物語が次の展開を迎える時点です。Paul氏にとって、その展開はQuickwitでした。アプリケーション内の検索を支える同じ技術が、オブジェクトストレージから直接実行されるインフラストラクチャスケールで動作するように再考できるという賭けでした。

Tantivyを構築した後、2020年にQuickwitを共同設立しました。当初のビジョンは何でしたか？市場でどのようなギャップを見ましたか？

当初のビジョンは実際には非常に異なっていました。Indeedで使っていた、信じられないほど強力なリアルタイムの大規模な検索ベースの分析ツールがありました。私たちは同様の体験を再現したいと考えていました。

それを構築し始めると、従来の検索エンジンがS3から実行するのに完全に適していることに気づいたため、S3上でログ検索エンジンを構築することに機会主義的にピボットしました。

このピボットは、見過ごされやすい詳細ですが、Paul氏の働き方について重要なことを示しています。ロードマップではなく、アーキテクチャに従うのです。基盤となるテクノロジーが興味深い場所を指しているなら、そこへ行きましょう。

オープンソースライブラリの維持からスタートアップの運営への移行はどのようなものでしたか？

私にとって、移行は思ったほど過酷ではありませんでした。最初の2年間、Quickwitは「コードを書くだけ」の会社に非常に近いものでした。誰もが非常に自己駆動型だったので、管理はほとんど、あるいは全く必要ありませんでした。マーケティングについては、質の高いエンジニアリングブログ記事をいくつか書くことが私たちにとって正しいアプローチであるとすぐに発見しました。

最も困難だったのは、リモートワークの孤立に対処し、異なるタイムゾーンをまたぐ会議を受け入れなければならなかったことです。私は日本に住んでいたので、午前8時か午後11時に会議があるのは普通でした。どちらにも慣れることはありませんでした。

初期の頃、QuickwitはBinanceのようなヘビーヒッターに採用され、1日あたり1.6 PBをインデックス化する100 PBのログ検索サービスを構築しました。大規模ユーザーとの作業はQuickwitのロードマップにどのように影響しましたか？

Binanceは最終的に契約に署名する用意があることを示唆しましたが、実際には署名しませんでした。私たちはすでに同様の企業で指を火傷しており、署名済みの契約が得られるまで、彼らの機能リクエストを優先すべきではないことを知っていました。私たちは彼らが報告したスケール上のロードバンプを修正しただけです。あまりにもエキゾチックなワークロードに特化していない限り、バグレポートは常に歓迎します。

Mezmoは私たちのロードマップに最も影響を与えた企業です。彼らは私たちに多大な信頼を寄せ、彼らの製品のために機能を開発する契約に署名しました。その影響は全体的に私たちのロードマップにプラスとなり、実装を延期していた機能を、難しすぎると判断していたにもかかわらず、実装するように促しました。

しかし、一つの機能、すなわち取り込みAPIは、速すぎたため実装され、彼らの特定の要件に合うように構築されました。私たちは今日でも、その一つで蓄積した技術的負債に苦しんでいます。

Datadog

2024年までに、QuickwitはTantivyベースのインフラストラクチャが本番ワークロードを真剣なスケールで処理できることを証明しました。チームはシリーズAの資金調達を準備していましたが、Datadogから声がかかり、資金調達ラウンドでは得られないもの、すなわち世界最大級のオブザーバビリティワークロードへの即時アクセスを提供されました。

DatadogがQuickwitにとって適切な場所となった理由は何ですか？

正直に言うと、これは非常に難しい決断でした。期待していた一つの利点は、私たちの技術がさらに多くの企業に、さらに大きなスケールで提供できるようになることでした。

TantivyとQuickwitをオープンソースとして維持するというコミットメントを確保するのは難しかったですか？

DatadogはQuickwitをApacheライセンスに変更することを提案しました。これにより、4社（おそらくそれ以上）の企業がQuickwitを中心に製品を構築できるようになりました。

とはいえ、Datadogで構築している製品はオープンソースではありません。私たちはすべての改善をQuickwitにプッシュし、Datadog固有のコードを持つプライベートフォークを維持しています。それ以外では、製品の議題に沿っていないサポートや貢献に対処する多くの時間を割く余裕はありません。

これは実用的な取り決めであり、買収基準では寛大なものです。オープンソースプロジェクトはオープンなままで、プロプライエタリ製品はプロプライエタリなままで、その間の線は明確です。さらに興味深いのは、Datadogのスケールでの作業が、Paul氏の検索自体に関する考え方をどのように再形成したかということです。

より大きなプラットフォーム内で検索に取り組むことで、あなたの視点は変わりましたか？その作業の一部はTantivyにフィードバックされましたか？

コラム型データベースと検索エンジンの間の壁は完全に人工的なものであると、私はかつてないほど確信しています。

私たちはDatadogの顧客から観察されたワークロードによって動機付けられた、Tantivyへのいくつかの大規模な最適化とQuickwitの安定性の向上をプッシュしました。一般的に、可能な限り、すべての変更をTantivyとQuickwitのオープンソースプロジェクトにプッシュします。

開発者へのアドバイス

フロントエンドエンジニアとしてのフラストレーションから、世界中の企業で利用される検索インフラストラクチャの作成者へと至るPaul氏の軌跡は、多くの意味で、「解決済み」の問題を見て、それがそうではないと決断した人物の物語です。私たちは、同じことをしたいと考えている開発者に何を伝えるかという質問で締めくくりました。

2016年に辞書検索とBM25の分野を見ていたら、それは解決済みで、追いつくのはほぼ不可能だと言ったでしょう。あなたはそうではないことを証明しました。解決済みの問題空間を新鮮な目で覗き込んでいる開発者に、どのようなアドバイスをしますか？

学術界に目を光らせてください。新しいアイデアはしばしばそこから生まれますが、私たちの助け — そして私たちの汗 — なしには業界には浸透しません。

システムがどのように機能するかについてのメンタルモデルを洗練し続けてください。ソフトウェアは抽象化のマトリョーシカ人形のコレクションです。これらの抽象化を特定し、それらを研究してください。それはあなたをより良い開発者にするでしょう。あなたはあなた自身が美しい抽象化を構築し始めるでしょう。しかし、抽象化が漏れる場所には多くの価値があることに気づくでしょう。

そして、業界がなぜ特定のソリューションに収束したのかについて、批判的な見方を保ってください。おそらくあなたの問題は、バニラソリューションに合わないほどユニークです。あるいは、ハードウェアとソフトウェアが今日とは非常に異なっていた過去に、業界が選択をしたのかもしれません。