1

大量の階層データを分割するためのベスト プラクティス/パターン、または一般的なアドバイスはありますか?

たとえば、特定の国のすべての人々のデータベースと、誰が誰と一緒に仕事をしたかを追跡することを考えてみてください。「人」エンティティを分離して考えると、各人について多くのデータを保持する場合、人口を複数の水平パーティションに分割するのが自然なアプローチのようです。ただし、関係 (誰が誰と協力したか) はパーティションをまたがる可能性があります (またそうするでしょう)。これらの関係でのクラスタリング (つまり、相互パーティション参照を最小限に抑えるために、たとえば雇用主をパーティション キーとして使用する) は、データがますます相互リンクされるにつれて、時間の経過とともに実行できなくなります。このようなクラスタリングは、スケーラビリティを妨げる不均衡なパーティションにもなります。

私は今かなり立ち往生しているので、提供された助けがあれば非常に助かります。

ありがとう。

4

1 に答える 1

1

次の 3 つの問題があるようです。

  1. 従業員に関するデータの保存 (関係/階層を除く)
  2. 雇用者から従業員への階層 (時間の経過とともに変化する可能性があります)
  3. 従業員間の作業履歴 (繰り返しますが、時間の経過とともに変化します)

それぞれに順番に取り組むには：

  1. 従業員データ: これは、姓 + 名 + 生年月日の代替キーを使用して、一意の ID でパーティション分割できます。ID ごとに均等に分散してパーティション化するか、エリア/リージョンなどのその他の情報を使用します (ただし、一部のパーティションが他のパーティションよりもホットになることを意味します)。

  2. 雇用者/従業員の階層: これを定義するためのセカンダリ テーブルが必要であり、時間の経過に伴う変更が可能です。例えば。と逆にEmployee id, Employer id, start date, end dateキーを押します。以下を読むことをお勧めします: http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back、データのサイズに適したアイデアがあるかもしれません。employee id + employer idemployer id + employee id

  3. 従業員/従業員の作業履歴: 従業員と一緒に働いた時間を相互参照する、#2 と非常によく似た別のセカンダリ テーブルが必要です。例えば。employee1 id, employee2 id, start date, end date、少なくとも各 ID によってインデックスが作成されます。

ここで重要なのは、関係/階層を従業員データ テーブル内に配置しようとしないことです。時間がかかり、必要なリンクが制限されます (特にリンクが時間の経過とともに変化するため)。

于 2009-11-26T21:46:21.073 に答える