Twitter：1日あたり10億のリクエストと新しい検索エンジン

現在、Twitterサーバーの負荷は1000 TPS（1秒あたりのツイート数）と12000 QPS（1秒あたりの要求数）に増加しています-1日あたり10億件を超えています。 現在のインフラストラクチャーはまだ残っていますが、数年先の予備金を確保するために、同社は検索エンジンのバックエンドを更新することにしました。 「うまくいけば、ここ数週間で何も気付かないはずだった」とTwitter開発者のブログは語った。



最近まで、Twitter検索バックエンドは古いSummize SQLシステムに基づいていました。 これらの目的のためだけに2008年7月に購入され、6人の開発者のうち5人を取りました。 Twitterをアップグレードする必要性は、iPhone 3Gの発表直後に明らかになり、Summizeとの協力が始まりました。 しかし、今度は再び更新する時が来ました。



約6か月前、リレーショナルデータベースの代わりに効果的な逆インデックスに基づいた新しい最新の検索アーキテクチャを開発することが決定されました。 Twitterはオープンソースを好むため、Javaで記述されたApache Lucene検索ライブラリをソリューションの出発点として選択しました。



新しい検索エンジンの要件は、優れたスケーラビリティと最大インデックス作成速度でした。 タスクは、ツイートの公開から全文検索の可能性まで、10秒以内に渡されるように設定されました。 インデクサーはこのパスに沿ったパイプライン全体の一部に過ぎないため、可能な限り迅速に（1秒未満で）動作するはずです。



目標を達成するために、Luceneはリアルタイム検索エンジンにはあまり適していないため、少しやり直さなければなりませんでした。 メモリ内の主なデータ構造、特にポストリストが書き直されましたが、同時に標準Lucene APIのサポートが保持されたため、ライブラリの検索部分をやり直す必要はほとんどありませんでした。 変更による主な利点は次のとおりです。



*ガベージコレクションのパフォーマンスを大幅に改善

*データ構造とノンブロッキング同期アルゴリズム（ロックフリー）

*逆順で実行できるポストリスト

*初期段階でのリクエストの効果的な終了



開発者自身によると、使用されているメソッドの一部は（検索の分野だけでなく）他のプログラマーにとって興味深いものであり、今後のトピックのより詳細な議論が可能になる可能性があります。



いずれにしても、Luceneに加えられたすべての変更はApacheに送信され、一部はすでにメインのLuceneコードとリアルタイム検索用の新しいブランチに含まれています。



検索インフラストラクチャのアップグレードの結果、バックエンドの負荷が大幅に削減されたため（現在ではリソースの5％しか占めていません）、将来のために十分な余裕があります。 新しいインデクサーは、今日公開されているツイートの1秒あたり約50倍のツイートをインデックスに登録できます。 また、新しい検索エンジンは、文句なしに完全に安定して動作します。



Twitter検索エンジンの不快な瞬間の1つは、数日以上ツイートのアーカイブを検索できないことでした。 彼らはこれを「スペース不足」に帰した 。 この制限を回避するには、ツイート（たとえばTopsy）を独立してインデックス付けするサードパーティの検索エンジンを使用する必要があります。



Danny Sullivanは2010年1月14日に[今日]という単語で検索結果をチェックし、 7日前に投稿された最も古いツイートを見つけました。



9月中旬に行われた同様のテストでは、インデックスの深さが4日間に短縮されたことが示されました。



新しい検索の導入により、「検索クエリの速度に影響を与えることなくインデックスが2倍になった」ことが発表されました。 どうやら、我々は同じ7日間の制限への復帰について話している。