OBKV-Table Java開発ガイド

本記事では、OBKV-Tableの開発プロセスにおける注意点とベストプラクティスについて説明します。OBKV-Tableを開発に採用する前に、アプリケーションの用途とOBKV-Tableの製品ポジショニングを理解しておく必要があります。

使用上の推奨事項

バッチ処理(Batch)

バッチ内のデータに論理的な関連がない場合は、できるだけパーティションをまたがないようにバッチを構成してください。OBKV-Tableクライアントが提供するパーティションAPIでパーティションIDを計算し、パーティションごとに操作をまとめて送信できます。これにより、単一ノード内のトランザクションとして処理できるため、パフォーマンスへの影響が小さく、アプリケーション側の再試行ロジックも簡素になります。

インデックス

インデックスの使用に関する推奨事項は以下の通りです：

• 不要な場合はグローバルインデックスを使用しないでください。ベーステーブルのデータの書き込み/更新/削除のシナリオでは、グローバルインデックスのメンテナンスにより、分散トランザクションのオーバーヘッドが大きくなります。
• ローカルインデックスの保守コストはグローバルインデックスより小さいものの、インデックスの数に応じて増加します。そのため、ローカルインデックスの数も適切に抑えてください。

パーティション計画

以下では、Keyパーティションを例に説明します。

パーティションキーの設計

OBKV-Tableでは、パーティションキー設計の第一の目標は、業務シナリオにおけるリクエストがパーティションをまたがらないようにすることです。パーティションキーの選択には以下の規則があります：

• パーティションキーは通常、主キーまたは主キーのプレフィックスです。

  • 主キーをパーティションキーにする場合：例えば注文データで、主キーをorderidとし、クエリがorderidを指定するポイントルックアップクエリだけである場合は、orderidをそのままパーティションキーにできます。これにより、指定した注文の情報の全部または一部をすばやく取得できます。
  • 主キープレフィックスをパーティションキーにする場合：例えば注文データで、useridとorderidを複合主キーとし、useridを指定したプレフィックススキャンでユーザーの注文の全部または一部を取得する場合は、useridをパーティションキーにできます。

• 業務シナリオでクエリを実行する際、必ずパーティションキーのフィールドが含まれます。

パーティション数の設計における考慮事項

パーティション数を意識する理由

• パーティション数の調整には、データモデル（つまりテーブルのSchemaまたはDDL）を変更し、データの再分散を行う必要があるため、コストがかかります。
• パーティション数は小さすぎてはなりません：データベースの均衡アルゴリズムは、2つのノード間のパーティション数の差が1を超えないように保証します。したがって、3つのノード、7つのパーティションを仮定すると、各ノードのパーティション数は<3,2,2>となり、ノード間のパーティション不均衡度は(3-2)/3 = 33%となります。データの偏りがないと仮定すると、パーティション数はデータのストレージ量およびアクセス量にほぼ比例し、パーティションの不均衡度は各ノードのリソース使用状況の不均衡にも反映されます。したがって、パーティション数は小さすぎてはなりません。
• パーティション数を多くしすぎないでください。各パーティションは、ストレージ領域とデータアクセスを個別に管理する小さなデータベースとみなせます。パーティションが多いとストレージ領域を効率よく共有しにくくなり、Scan演算子が複数のパーティションをまたぐことで性能が低下する場合があります。また、バッチ操作をストレージ層に直接渡して最適化することも難しくなります。

パーティション数がパフォーマンスに与える影響

通常、パーティション数がパフォーマンスに与える影響は大きくありません。ただし、メジャーコンパクション、移行、バックアップなど、パーティション単位で実行するタスクには影響します。パーティション数が少なく、各パーティションが大きい場合は、1つのタスクの実行時間が長くなり、必要なストレージ容量も増えます。

パーティション数の選定方法

• 容量を考慮すると、単一パーティション単一レプリカのデータ量は、100GBを超えないようにすることを推奨します。パーティション数を選定する際は、可能な限り23、59、97、193、389、997などの素数を選択してください。例えば、3レプリカ、24TBのストレージ容量を使用する場合、1レプリカ分のデータ量は8TBとなり、少なくとも80個のパーティションが必要と推定されます。上記の推奨値に基づき、97個のパーティションを選択します。
• パーティション数の変更にはDDLの調整が必要であり、一定のオーバーヘッドがあります。パーティション数を設計する際には、事前にパーティション計画を立て、頻繁なパーティション数の変更を避けるようにしてください。現在のストレージ容量が24TBだが、将来1年以内に50TBに拡大する見込みがある場合、初期設計時には50TBを基準として、できれば193個のパーティション数を選択するのが望ましいです。
• パーティション数は大きすぎてはならず、997個を超えることは推奨されません。

パーティション間のデータ偏りを判断する方法

KeyパーティションではMurmurHashを使用し、パーティションキーのハッシュ値に基づいてデータを各パーティションに振り分けます。例えば、1億件のうち1,000万件が同じパーティションキーを持つような極端なケースでは、大きなデータの偏りが生じます。一方、1億件のうち一部のパーティションキーに数千件が集中する程度であれば、通常は偏りの原因にはなりません。データ件数が十分に多い場合は、ハッシュによる分散が全体としてほぼ均等になるためです。