シャーディング時のデータ分散、ID採番戦略

MySQL

データをどう分散するかに加えて、ID採番も考える必要がある

データ分散の戦略

  1. fixed mapping
    1. id % shard で求めるやつ。shard数が変わると計算結果が変わるのがネック
  2. dynamic mapping
    1. user_to_shard のようなマッピングテーブルをつくる。shardキーのカーディナリティが100億とかになるとそもそもマッピングテーブル自体がでかくなり過ぎてつらいのがネック
  3. mixed mapping
    1. 上記の欠点に対して、ハッシュ関数などを噛ませて取りうる値の範囲を絞ってからマッピングを行うもの
  4. explicit mapping
    1. instagramやpinterestが採用している方法。idの中にシャード番号も織り込む。欠点はシャードキーにそのidを使えない制約がある場合。

ID採番の戦略

  1. 採番テーブルを使う
    1. MySQLそのもののauto_increment
    2. RedisなどInMemoryDBで一元管理
  2. UUID
    1. MySQLのUUID_SHORT()など
    2. オリジナルUUID（instagramやpinterest）

感想

  • データ分散をexplicitにした場合、必然的にID採番はオリジナルUUIDになる
  • mixed mappingは割りと柔軟性があると思う。しかし、ID採番をどうするか、またhash to shardのLOOKUPテーブルをどうやって生成してどこに保持するか。など考えるべき事項が多い。