0

データが次のようなテーブルに格納されている HBase のビデオ チュートリアルを見ました。

EmployeeName - Height - ProjectInfo

------------------------------------

Jdoe - 5'7" - ProjA-TeamLead, ProjB-Contributor

ProjA の名前を ProjX に変更する必要があるビジネス要件が発生した場合はどうなりますか? プロジェクト情報が格納される別のテーブルはありませんか?

4

2 に答える 2

1

リレーショナル データベースでは、はい: プロジェクト テーブルがあり、従業員テーブルは外部キーを介してそれを参照し、不変のプロジェクト ID (名前ではなく) のみを格納します。次に、(リレーショナル データベースで) クエリを実行する場合は、次のように JOIN を実行します。

SELECT
  employee.name,
  employee.height,
  project.name,
  employee_project_role.role_name
 FROM
   employee
   INNER JOIN employee_project_role
     ON employee_project_role.employee_id = employee.employee_id
   INNER JOIN project
     ON employee_project_role.project_id = project.project_id

これは、HBase (およびその他の NoSQL データベース) で行われる方法ではありません。その理由は、これらのデータベースは非常に大きなデータセットを対象としており、多くのマシンに分散されているため、このような複雑な結合を透過的に実行する実際のアルゴリズムは、うまく機能する方法で実行するのがはるかに困難になるためです. したがって、HBase には組み込みの結合さえありません。

代わりに、このようなシステムの一般的なアプローチは、データを非正規化し、単一のテーブルに格納することです。したがって、この場合、従業員ごとに 1 つの行があり、その行に非正規化されて、従業員のプロジェクト ロール情報がすべて表示されます (おそらく別の列にあります。HBase の行の内容は実際にはキー/値マップであるため、さまざまな役割のすべてのような繰り返しを簡単に表すことができます)。

しかし、その通りです。プロジェクトの名前を変更すると、従業員ごとに保存されているデータを変更する必要があります。この点で、リレーショナル モデルは「よりクリーン」です。しかし、ペタバイト単位のデータや数兆単位の行を処理している場合、リレーショナル データベースの「クリーンな」抽象化は、すべて手動で分割する必要があるため、非常に複雑になります。HBase のようなシステムのポイントは、これらのコストを設計プロセスで前もって支払うことであり、リレーショナル データベースがこのような問題を魔法のように大規模に解決すると想定するだけではありません。（そうしないからです）。

つまり、少なくとも数テラバイトのデータ (100 万 MB です) を期待できない場合は、リレーショナル データベースで実行してください。はるかに簡単になります。

于 2012-04-17T23:47:44.647 に答える
0

このプレゼンテーションを通過することで、いくつかの視点が得られると思います。

http://ianvarley.com/coding/HBaseSchema_HBaseCon2012.pdf

そして、よりプログラム的な表現については、以下をご覧ください。

http://jimbojw.com/wiki/index.php?title=Understanding_Hbase_and_BigTable

于 2012-12-19T02:01:02.090 に答える