orm - 参加のない生活...理解と一般的な慣行

Question

多くの「BAW」（big ass-websites）は、インデックス付きの巨大なテーブルに依存するデータストレージおよび取得技術を使用しており、クエリでJOINを使用しない/使用できないクエリ（BigTable、HQLなど）を使用しています。スケーラビリティとシャーディングデータベースを処理します。非常に関連性の高いデータがたくさんある場合、それはどのように機能しますか？

この結合の多くはアプリケーション側で行わなければならないと推測することしかできませんが、それは高価になり始めませんか？コンパイルする情報を取得するために、いくつかの異なるテーブルに対していくつかのクエリを実行する必要がある場合はどうなりますか？そもそも結合を使用するよりも、データベースに何度もアクセスする方がコストがかかり始めていませんか？どれだけのデータがあるかによると思いますか？

また、一般的に利用可能なORMの場合、結合を使用できないことにどのように対処する傾向がありますか？今日頻繁に使用されているORMでこれをサポートしていますか？または、このレベルのデータにアプローチする必要があるほとんどのプロジェクトは、とにかく独自にロールする傾向がありますか？

したがって、これは私が行っている現在のプロジェクトには当てはまりませんが、「ベストプラクティス」とは何かについてしか推測できないようになったため、数か月前から頭に浮かびました。必要な規模に達したことがないため、どのプロジェクトでもこれに対処する必要はありませんでした。うまくいけば、この質問は他の人にも役立つでしょう。

誰かが以下に言ったように、ORMは参加なしでは「機能しません」。このレベルのデータを扱う開発者がすでに利用できる他のデータアクセスレイヤーはありますか？

編集： いくつかの明確化のために、VinkoVrsalovicは言った：

「スニッカーは、トランザクションデータが非正規化されてHadoop、BigTable、またはCassandraスキームで使用されるNO-SQLについて話したいと思っています。」

これは確かに私が話していることです。

xkcdリファレンスをキャッチした人のためのボーナスポイント。

Answer 1

私の見方では、リレーショナルデータベースはあなたの賭けをヘッジするための汎用ツールです。最新のコンピューターは十分に高速であり、RDBMSは十分に最適化されているため、1つのボックスでかなりのサイズに拡張できます。RDBMSを選択することで、データへの非常に柔軟なアクセスと、データに対するコーディングをはるかに容易にする強力な正確性制約を持つ機能が提供されます。ただし、RDBMSは特定の問題に対する適切な最適化を表すものではなく、問題を簡単に変更できる柔軟性を提供するだけです。

急速に成長し始め、単一のDBサーバーのサイズを超えて拡張する必要があることに気付いた場合、突然、選択がはるかに困難になります。ボトルネックの特定と除去を開始する必要があります。RDBMSは、共依存関係の厄介な結び目であり、それをバラバラにする必要があります。データの相互接続が多ければ多いほど、より多くの作業を行う必要がありますが、すべてを完全に解きほぐす必要はないかもしれません。読み取りが多い場合は、単純なレプリケーションでうまくいくかもしれません。市場が飽和状態にあり、成長が横ばいになっている場合は、部分的に非正規化し、固定数のDBサーバーにシャーディングすることができます。たぶん、よりスケーラブルなデータストアに移動できる問題テーブルがいくつかあるだけです。

BigTableのようなスケーラブルなKey-Valueストアが登場するのは、上記のいずれも機能しない場合であり、単一タイプのデータが多すぎるため、非正規化された場合でも、単一のテーブルは1つのサーバーには多すぎます。この時点で、任意にパーティションを作成し、それにアクセスするためのクリーンなAPIを使用できる必要があります。当然のことながら、データが非常に多くのマシンに分散している場合、これらのマシンが相互に通信する必要のあるアルゴリズムを使用することはできません。これは、標準のリレーショナルアルゴリズムの多くで必要になります。ご提案のとおり、これらの分散クエリアルゴリズムは、適切にインデックス付けされたリレーショナルデータベースの同等のJOINよりも多くの合計処理能力を必要とする可能性があります。

これで、大量のデータセットを水平方向にスケーリングできるようになると（より多くのサーバーを接続するだけで）、スケーラビリティの難しい部分が完了します。この規模での継続的な運用と開発は単一サーバーアプリよりもはるかに難しいため、完了したとは言えませんが、要点は、アプリケーションサーバーは通常、シェアードナッシングアーキテクチャを介して拡張するのは簡単です。必要なデータをタイムリーに。

一般的に使用されるORMがJOINを使用できないことをどのように処理するかについての質問に答えるために、簡単な答えは、それらが使用しないことです。ORMはObjectRelationalMappingの略であり、ORMの仕事のほとんどは、述語ロジックの単純なオブジェクト指向データ構造の強力なリレーショナルパラダイムを変換することです。それらが提供するものの価値のほとんどは、Key-Valueストアからは不可能になります。実際には、特定のニーズに適した独自のデータアクセス層を構築して維持する必要があります。これらの規模のデータプロファイルは劇的に変化し、汎用ツールを出現させるにはトレードオフが多すぎると思われるためです。 RDBMSのように支配的になります。要するに、あなたは常にこの規模でより多くのレッグワークをしなければならないでしょう。

そうは言っても、Key-Valueストアプリミティブの上にどのような種類のリレーショナルまたはその他の集約機能を構築できるかを確認することは間違いなく興味深いでしょう。私はここで具体的にコメントするのに十分な経験を持っていませんが、これについては何年も前に遡るエンタープライズコンピューティングに関する多くの知識（例：Oracle）、学界における未開発の理論的知識、グーグル、アマゾン、フェイスブックなどですが、より広い開発コミュニティにフィルターされた知識はまだかなり限られています。

ただし、多くのアプリケーションがWebに移行し、世界中の人口のますます多くがオンラインになっているため、必然的にますます多くのアプリケーションを拡張する必要があり、ベストプラクティスが具体化し始めます。知識のギャップは、AppEngineやEC2などのクラウドサービスや、Cassandraなどのオープンソースデータベースによって、両側から縮小されます。ある意味で、これは並列および非同期の計算と密接に関連しており、これもまだ初期段階です。プログラマーになるのは間違いなく魅力的な時間です。

Answer 2

あなたは誤った仮定から始めています。

データウェアハウジングは、トランザクションアプリケーションが正規化するのと同じ方法でデータを正規化するわけではありません。「たくさんの」結合はありません。比較的少ないです。

特に、データウェアハウスが更新されることはめったにないため、2番目と3番目の正規形違反は「問題」ではありません。そして、それらが更新されると、通常、ディメンション行を「現在」と「現在ではない」として変更するのはステータスフラグの変更のみです。

更新について心配する必要がないので、更新が異常な関係につながることができない2NFレベルに物事を分解することはありません。更新がないということは、異常がないことを意味します。分解も結合もありません。すべてを事前に参加できます。

通常、DWデータはスタースキーマに従って分解されます。これにより、データを、メジャー（単位付きの数値）とディメンションへの外部キー参照を含む数値の「ファクト」テーブルに分解できます。

ディメンション（または「ビジネスエンティティ」）は、属性を持つ実世界のものとして最もよく考えられます。多くの場合、これには地理、時間、製品、顧客などが含まれます。これらのものには複雑な階層が含まれることがよくあります。階層は通常任意であり、さまざまなビジネスレポートのニーズによって定義され、個別のテーブルとしてモデル化されるのではなく、集計に使用されるディメンションの列にすぎません。

---

あなたの質問のいくつかに対処するため。

「この結合は、アプリケーション側で行う必要があります」。すこし。データは、ロードされる前に「事前に結合」されています。ディメンションデータは、多くの場合、そのディメンションに関連するソースデータの結合です。比較的平らな構造として結合され、ロードされます。

更新されません。更新の代わりに、追加の履歴レコードが挿入されます。

「しかし、それは高くなり始めませんか？」。すこし。データをロードするには注意が必要です。ただし、レポート/分析の結合はそれほど多くありません。データは事前​​に結合されています。

データが事前に結合されているため、ORMの問題はほとんど議論の余地があります。ORMは、必要に応じてファクトまたはディメンションにマップされます。特別な場合を除いて、寸法は小さく、完全にメモリに収まる傾向があります。例外は、金融（銀行または保険）または公益事業にいて、大規模な顧客データベースを持っている場合です。これらの顧客の側面がメモリに収まることはめったにありません。

Answer 3

AJOINは純粋なリレーショナル用語であり、すべてのデータベースがリレーショナルであるとは限りません。

他のデータベースモデルには、関係を構築する他の方法があります。

ネットワークデータベースはfind a key - fetch the reference - find a key、共通のプログラミング言語でプログラミングする必要のあるエンドレスチェーンを使用します。

コードはアプリケーション側またはサーバー側で実行できますが、SQLセットベースではなく、セットベースでもありません。

適切に設計されていれば、ネットワークデータベースはリレーショナルデータベースよりもはるかに高速になります。

たとえば、ネットワークデータベースは、別のエンティティへの参照を、このエンティティに関する情報が格納されているファイルまたはディスク上のブロックのオフセットへの直接ポインタとして格納できます。

これにより、ネットワークのトラバースが非常に高速になります—これを行うための効率的なコードを記述した場合。

リレーショナルデータベースは、整数（または高次のトリプルまたはタプル）のような基本値のペアとしてのみ参照を格納できます。

リレーショナルデータベースでこれらの値を見つけるには、エンジンは次のことを行う必要があります。

• 最初の値を含むタプルがどこにあるかを調べます
• 2番目の値を見つける
• B-Tree2番目の番号が参照するデータを保持しているルートのアドレスを見つけます
• この木を横断する
• B-Tree実際のテーブルへのポインタを見つけます（これはそれ自体として格納される場合があります。その場合、ポインタはPRIMARY KEY後の行の値です）
• ポインタでテーブルの行を見つけるか、テーブルをトラバースします
• 最後に、結果を取得します。

そして、あなたはこれをある程度しか制御することができません。その後、SQLクエリを発行して待機します。

開発者の生活を簡素化するために作成されたリレーショナルモデル。常に超高速を達成するためではなく、何があっても。

これは、アセンブリ対高水準言語と同じであり、リレーショナルモデルは高水準言語です。

あなたは私のブログの記事を読みたいと思うかもしれません

• リレーショナルデータベースとは何ですか？

、ここでは、一般的に使用されるいくつかのデータベースモデルの違いを説明しようとしています。

Answer 4

この方法でデータを非正規化するときは、異種のアイテムを結合するコストを回避するために非正規化します。単純なクエリを使用することによるパフォーマンス上の利点のために、一部のデータが複製される可能性があり、それを組み合わせる特定の方法が難しい場合があることを受け入れます。

アプリケーションレベルで大量の参加を行う必要がある場合は、それを十分に非正規化していないことを意味します。

理想的には、必要なデータセットに対して1つのクエリを実行できるようになります。実際には、アプリケーションのどの側面でも2つまたは3つを超えるクエリを使用する必要はありません。アプリケーションレベルの結合は、ビューに挿入するために個別の結果セットから内容を簡単に取得することになります。

この種のものは、本当に大規模なデータセットにのみ本当に必要であり、あらゆる種類のトレードオフが関係しています。一例を挙げると、BigTableは、カウントの提供など、集計クエリを実行できません。これを使用すると、大まかに正確な数値を得ることができます。たとえば、過去1時間に23,721件が追加された12,149,173件のレコードがある場合、それが最良であるかどうかは問題ではありません。 「約12,100,000レコード」があります。アプリケーションがいつでも正確な数値を知ることに依存している場合は、BigTableを使用するべきではありません。これが一般的な態度です。

Answer 5

Facebookのようなアプリケーションでは、データの変更がほとんどなく、ほとんどの場合、ユーザーは新しいアイテムを投稿しています。したがって、アイテムが変更されたときに複数レコードを更新する必要があるという事実は、それほど問題ではありません。

これにより、更新に関する一般的な問題にぶつかることなく、データを正規化できなくなります。

Amazonのようなアプリケーションは、1人のユーザーのすべてのデータをRAMにロードし（結局のところ、ショッピングカートの大きさはどれくらいですか？）、RAM内のデータを更新して、単一のデータ項目として書き出すことができます。

もう一度、ほとんどのデータを正規化する必要がなくなります。

アプリケーション開発の容易さのためにスケーリングを交換しているので、大きな高さまでスケーリングする必要がない場合は、RDBMSが提供するアプリケーション開発の容易さを維持したいと思うかもしれません。

Answer 6

このような状況では、あなたはほとんど自分で行動し、すべてを自分で転がさなければならないと思います。私はそこに行ったことがありませんが、私たちのプロジェクトのいくつかでそれを検討しました。（SOが示すように）リレーショナルDBを使用するとかなり大きくなる可能性があるので、今のところリレーショナルの良さを楽しみ続けます。

Answer 7

一般に、データウェアハウジングは、結合と、ディメンションおよびファクトテーブルに分割されたデータ（いわゆる「スタースキーマ」など）を使用して構築されます。

多くの場合、結合は事前に計算され、非正規化テーブルとして格納されます。

結合を許可しないデータベースシステムで動作するORMツールは、一般に従来のリレーショナルデータベースとは見なされていないため、私は知りません。