ここでは、Table Store のデータ操作を最適化するための推奨事項について説明します。 特に、属性列とアプリケーション要求エラーを効果的に管理する方法について詳しく説明します。

属性列間で表を分割

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

たとえば、商品の数量、商品の価格、商品の説明を含む行を含む商品管理システムでは、次のようになります。

  • アイテムの数量と価格は、ストレージ領域をほとんど消費しない整数型の値ですが、頻繁に変更されます。

  • アイテムの説明は String 型の値で、より多くのストレージ領域を消費しますが、変更はほとんどされません。

大部分の操作ではアイテムの数量と価格の整数型の値を更新するだけでよいため、テーブルを 2 つのテーブルに分割し、一方にこれらの 2 つの値を、もう一方に String 型のアイテムの説明を含めることができます。

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

属性列に大量のテキストが含まれている場合は、属性列を圧縮して Table Store にバイナリ型として格納できます。 このプロセスにより、スペースを節約し、アクセス操作で消費される容量ユニットを削減して、Table Store の使用コストを削減します。

OSS に属性列を格納

Table Store では、単一の属性列のサイズが 2 MB に制限されています。 2 MB を超えるファイルを保存する必要がある場合は、Alibaba Cloud Object Storage Service (OSS) を使用することを推奨します。 OSS は、Alibaba Cloud Table Store と比較して低コストで大きなファイルを保存できる代替のストレージサービスです。

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

エラー再試行間隔を追加

アプリケーションの要求が失敗して再試行エラーが返された場合は、しばらくしてから要求を再試行することを推奨します。 ベストプラクティスとして、無作為化または指数関数的に増加するバックオフは、雪崩効果を回避するのに役立ちます。