GitHubはコード検索機能を全面改修している。高速・高性能かつコードが理解しやすいように刷新された検索インターフェイスと新しいコードビューを備えた新しいコード検索機能はスクラッチで開発された、とGitHubソフトウェアエンジニアColin Merkel氏は述べている。
新しいコード検索とコードビュー機能は、開発者がコードを素早く検索して理解できること、重要な情報をコンテキストに置き換えること、最終的に生産性を向上させることを目標としています。
同氏によると、新しい検索エンジンは以前に比べて2倍の速さになったという。また部分文字列クエリや正規表現、シンボル検索がサポートされ、柔軟な検索が可能になった。例えば、ある文字列を検索する際、事前にリポジトリのクローンを作らなくても、組織に属するすべてのリポジトリを横断して検索ができる。
org:my_org "string to look for"
また特定のプログラム言語やリポジトリで書かれたファイルでフィルタリングしたり、特定のパスを除外したり、GitHubの検索クエリ構文でサポートされている多くのクエリ構文を使用できる。
新しいコードビューは、検索結果とファイルブラウザを統合し、コードのナビゲーションとブラウジングをサポートしている。自動的に認識された言語のシンボルをクリックすると該当のコードページにジャンプできるのだ。そして、10以上のプログラム言語のシンボルをサポートしている。
GitHubのエンジニアであるTimothy Clem氏は、柔軟性やパフォーマンス、スケーラビリティ、それぞれの面で、新しい検索エンジンが舞台裏でどのように機能しているかを詳細に説明した。
GitHubの検索エンジンの中心には、クエリを高速に実行するための前提条件となる強力なインデクサがある。例えばプログラミング言語を区別できる、句読点を無視しない、ストップワードを除去しないなど、検索インデックスはコードに特化したものとなっている。また部分文字列のクエリをサポートするために、インデックスにはngram、つまり与えられた長さの文字列が含まれていなければならない。
GitHubは4,500万のリポジトリを解析して検索インデックスを構築していて、それは155億文書に及ぶ115TBのコンテンツに相当する。幸いなことにGitHubには作業量をスリム化するための2つのナレッジがある、とClem氏は説明する。1つはGitのblobオブジェクトIDを使ってユニークなドキュメントをシャードに均等に分配すること。2つ目はGitHubが多くの重複したコンテンツをホストしているという事実である。
新しいクエリを受け取ると、抽象的な構文木に解析され、検索クラスタ内の異なるシャードに送られるn個の同時リクエストに変換される。シャードは正規表現をngramインデックスの部分文字列クエリに変換するなどの低レベルの処理を実行する。最終的にシャードは結果をクエリサービスに返し、クエリサービスは結果を集約して上位100件を選択する。
個々のシャードからの99%のレスポンスタイムは100ms程度ですが、レスポンスの集約やパーミッションのチェック、シンタックスハイライトなどのため、トータルのレスポンスタイムはもう少し長くなります。クエリがインデックスサーバーの1つのCPUコアを100ミリ秒占有するため、64コアのホストでは、1秒間に640クエリ程度が上限となります。
このアプローチにより、GitHubは約18時間でリポジトリ全体のコーパスを再インデックス化できる。全体のインデックスサイズは25TBで、これは元データの約4分の1に相当である。
新しいコード検索機能はGitHubの全ユーザーに無料で提供されている。