どうやら BigTable アーキテクチャの理由は、Google が対処しなければならない膨大な数のサーバーを扱う場合に、リレーショナル データベースをスケーリングするのが難しいことに関係しています。
しかし、技術的に言えば、リレーショナル データベースの拡張が困難な理由は何でしょうか?
大企業のエンタープライズ データ センターでは、これをうまく実行できるように見えるので、Google のサーバーでスケーリングするために、これをより大きな規模で単純に実行できないのはなぜだろうかと思っています。
物理的に分散された関係を含むクエリを実行する場合、関係ごとにそのデータを中央の場所にプルする必要があります。これは明らかに、大量のデータに対して適切に拡張できません。
適切に設定されたRDBMSサーバーは、RAM内のホットページでクエリの大部分を実行し、物理ディスクやネットワークI/Oはほとんどありません。
ネットワークI/Oに制約がある場合、リレーショナルデータのメリットは少なくなります。
Mitch の答えに加えて、もう 1 つの側面があります。一般に、Web アプリケーションはリレーショナル データベースにはあまり適していません。リレーショナル データベースは、正規化に重点を置いています。つまり、基本的に、書き込みは簡単になりますが、読み取りは難しくなります (完了した作業に関しては、必ずしも必要ではありません)。これは、OLAP のアドホック クエリ タイプの状況では非常にうまく機能しますが、一般に書き込みよりも読み取りが優先される Web アプリケーションではうまく機能しません。
Bigtable などの非リレーショナル データベースで採用されている戦略は逆です。つまり、非正規化により、読み取りがはるかに簡単になりますが、書き込みのコストが高くなります。
前述の主な理由は、物理的な場所とネットワーク IO です。さらに、大企業でさえ、検索エンジンが扱うデータのほんの一部しか扱っていません。
標準データベースのインデックスについて考えてみてください。おそらくいくつかのフィールドです... 検索エンジンは、大きなテキスト フィールドで高速なテキスト検索を必要とします。