巨大なデータベースへのクエリは、無視できるほどの待ち時間でどのように返されますか?


12

たとえば、Googleで何かを検索すると、結果はすぐに返されます。

Googleがアルゴリズムなどを使用してページをソートおよびインデックス付けすることを理解していますが、考えられるすべてのクエリの結果にインデックスを付けることは不可能だと思います(結果はパーソナライズされ、これによりさらに実行不可能になります)?

さらに、Googleのハードウェアのハードウェアレイテンシは巨大ではないでしょうか。GoogleのデータがすべてTB / s SSDに保存されていたとしても、処理するデータの量が膨大であることを考えると、ハードウェアのレイテンシは非常に大きくなると思います。

MapReduceはこの問題の解決に役立ちますか?

編集:さて、私は人気のある検索がメモリにキャッシュできることを理解しています。しかし、不人気な検索はどうですか?私が行った最もあいまいな検索でさえ、検索が5秒を超えると報告されたことはないと思います。これはどのように可能ですか?

回答:


13

まあ、問題を解決するのがMapReduceであるかどうかはわかりませんが、あなたが提起したこれらの質問をすべて解決するのは、MapReduceだけでは間違いないでしょう。しかし、ここで考慮すべき重要な点があります。これにより、さまざまなマシンのこれらすべてのTBのデータからのクエリのレイテンシをこのように低くすることが可能になります。

  1. 分散コンピューティング:分散されているということは、インデックスが単に異なるマシンに分散されているという意味ではなく、実際には異なるクラスターに沿って複製されるため、多くのユーザーが短いクエリ時間でさまざまなクエリを実行できます(そうです、巨大な企業はそれだけの余裕があります)マシンの);
  2. キャッシング:キャッシュは、クロールステップ、ページの取得、または結果のランキングと表示のために、実行時間を大幅に削減します。
  3. たくさんの微調整:上記のすべてと非常に効率的なアルゴリズム/ソリューションは、実装も効率的である場合にのみ効果的です。参照の局所性、圧縮、キャッシングなど、大量の(ハードコードされた)最適化があります。それらのすべては通常、処理のさまざまな部分に適用できます。

それを考慮して、あなたの質問に取り組みましょう:

しかし、考えられるすべてのクエリの結果にインデックスを付けることは不可能だと思います

はい、あり得ます。実際には、考えられるすべてのクエリに対して結果を得るのは不可能です。世界には無数の用語があり(適切なスペルの用語のみが入力されると仮定した場合でも)、これらのn -> inf用語からのクエリの指数関数的な数があります(2^n)。それで、何が行われますか?キャッシング。しかし、非常に多くのクエリ/結果がある場合、どれをキャッシュするべきですか?キャッシュポリシー。最も頻繁な/人気のある/ユーザーに関連するクエリは、キャッシュされたクエリです。

Googleのハードウェアのハードウェアレイテンシは巨大ではないでしょうか。GoogleのデータがすべてTB / s SSDに保存されていたとしても

今日、このような高度に発達したプロセッサーを使用する場合、1秒以内に完了する必要があり、大量のデータを処理するすべての可能なタスクは、複数のコアと大量のメモリを備えた非常に強力なプロセッサーで処理する必要があると考える傾向があります。しかし、支配市場の一つはお金であり、投資家はそれを無駄にすることに興味がありません。それで、何が行われますか?

実際には、多くのマシンがあり、それぞれがシンプル/アクセス可能な(コストの観点から)プロセッサーを使用しているため、多数のクラスターを構築するコストが低くなります。そして、はい、それは動作します。パフォーマンスの単純な測定を考えると、主なボトルネックは常にディスクに集約されます。しかし、マシンが非常に多くなると、ハードディスクで作業する代わりに、メインメモリにロードする余裕ができます。

メモリーカードは私たちにとって、単なる人間にとっては高価ですが、そのようなカードを一度にたくさん購入する企業にとっては非常に安価です。コストがかからないので、インデックスをロードしてキャッシュを手元に保持するために必要なだけのメモリがあっても問題ありません。非常に多くのマシンがあるので、あなたが別の場所へのクエリを指示し、出席を担当するマシンのクラスタ持つことができるように、超高速プロセッサの必要がないため、特定の地理的領域をより多くすることができます、専門のデータキャッシュ、およびより良い応答を回。

MapReduceはこの問題の解決に役立ちますか?

MapReduceの使用がGoogle内の制限された情報であるとは思わないが、私はこの点に精通していません。ただし、GoogleのMapReduce(確かにHadoop ではない)の実装には、多くの最適化が必要です。そのため、MapReduceのアーキテクチャは、計算が物理的にどのように分散されるかをガイドするのにおそらく役立ちますが、クエリ時間のそのような速度を正当化するために考慮すべき他の多くのポイントがあります。

さて、私は人気のある検索をメモリにキャッシュできることを理解しています。しかし、不人気な検索はどうですか?

次のグラフは、クエリの種類がどのように発生するかを示しています。検索には3つの主要な種類があり、それぞれがクエリのボリュームの約1/3(曲線の下の領域)を保持していることがわかります。このプロットはべき乗則を示しており、小さいクエリが最も人気があるという事実を強調しています。クエリの2/3は、単語数が少ないため、まだ処理可能です。ただし、通常は経験のないユーザーのクエリで構成される、いわゆるあいまいなクエリのセットは、クエリの一部として無視できません。

ヘビーテール分布

そして、新しいソリューションのためのスペースがあります。これは1つまたは2つのクエリではない(ただし、その3分の1)ため、関連する結果が必要です。Googleの検索であまりにあいまいなものを入力しても、結果のリストが返されるまでに時間がかかることはありませんが、おそらくあなたが言いたいと思われる何かが表示さます。または、そのような用語を含むドキュメントがないと単に記載している可能性があります-または、検索を32ワードに削減しました(これは、ランダムなテストで私に起こっただけです)。

いくつかの適用可能なヒューリスティックがあり、いくつかの単語を無視するか、クエリをより小さなものに分割して、最も人気のある結果を収集します。そして、これらすべてのソリューションは、たとえば1秒未満の実現可能な待機時間を尊重するように調整および調整できますか?:D


質問を編集して別のクエリを追加しました。
2014年

@namehere私はあなたの編集に対処しようとしました。質問への回答に役立つことを願っています。
ルーベンス2014年

10

MapReduceは、リアルタイムのものとは何の関係もありません。これは、ETLやインデックスの構築など、一部のオフラインタスクに適したバッチ指向の処理フレームワークです。Googleは現在、ほとんどの仕事でMapReduceから離れており、Hadoopエコシステムでさえ同じことをしています。

低レイテンシへの答えは、通常、事前に計算されたインデックスをメモリに保持することです。ディスクに触れるものはどれも、高速化と拡張が困難です。これは、Impalaなどの新世代のHadoopベースのSQLエンジンが、HiveなどのMapReduceベースのインフラストラクチャと比較して非常に高速になる方法です。

検索インフラストラクチャは、すべてのクエリの結果をキャッシュすることはできません。ただし、中間結果、または上位クエリのより完全な結果を確実にキャッシュできます。少しのキャッシングで、すべてのクエリのかなりの少数に対して結果を提供できます。

検索もサーバー間で分割されます。したがって、1台のマシンが100に委任して、それぞれが結果の一部を取得し、それらを組み合わせることができます。

また、ある程度の近似を回避することもできます。グーグルは文字通り千ページの検索結果を形成することはありません。それはちょうど最初のページを適切にするだけです。

Googleには世界中に数百万台のコンピュータがあることに注意してください。クエリは地理的に近くのデータセンターに送信され、地理情報のみを提供しています。これにより、ネットワークであり、データセンターでの処理時間ではない、ほとんどの遅延が削減されます。


まず、質問を編集して別のクエリを追加しました。また、重要な少数派が事前に計算されていても、残りのクエリは完了するまでに長い時間がかかるはずです。さらに、プロセスが1台のマシンから100台のマシンに委任されている場合、レイテンシは実際に増加していませんか(マシン間のネットワークレイテンシであり、合計レイテンシはすべてのマシンのレイテンシの最大です)?
2014年

つまり、「spaghetti diamond」というクエリは、珍しい珍しいクエリですが、「spaghetti」と「diamond」の事前に計算された結果によって高速に処理される可能性があります。DC内接続は、非常に高速で低遅延です。コンピュータとDCの間の最大20ホップと比較して、内部に余分な1ホップまたは2ホップはありません。作業の分配における支配的な問題はストラグラー問題です。サブセットが時間内に応答しない場合は、サブセットから結果をドロップする必要があります。これらはすべて全体的な一般化ですが、正しい方向を指しています。
Sean Owen

4

MapReduceは検索では使用されません。索引を作成するためにずっと前に使用されました。しかし、これはバッチ処理フレームワークであり、ほとんどのWebは常に変更されるわけではないため、新しいアーキテクチャはバッチ指向ではなく、すべてインクリメンタルです。

Googleの検索は、LuceneやElastic Searchとほぼ同じように機能しますが、微調整された追加の重み付けと最適化が多数行われています。しかし、核心では、何らかの形式の逆インデックスを使用します。つまり、検索クエリを入力しても、キャッシュされていなくても数テラバイト検索されません。彼らはおそらく実際の文書をまったく見ていません。ただし、検索語に一致するドキュメントをリストするルックアップテーブルを使用します(ステミング、スペルミス、シノニムなどがすべて前処理されています)。彼らはおそらく、各単語の上位10000のドキュメントのリスト(10kの整数-ほんの数kb!)を取得し、そこから最適な一致を計算します。これらのリストに適切な一致がない場合にのみ、次のブロックなどに展開されます。

一般的な単語のクエリは簡単にキャッシュできます。また、前処理を介して上位10kの結果のリストを作成し、ユーザープロファイルに従ってそれらを再ランク付けできます。「正確な」答えを計算しても得られることは何もありません。上位10kの結果を確認するだけで十分です。正解はありません。そして、10001の位置のどこかでより良い結果が見逃された場合、だれも知ることも、気づくことも(気にすることも)ありません。前処理ですでにランクダウンされている可能性が高く、最後にユーザーに表示されるトップ10(またはユーザーが実際に見るトップ3)にはなっていません。

一方、まれな用語もそれほど大きな問題ではありません。リストの1つには一致するドキュメントがいくつかしか含まれておらず、他のすべてをすぐに破棄できます。

この記事を読むことをお勧めします:

大規模なハイパーテキストウェブ検索エンジンの構造
セルゲイブリンアンドローレンスページ
コンピューターサイエンス部、スタンフォード大学、カリフォルニア州スタンフォード94305
http://infolab.stanford.edu/~backrub/google.html

そして、はい、これを書いたのはGoogleの創設者です。これは最新の状態ではありませんが、かなり大規模で動作します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.