OBKV-Table Java開発ガイド

本記事では、OBKV-Tableを使用した開発時の注意事項とベストプラクティスについて説明します。

使用上の推奨事項

バッチ操作

バッチ操作内の各行が論理的に無関係である場合は、単一バッチでのパーティションまたぎを避けるようにしてください。OBKV-TableクライアントはパーティションAPIを提供しています。バッチ操作を実行する際には、まずパーティションAPIを使用してパーティションIDを計算し、その後パーティションごとに集約してバッチをコミットすることができます。これにより、各バッチを単一マシントランザクション内で完了させることができ、パフォーマンスオーバーヘッドを最大限に削減し、アプリケーション内の再試行ロジックを簡素化できます。

インデックス

インデックスを使用する際は、以下の点に注意してください：

• 必要でない限り、グローバルインデックスの使用は避けてください。メインテーブルにデータを挿入、更新、または削除する際、グローバルインデックスのメンテナンスは分散トランザクションのオーバーヘッドを増大させます。
• ローカルインデックスのメンテナンスコストはグローバルインデックスよりも低いですが、それでもローカルインデックスの数を制御する必要があります。インデックスが多すぎると、インデックスのメンテナンスコストも高くなります。

パーティション計画

以下の例では、KEYパーティションを使用します。

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

OBKV-Tableにおいて、パーティションキー設計の主な目的は、業務シナリオにおけるリクエストがパーティションをまたがらないようにすることです。以下の原則に従ってパーティションキーを選択してください：

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

  • 主キーをパーティションキーとして使用する：注文シナリオにおいて、orderidが主キーであり、クエリが常にorderidでポイントルックアップされる場合、orderidを直接パーティションキーとして使用することで、指定された注文の全データまたは一部のデータを迅速に取得できます。
  • 主キーのプレフィックスをパーティションキーとして使用する：注文シナリオにおいて、主キーがuseridとorderidで構成されており、クエリがuseridプレフィックススキャンを通じて特定ユーザーの全注文または一部の注文を取得する可能性がある場合、useridをパーティションキーとして使用できます。

• 業務シナリオにおけるクエリは、常にパーティションキー列を含む必要があります。

パーティション数に関する注意事項

パーティション数の重要性

• パーティション数を変更するには、スキーマ（テーブルDDL）を変更し、データを再分散する必要があるため、コストは高くなります。
• パーティション数は少なすぎてはなりません：データベースの均衡アルゴリズムは、任意の2つのノード間のパーティション数の差を1以内に制御します。例えば、3つのノードに7つのパーティションがある場合、分布は<3,2,2>となり、不均衡率は(3 - 2) / 3 = 33%となります。データの偏りがないと仮定すると、パーティション数はストレージ容量とアクセス量にほぼ比例します。パーティションの不均衡は、ノード間のリソース使用量の不均衡として現れます。したがって、パーティション数が少なすぎることは避けてください。
• パーティション数は多すぎてもなりません：各パーティションをクラスタ内のミニデータベースと見なすことができ、各ミニデータベースはストレージとデータアクセスを独立して管理します。この構造では、ミニデータベースが多すぎると、ストレージの最適な共有が図れず、スキャン演算子が複数のパーティションにまたがる可能性があり、一定のパフォーマンス損失が生じる可能性があります。また、バッチ操作もストレージ層にプッシュダウンして十分に最適化することが難しくなります。したがって、パーティション数が多すぎることは避けてください。

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

通常、パーティション数は日常的なパフォーマンスに与える影響は小さいですが、パーティション単位で実行されるメジャーコンパクション、移行、バックアップなどのタスクには影響します。パーティション数が少なすぎて、かつ単一パーティションのデータ量が大きすぎる場合、個々のタスクの実行時間が長くなり、ストレージ要件も高くなります。

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

• 容量計画を立てる際は、各パーティションの単一レプリカデータ量を可能な限り100GB以内に抑えることを推奨します。パーティション数を選定する際は、23、59、97、193、389、または997などの素数を優先的に使用してください。例えば、3レプリカ構成でストレージ容量が24TBの場合、単一レプリカのデータ量は約8TBとなるため、少なくとも80個のパーティションが必要です。上記の推奨値に基づき、97個のパーティションを選択できます。
• パーティション数を変更するにはDDL変更を実行する必要があり、追加のオーバヘッドが発生します。事前に慎重にパーティション数を計画し、頻繁な変更を避けてください。現在のストレージ容量が24TBだが、1年以内に50TBまで増加する見込みの場合、初期設計では50TBを基準にするべきです。例えば、193個のパーティションを選択します。
• パーティション数は多すぎない方がよく、997個を超えることは推奨されません。

パーティション間のデータ偏りの有無の判断方法

KEYパーティションは現在MurmurHashロジックを使用しています：パーティションキーに基づいてデータをハッシュし、対応するパーティションにルーティングします。1億行のデータのうち1000万行が同じパーティションキーを使用し、重大な偏りが生じるといった極端な状況が発生しない限り、通常はデータ偏りは発生しません。1億行のデータにおいて、各パーティションキーが数千行のデータに対応する場合、一般的にデータ偏りを心配する必要はありません。サンプルサイズが十分に大きい場合、パーティションキーへのハッシュ処理は高いランダム性を持ち、各パーティションのデータはグローバルに見て比較的均等に分布します。