foldrr's weblog

旧ブログ http://d.hatena.ne.jp/foldrr/

パーティショニング キーの設計に関する注意

パーティショニング キーとは

データベースを複数拠点で保持する場合、キーの衝突を避けるために以下の2つでキーを構成する。

  1. 拠点ID
  2. レコードID

上記 1 を「パーティショニング キー」と言う。

パーティショニング キーの設計に関する注意

データ作成拠点とビジネスデータを混同しないことである。
この2つを混同してしまい1つのカラムで扱ってしまうと、「別拠点で利用するデータを作成する」といった操作ができなくなる。

具体例

具体例をあげてみる。

  • 株式会社×工業では本社、工場1、工場2の3拠点がある。
  • 各拠点はネットワークで結ばれており互いにデータをやりとりする。
  • 各拠点はネットワーク不全時にも稼働できるようデータベースを個別に配置する。
  • 工場1、工場2では独自に生産プランを作成できる。
  • 生産プランは本社でも作成できる。

この時、テーブルの主キー構成として以下2つを比べてみる。
構成 1. 利用拠点ID(PK), レコードID(PK)
構成 2. 作成拠点ID(PK), 利用拠点ID, レコードID(PK)

構成 1 の場合

本社で工場の生産プランを作成した場合、工場側でデータ同期の際にキー重複が発生してしまう。
(括弧内はフィールド内容)
本社 → 工場1
拠点ID (001) → 拠点ID (001)
レコードID (538) → レコードID (538) 衝突!!

構成 2 の場合

構成 1 と異なりキー重複は発生しない。
(括弧内はフィールド内容)
本社 → 工場1
作成拠点ID (000) → 作成拠点ID (001) 作成拠点が異なるので…
利用拠点ID (001) → 利用拠点ID (001)
レコードID (538) → レコードID (538) 衝突しない!!

まとめ

パーティショニング キーとビジネス データは分離することが重要である。
特に、ある拠点で利用するデータを別拠点で作成しデータの同期が発生する場合は、この考えは必須となる。

その他

この考えを徹すことで、特定拠点に限定すれば純粋なレコード識別に必要なカラムは常に1つとすることができる。
これによりDBMSが搭載している自動採番機能を利用することができる点は非常に大きな利点である。