Tablestore:データ操作のベストプラクティス

属性列間のアクセス頻度の違いに基づいてテーブルを分割する

テーブルの行に多くの属性列が含まれているが、各操作でこれらの列の一部にしかアクセスしない場合は、テーブルを複数のテーブルに分割できます。アクセス頻度の異なる属性列は、異なるテーブルに配置できます。

たとえば、商品管理システムでは、各行には、商品の数量、商品の価格、商品の説明を個別に指定する属性列が含まれています。商品の数量と商品の価格を指定する属性列のデータ型は、ストレージ容量の少ない Integer です。商品の説明を指定する属性列のデータ型は、ストレージ容量の大きい String です。ほとんどの操作は、商品の数量と商品の価格を指定する属性列のみを更新し、商品の説明を指定する属性列は更新しません。したがって、商品の説明を指定する属性列のアクセス頻度は比較的低くなります。この場合、商品の数量と商品の価格を指定する属性列と商品の説明を指定する属性列が別々に格納される2つのテーブルにテーブルを分割できます。

テキストベースの属性列を圧縮する

属性列に大量のテキストが含まれている場合は、属性列を圧縮し、Tablestore にバイナリデータとして格納できます。これは、スペースの節約と計算リソースの消費の削減に役立ち、Tablestore の使用コストを削減します。

データ量が上限を超える属性列を Object Storage Service (OSS) に格納する

Tablestore の属性列のデータサイズは 2 MB を超えることはできません。1 つの属性列に 2 MB を超えるデータ（画像、音楽、ファイルなど）を格納する場合は、OSS を使用してデータを格納できます。 Tablestore と比較して、OSS はより低い単価でファイルを保存します。したがって、OSS はオブジェクトの保存に適しています。

OSS を使用できない場合は、値のサイズが 2 MB を超える属性列を複数の小さな行に分割し、Tablestore に格納できます。

再試行間隔を追加する

Tablestore では、ハードウェアまたはソフトウェアの問題が発生し、アプリケーションの一部のリクエストが失敗し、再試行が可能なエラーが返される場合があります。アプリケーションからのリクエストが失敗し、そのようなエラーが返された場合は、しばらく待ってからリクエストを再試行することをお勧めします。ベストプラクティスとして、ランダムまたは増加する間隔は、雪崩効果を回避するのに役立ちます。