Skip to content
Published on

HBase Row Keyの設計

Authors
  • Name
    Twitter

Background

HBaseのRow Key設計は非常に重要です。Row Keyの範囲でリージョンが分割されるため、Row Keyのプレフィックスが適切に設計されていないと、ホットスポットリージョンが発生し、パフォーマンスが大幅に低下します。これを防ぐ方法の1つとして、Row Keyの先頭にsaltを配置し、Row Keyが異なるリージョンに適切に分散されるように保存する方法があります。

例えば、メッセージを保存する際にRow Keyを送信日:送信時刻:message_idで設計するとすると、以下のようなメッセージは同じリージョンサーバーで処理され、パフォーマンスの低下を招きます。

230611:063031:1231231
230611:063032:1231232
230611:063032:1231233
230611:063033:1231234
230611:063033:1231235

もしmessage_idを先頭に置くとどうなるでしょうか?

1231231:230611:063031
1231232:230611:063032
1231233:230611:063032
1231234:230611:063033
1231235:230611:063033

これも順番に増加するmessage_idのため、書き込みが1つのリージョンに集中してしまいます。 これを防ぐには、適切なハッシュ値を使ったsaltをRow Keyのプレフィックスとして追加することが効果的です。

saltを追加するとRow Keyの構造はsalt:送信日:送信時刻:message_idになります。 saltには別のキーをハッシュ関数に入れて返された値を使用しますが、その理由はハッシュ関数の戻り値の長さが一定でランダム性があるため、リージョンが適切に分散されるからです。

最もよく使われるSHA、AES、MD5関数の中からMD5を使用してみましょう。 saltとしてMD5_function(message_id)を入れて作成した場合、Row Keyは以下のようになります。

8D4646EB2D7067126EB08ADB0672F7BB:230611:063031:1231231
715782C59C0561E9B6CE0F3D522C32F1:230611:063032:1231232
57F962C03EF3526EC6E95CEB50785C4C:230611:063032:1231233
8B353D5CC07E13577608711F4602FCB7:230611:063033:1231234
430EDB0C535BF08174E122EFECFA711D:230611:063033:1231235

プレフィックスの順序が連続していないため、リージョンサーバー全体に適切に分散されることが期待できます。これにより、HBaseのリージョンサーバーのパフォーマンスを均等に活用でき、パフォーマンスの向上に大きく貢献します。