:データ操作

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

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

たとえば、商品管理システムでは、行には商品数量、商品価格、商品説明が含まれています。商品数量と価格は、ストレージ容量をあまり消費しない INTEGER 値です。商品説明は、より多くのストレージ容量を消費する STRING 値です。ほとんどの操作では商品説明を変更せずに商品数量と価格を更新するため、商品説明は変更される頻度が低くなります。テーブルは2つのテーブルに分割できます。1つのテーブルには商品数量と価格が含まれ、もう1つのテーブルには商品説明が含まれます。

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

属性列に大量のテキストが含まれている場合は、属性列を圧縮し、Tablestore に BINARY データとして格納できます。このプロセスにより、容量が節約され、アクセス操作で消費されるキャパシティユニットが削減されるため、Tablestore の使用コストを削減できます。

OSS に属性列を格納する

Tablestore では、1 つの属性列のサイズが 2 MB に制限されています。2 MB を超えるファイルを格納する必要がある場合は、Alibaba Cloud Object Storage Service (OSS) を使用することをお勧めします。OSS は、大量のデータを格納するために Alibaba Cloud が提供するオープンストレージサービスです。Tablestore と比較して、OSS はファイルをより低い単価で格納します。そのため、OSS はオブジェクトの格納に適しています。

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

エラー再試行間隔を追加する

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