Tablestore は、ご利用のインスタンスの 1 時間ごとの平均データ量に基づき、1 時間単位でデータストレージを課金します。
最新の料金情報については、「Tablestore 料金ページ」をご参照ください。
以下のセクションでは、行およびテーブルのデータ量の計算方法について説明します。
行のデータ量の計算
各行が占有するストレージ容量は、そのプライマリキー列および属性列によって決まります。
行のデータ量 = プライマリキー列のデータ量 + すべての属性列のデータ量
プライマリキー列のデータ量 = プライマリキー列名の長さの合計 + プライマリキー列の値のサイズの合計
属性列のデータ量は、MaxVersions および Time to Live (TTL) の設定に依存します。以下の例をご参照ください。
データの型別の値サイズ
|
データの型 |
バイト数 |
|
文字列 |
UTF-8 文字列が占有するバイト数。空文字列のサイズは 0 です。 |
|
整数 |
8 |
|
Double |
8 |
|
ブール値 |
1 |
|
バイナリ |
バイナリデータが占有するバイト数。 |
ヒント： 属性列名は短くしてください。列名はストレージ課金対象となるため、Nameのような 4 文字の名前は、CustomerNameのような 12 文字の名前よりもコストが低くなります。
例：行のデータ量の計算
プライマリキー列として ID（整数型）を持つテーブルを想定します。他のすべての列は属性列です。
|
ID |
Name |
Length |
Comments |
|
1 |
timestamp=1466676354000,value='zhangsan' |
timestamp=1466676354000,value=20 |
timestamp=1466676354000,value=String (100 bytes) timestamp=1466679954000,value=String (150 bytes) |
Comments 列には 2 つの保存済みバージョンがあります。計算方法は MaxVersions および TTL 設定によって異なります。
シナリオ 1：MaxVersions = 2、TTL = 2592000
複数バージョンが有効（MaxVersions > 1）または TTL が設定されている（TTL > -1）場合、各バージョン番号は 8 バイトのタイムスタンプとして保存されます。
-
単一の属性列のデータ量 =
(列名の長さ + 8) × バージョン数 + すべてのバージョンの値サイズの合計説明複数バージョンを使用するシナリオ（Max versions > 1）または TTL が有効なシナリオ（TTL > -1）では、各バージョン番号は 8 バイトのタイムスタンプとして保存されます。
この行のデータ量は 10 + 20 + 22 + 282 = 334 バイト です。
プライマリキー列 (ID)：
len('ID') + len(1) = 10 バイトName 属性列：
(len('Name') + 8) × 1 + len('zhangsan') = 20 バイトLength 属性列：
(len('Length') + 8) × 1 + len(20) = 22 バイトComments 属性列（2 バージョン）：
(len('Comments') + 8) × 2 + 100 + 150 = 282 バイト
-
シナリオ 2：MaxVersions = 1、TTL = -1
MaxVersions = 1 かつ TTL = -1（TTL 無効）の場合、バージョン番号はバイトを占有しません。
属性列のデータ量 =
列名の長さ + 列の値サイズ説明単一バージョンを使用するシナリオ（Max versions = 1）かつ TTL を使用しないシナリオ（TTL = -1）では、バージョン番号はバイトを占有しません。
Comments 列には 2 つのバージョンがありますが、MaxVersions が 1 に設定されているため、最新のバージョンのみがデータ量に加算されます。
この行のデータ量は 10 + 12 + 14 + 158 = 194 バイト です。
プライマリキー列 (ID)：
len('ID') + len(1) = 10 バイトName 属性列：
len('Name') + len('zhangsan') = 12 バイトLength 属性列：
len('Length') + len(20) = 14 バイトComments 属性列（最新バージョンのみ）：
len('Comments') + 150 = 158 バイト
テーブルのデータ量の計算
テーブルのデータ量は、そのテーブルに含まれるすべての行のデータ量の合計です。ID をプライマリキー列とし、他のすべての列を属性列とし、MaxVersions を 2、TTL を -1 に設定したテーブルを想定します。
ID=1 の行：292 バイト — プライマリキー 10 バイト + Comments 列（2 バージョン）282 バイト
ID=2 の行：248 バイト — プライマリキー 10 バイト + Comments 列（1 バージョン）216 バイト + Length 列（1 バージョン）22 バイト
テーブルの合計データ量は 292 + 248 = 540 バイト です。1 時間を通してデータ量が一定であれば、ストレージ料金は 540 バイトに基づいて計算されます。
Tablestore はテーブル単位のストレージ上限を設けていません。ご利用分のみを課金します。
Tablestore は、各パーティションから期限切れのデータおよび MaxVersions を超過したバージョンを非同期で削除します。クリーンアップ後、そのパーティションのデータ量を再計算します。クリーンアップは通常、合計データ量に応じて 24 時間以内に完了します。クリーンアップ後に書き込まれたデータは、次のクリーンアップサイクルでのデータ量計算に含まれます。
ストレージ量の統計期間
ストレージの計測は即時ではありません。統計は通常 24 時間以内に更新されるため、データの変更がストレージレポートに反映されるまでに遅延が生じます。
遅延が発生する理由
Tablestore は Log-Structured Merge-tree (LSM tree) アーキテクチャを採用しています。新しいデータはまずメモリに書き込まれ、特定のしきい値に達するとディスク上の小さなファイルにフラッシュされます。1 行に対する更新および削除操作は、複数のファイルに分散される可能性があります。生のファイルサイズを単純に合計すると、冗長なデータにより過大評価されてしまいます。
正確な計測を確保するため、Tablestore はコンパクション（ファイルをマージして冗長データを削除する定期的なプロセス）を待機したうえで、マージ後のファイルサイズに基づいてデータ量を再計算します。
そのため、書き込み・更新・削除操作を行っても、テーブルサイズのレポート値が直ちに変化しない場合があります。データ量の統計期間は、コンパクションサイクルに対応しています。