Googleが非常に高速にクエリを処理できるようにするテクノロジーとプログラミングの決定は何ですか？
私は何かを検索するたびに（1日に数回のうちの1つ）、1秒近くまたは1秒未満で結果を提供する方法をいつも驚かせます。これを実現するために、どのような構成とアルゴリズムを導入できますか？
補足：デスクトップアプリケーションを置いて自分のマシンで使用したとしても、おそらくGoogleの半分の速度ではないと考えるのは、圧倒的な考え方です。私が言うことを学び続けなさい。
提供されたすばらしい答えとポインタのいくつかを以下に示します。
回答:
レイテンシはディスクアクセスによって強制終了されます。したがって、クエリに応答するために使用されるすべてのデータがメモリに保持されていると信じることは合理的です。これは、数千のサーバーがそれぞれに多くのシャードの1つを複製することを意味します。したがって、検索のクリティカルパスが、GFS、MapReduce、BigTableなどの主要な分散システムテクノロジーにヒットする可能性はほとんどありません。これらは、クローラーの結果を大まかに処理するために使用されます。
検索の便利な点は、強い整合性のある結果や完全に最新のデータを持つ必要がないため、より最新の検索結果が利用可能になったため、Googleがクエリに応答するのを妨げられないことです。
したがって、可能なアーキテクチャは非常に単純です。フロントエンドサーバーがクエリを処理し、正規化して（ストップワードを削除するなどして）、クエリスペースのその部分を所有するレプリカのサブセットに分散します（別のアーキテクチャは、すべてのレプリカセットの1つにクエリごとにアクセスする必要があるように、Webページごとにデータをアップします。多くの場合、多くのレプリカが照会され、最も速い応答が優先されます。各レプリカには、ドキュメントへのインデックスマッピングクエリ（または個々のクエリ用語）があり、メモリ内の結果を非常にすばやく検索するために使用できます。異なるソースから異なる結果が返された場合、フロントエンドサーバーは、htmlを吐き出すときにそれらをランク付けできます。
これはおそらくGoogleが実際に行うこととはかなり異なることに注意してください。これらのシステムは、このシステムの寿命を設計しているので、奇妙な領域、奇妙なインデックス、および他の考えられる違いの中である種のファンキーなロードバランシングスキームがある可能性があります。 。
1つの答えに入れるには少し多すぎます。 http://en.wikipedia.org/wiki/Google_platform
私が面白くないと思った1つの事実は、Googleが実際にバイオインフォマティクスによって運営されているということです（そうですね、私はbioinfだ... 説明させてください。
初期のバイオインフォマティクスでは、巨大な文字列内の小さなテキストを非常に高速に検索するという課題がありました。私たちにとって、「巨大なひも」はもちろんDNAです。多くの場合、単一のDNAではなく、異なる種/個体からのいくつかのDNAのデータベースです。小さなテキストは、タンパク質またはその遺伝的対応物である遺伝子です。計算生物学者の最初の研究のほとんどは、遺伝子間の相同性を見つけることに限定されていました。これは、既知の遺伝子との類似性に注目することにより、新たに発見された遺伝子の機能を確立するために行われます。
現在、これらのDNAストリングは非常に大きくなり、（損失！）検索は非常に効率的に実行する必要があります。したがって、文字列ルックアップの現代の理論のほとんどは、計算生物学のコンテキストで開発されました。
しかし、かなり前に、従来のテキスト検索は使い果たされていました。大きな文字列を準線形時間で検索できるようにする、つまり各文字を1つずつ確認する必要がない新しいアプローチが必要でした。これは、大きな文字列を前処理し、その上に特別なインデックスデータ構造を構築することで解決できることが発見されました。多くの異なるそのようなデータ構造が提案されてきた。それぞれに長所と短所がありますが、一定の時間で検索できるため、特に注目すべきものがあります。現在、Googleが運用している規模では、これは厳密には真実ではありません。サーバー間でのロードバランシング、前処理、およびその他の高度な処理を考慮する必要があるためです。
しかし、本質的には、いわゆるq-gramインデックスを使用すると、一定の時間で検索できます。唯一の欠点：データ構造が途方もなく大きくなる。基本的に、までを含む文字列の検索を可能にするために、Qの文字（名前）、それはそれぞれの可能な組み合わせのための一つのフィールドを持つテーブルが必要ですQのある文字（、q個のS、Sをアルファベットのサイズですが、たとえば36（= 26 + 10））とします。さらに、インデックス付けされた文字列の各文字位置（またはGoogleの場合は各Webサイト）ごとに1つのフィールドが必要です。
純粋なサイズを軽減するために、Googleはおそらく複数のインデックスを使用します（実際には、スペル修正などのサービスを提供するために使用します）。最上位のものは文字レベルでは機能せず、代わりに単語レベルで機能します。これによりqは減少しますが、Sが無限に大きくなるため、ハッシュと衝突テーブルを使用して無数の異なる単語に対処する必要があります。
次のレベルでは、これらのハッシュ化された単語は他のインデックスデータ構造を指し、次に、ウェブサイトを指す文字をハッシュします。
要するに、これらのq -gramインデックスデータ構造は、おそらくGoogleの検索アルゴリズムの最も中心的な部分です。残念ながら、q - gramインデックスがどのように機能するかを説明する非技術的な論文はありません。そのようなインデックスがどのように機能するかについての説明が含まれている私が知っている唯一の出版物は、悲しいことに、私の学士論文です。
提供されたすばらしい答えとポインタのいくつかを以下に示します。
彼らは、膨大な量のハードウェア上で実行される優れた分散型アルゴリズムを実装しています。
彼らは、インターネットのローカルコピーをカスタムファイルシステム上の何千ものPCにキャッシュしています。
グーグルリサーチのホームページで、グーグルの人たちが書いたリサーチペーパーについてのポインタを見つけることができます。googleファイルシステムの説明とmap / reduceアルゴリズムから始めて、googleページの背後で何が行われているのかを理解する必要があります。
このリンクはまた、グーグルクエリの舞台裏で非常に有益です
HenryRはおそらく正しいです。
Map Reduceは検索自体には役割を果たしませんが、索引付けにのみ使用されます。Map Reduceの発明者とのこのビデオインタビューをチェックしてください。
追加の理由は、TCPスロースタートアルゴリズムをだますことです。
http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html
そして、そのハードウェア能力を利用できるアルゴリズム。同様のMapReduce例えば。
Googleクラスターがどのように機能するかについて詳しく知りたい場合は、HDFSのこのオープンソース実装をお勧めします。
それはグーグルによるMapreduceに基づいています。
多段階のデータ保存、処理、検索
上記のタスクの効率的な分散（数千から数百のマシン）
生データと処理結果を保存するための優れたフレームワーク
結果を取得するための優れたフレームワーク
これらがどのように正確に行われるかは、質問の要約にあるすべてのリンクによって要約されます