資料存放區量 - Tablestore

Table Store對執行個體的資料總量按小時計費。Table Store以固定的時間間隔統計資料總量，然後計算每小時資料總量的平均值。

說明關於最新的單價資訊，請參見Table Store價格詳情頁

下面舉例說明如何計算單行和表的資料量。

計算行資料量

Table Store的每行資料都佔用一定的儲存空間。開啟多版本或設定資料表生命週期後，每一個版本的資料需要包括版本號碼（佔用8位元組）、列名和資料值。

儲存空間的計算公式：單行資料量=主鍵列的資料量+所有屬性列的資料量

主鍵列的資料量=主鍵列的名字長度之和+主鍵列的值的資料量之和
屬性列的資料量計算方式，請參考本文檔中關於行及表的資料量計算樣本的具體說明。

值的資料量的計算方式：

資料類型	位元組數
String	UTF-8字串佔用的位元組數（Table Store允許值為空白的String類型，如果字串為空白，則資料大小為0。）
Integer	8
Double	8
Boolean	1
Binary	位元據佔用的位元組數

行資料量的計算樣本：

資料表主鍵列為ID（Integer）。其中ID是主鍵列，其他均為屬性列。

Name

Length

Comments

timestamp=1466676354000,value=‘zhangsan’

timestamp=1466676354000,value=20

timestamp=1466676354000,value=String（100 Bytes）

timestamp=1466679954000,value=String（150 Bytes）

其中Comments有兩個有效版本：

當MaxVersions=2，TTL=2592000時：
單個屬性列的資料量=（屬性列名字長度之和+8）*有效版本個數+該屬性列所有有效版本的值資料量之和
說明在使用多版本（即Max versions>1）或者使用了TTL（即TTL=-1）的情況下，每個版本號碼需要佔用8位元組（以下提到的timestamp等同於版本號碼）。
該行資料量=10+20+22+282=334 Bytes，詳情如下：
- 主鍵列資料量=len(‘ID’)+len(1)=10 Bytes
- 屬性列Name資料量=(len(‘Name’)+8)*1+len(‘zhangsan’)=20 Bytes
- 屬性列Length資料量=(len(‘Length’)+8)*1+len(20)=22 Bytes
- 屬性列Comments資料量=(len(‘Comments’)+8)*2+100+150=282 Bytes
當MaxVersions=1，TTL=-1時：
單個屬性列的資料量=屬性列名字長度之和+屬性列的值的資料量之和
說明
- 在不使用多版本（即Max versions=1）且不使用TTL（即TTL=-1）的情境下，版本號碼不佔用位元組。
- 雖然Comments有兩個版本，但由於MaxVersions=1，只計算最新的版本。
該行資料量=10+12+14+158=194 Bytes，詳情如下：
- 主鍵列資料量=len(‘ID’)+len(1)=10 Bytes
- 屬性列Name資料量=len(‘Name’)+len(‘zhangsan’)=12 Bytes
- 屬性列Length資料量=len(‘Length’)+len(20)=14 Bytes
- 屬性列Comments資料量=len(‘Comments’)+150(Bytes)=158 Bytes

計算表資料量

表的資料量是表中所有行的資料量之和。假設存在如下表，ID是主鍵列，其他均為屬性列。當該表Max versions=2，TTL=-1。其資料量計算方式如下圖所示。

對於ID=1的行，其資料量=10（主鍵列資料量）+282（Comments屬性列兩個版本的資料量）=292 Bytes。
對於ID=2的行，其資料量=10（主鍵列資料量）+216（Comments屬性列一個版本的資料量）+22（Length屬性列一個版本的資料量）=248 Bytes。
因此該表的資料量之和為292+248=540 Bytes。

假設一小時內表的資料量之和未發生變化，將會按540 Bytes進行計費。Table Store對單表資料存放區量沒有限制，使用者可以根據自己的實際需求使用，隨用隨付。

說明 Table Store會非同步對各個資料分區到期的資料及超過最大版本號碼的版本資料進行清理操作，並在清理操作完成後統計該資料分區資料量。清理時間長度與總資料量相關，一般會在24小時內完成。資料清理操作完成後新寫入的資料將在下一個資料清理操作之後計入該分區資料量。

儲存量統計周期

Table Store的儲存量計量會存在一定延遲，一般在24小時內完成。

Table Store資料表基於LSM架構實現，資料會採取追加寫入的方式寫入記憶體，當資料滿足一定條件後會轉存形成一個小的資料檔案。對於單行資料的多次更新與刪除操作可能會分散到多個小檔案中，直接計算所有檔案大小會造成冗餘計量。而系統會定期進行資料檔案合并（compaction）清理冗餘資料，為了保障儲存計量的準確性，只記錄每次合并後的檔案大小。

因此資料寫入、更新或刪除後，短時間內表大小可能不會有變化，儲存量統計存在一定延遲。儲存量統計周期與系統合并資料檔案的周期一致。