Google BigTable や Amazon SimpleDB などの新しい学校のデータストア パラダイムは、特にスケーラビリティを考慮して設計されています。基本的に、結合の禁止と非正規化は、これを達成する方法です。
ただし、このトピックでは、大きなテーブルでの結合は必ずしも高価である必要はなく、非正規化はある程度「過大評価」されているというのがコンセンサスのようです。スケーラビリティを達成するために単一のテーブル？これらのシステムに格納する必要があるのは、膨大な量のデータ (数テラバイト) ですか?
データベースの一般的な規則は、これらの尺度には当てはまりませんか? これらのデータベースの種類は、多くの類似オブジェクトを格納するように特別に調整されているためですか?
それとも、全体像が欠けていますか？
分散データベースは、Orion が示唆するほど単純ではありません。分散データセットに対する完全なリレーショナル クエリの最適化に関して、かなりの作業が行われてきました。Teradata、Netezza、Greenplum、Vertica、AsterData などの企業が行っていることを調べてみてください。(最近の発表で、オラクルも最終的にゲームに参加しました。Microsoft は、以前は DataAllegro と呼ばれていた会社の名前でソリューションを購入しました)。
そうは言っても、データがテラバイトにスケールアップすると、これらの問題は非常に重要になります。RDBM から得られる厳密なトランザクション性と一貫性の保証が必要ない場合は、多くの場合、非正規化して結合を行わない方がはるかに簡単です。特に相互参照があまり必要ない場合。特に、アドホック分析を行っていないが、任意の変換によるプログラムによるアクセスが必要な場合。
非正規化は過大評価されています。100テラを扱っているときにそれが起こるからといって、データベースについて学ぶことを気にせず、スキーマ計画とクエリの最適化が不十分なために100万行または2行をクエリするのに苦労しているすべての開発者がこの事実を使用する必要があるという意味ではありません。 .
でも100テラ台ならぜひ…
ああ、これらのテクノロジーが話題になっているもう 1 つの理由は -- 人々は、そもそもデータベースに属していなかったものがいくつかあることを発見し、特定の分野の関係を扱っているのではなく、基本的な鍵を扱っていることに気付き始めていることです。値のペア。DB にあってはならないものについては、Map-Reduce フレームワーク、または何らかの永続的で最終的に一貫性のあるストレージ システムがまさにそれである可能性は十分にあります。
グローバル規模ではありませんが、この種の問題には BerkeleyDB を強くお勧めします。
私はそれらにあまり精通していません（私は他のみんなと同じブログ/ニュース/例を読んだだけです）が、スケーラビリティの名の下に通常のリレーショナルDB機能の多くを犠牲にすることを彼らが選んだというのが私の見解です-説明してみます。
データテーブルに200行あるとします。
googleのデータセンターでは、これらの行のうち50行がサーバーAに、50行がBに、100行がサーバーCに保存されています。さらにサーバーDにはサーバーAとBのデータの冗長コピーが含まれ、サーバーEにはサーバーCのデータの冗長コピーが含まれています。
（実際には、使用されるサーバーの数はわかりませんが、何百万もの行を処理するように設定されているため、かなりの数を想像します）。
「select*where name ='orion'」を実行するために、インフラストラクチャはそのクエリをすべてのサーバーに送信し、返される結果を集約できます。これにより、必要な数のサーバー間でほぼ直線的にスケーリングできます（参考までに、これはmapreduceとほぼ同じです）
ただし、これはいくつかのトレードオフが必要であることを意味します。
一部のデータに対してリレーショナル結合を実行する必要がある場合、たとえば5台のサーバーに分散している場合、これらのサーバーのそれぞれは、行ごとに相互にデータをプルする必要があります。10台のサーバーに200万行が分散している場合は、これを試してください。
これはトレードオフ＃1-結合なしにつながります。
また、ネットワークの遅延やサーバーの負荷などによっては、データの一部がすぐに保存される場合もありますが、1秒または2秒かかる場合もあります。サーバーが数十台ある場合、これはますます長くなり、通常のアプローチでは「誰もが最も遅い男が終わるまで待つだけです」はもはや受け入れられなくなります。
これはトレードオフ＃2-につながります-データは、書き込まれた直後に常に表示されるとは限りません。
他にどのようなトレードオフがあるかはわかりませんが、頭のてっぺんからそれらがメイン2です。
つまり、「非正規化、結合なし」の哲学全体が存在するということです。結合自体が大規模なシステムで拡張できないためではなく、分散データベースに実装することが事実上不可能だからです。
これは、単一タイプのほとんど不変のデータを保存している場合はかなり合理的なようです（Googleのように）。私はここで正しい方向に進んでいますか？
事実上読み取り専用のデータについて話している場合は、ルールが変わります。非正規化は、必要な作業が増加し、ロックに関する問題が増えるため、データが変更される状況で最も困難です。データがほとんど変化しない場合、非正規化はそれほど問題ではありません。
Novaday データベースの相互運用環境をもっと見つける必要があります。より頻繁に MySQL や MS SQL などのリレーショナル DB だけでなく、Hadoop や MongoDB などの非リレーショナル DB などのビッグ データ ファームも必要です。場合によっては、これらすべての DB が 1 つのソリューションで使用されるため、それらのパフォーマンスはマクロ スケールで可能な限り同等でなければなりません。つまり、たとえば Azure SQL をリレーショナル DB として使用できず、MongoDB 用に 2 コアと 3 GB の RAM を備えた 1 つの VM を使用できないということです。可能であれば、ソリューションをスケールアップし、DB as a Service を使用する必要があります (不可能な場合は、クラウド内に独自のクラスターを構築してください)。