資料存放區量

計算行資料量

每行資料的儲存空間由主鍵列和屬性列共同決定：

單行資料量=主鍵列的資料量+所有屬性列的資料量

• 主鍵列的資料量=主鍵列的名字長度之和+主鍵列的值的資料量之和

• 屬性列的資料量取決於 MaxVersions 和 TTL（Time to Live）設定，詳見下方樣本。

各資料類型的位元組數

提示：屬性列名越短，儲存費用越低。例如，列名 Name（4 位元組）比 CustomerName（12 位元組）每行節省 8 位元組的儲存開銷。

樣本：行資料量計算

以下樣本中，資料表主鍵列為 ID（Integer 類型），其他均為屬性列。

Comments 列存有兩個版本的資料，計算方式因 MaxVersions 和 TTL 設定而不同。

• 情境一：MaxVersions=2，TTL=2592000

  開啟多版本（MaxVersions>1）或設定 TTL（TTL>-1）時，每個版本號碼以時間戳記形式儲存，佔用 8 位元組。

  單個屬性列的資料量=（屬性列名字長度+8）× 有效版本數+該屬性列所有有效版本的值資料量之和

  說明

  在使用多版本（即Max versions>1）或者使用了TTL（即TTL > -1）的情境下，每個版本號碼需要佔用8位元組（以下提到的timestamp等同於版本號碼）。

  該行資料量=10+20+22+282=334 Bytes，詳情如下：

  • 主鍵列（ID）：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（2 個版本）：(len('Comments')+8)*2+100+150=282 Bytes

• 情境二：MaxVersions=1，TTL=-1

  MaxVersions=1 且 TTL=-1（不啟用 TTL）時，版本號碼不佔用位元組。

  單個屬性列的資料量=屬性列名字長度+屬性列的值的資料量之和

  說明

  • 不使用多版本（即Max versions=1）且不使用TTL（即TTL=-1）時，版本號碼不佔用位元組。

  • 雖然 Comments 列存有兩個版本，但 MaxVersions=1，只計算最新版本。

  該行資料量=10+12+14+158=194 Bytes，詳情如下：

  • 主鍵列（ID）：len('ID')+len(1)=10 Bytes

  • 屬性列 Name：len('Name')+len('zhangsan')=12 Bytes

  • 屬性列 Length：len('Length')+len(20)=14 Bytes

  • 屬性列 Comments（僅最新版本）：len('Comments')+150=158 Bytes

計算表資料量

表的資料量等於所有行的資料量之和。以下樣本中，ID 為主鍵列，其他均為屬性列，MaxVersions=2，TTL=-1。

• ID=1 的行：292 Bytes — 主鍵列 10 Bytes + Comments 屬性列兩個版本 282 Bytes。

• ID=2 的行：248 Bytes — 主鍵列 10 Bytes + Comments 屬性列一個版本 216 Bytes + Length 屬性列一個版本 22 Bytes。

該表的資料總量為 292+248=540 Bytes。若一小時內資料量未發生變化，將按 540 Bytes 計費。

Table Store對單表資料存放區量沒有限制，按實際用量計費。

儲存量統計周期

儲存量計量存在一定延遲，一般在 24 小時內完成統計。

延遲原因

Table Store基於 LSM（Log-Structured Merge-tree）架構實現，資料以追加寫入方式先存入記憶體，達到一定條件後轉存為磁碟上的小檔案。對同一行資料的多次更新和刪除操作可能分散在多個檔案中，直接匯總所有檔案大小會導致重複計量。

為保證計量準確，Table Store在 Compaction（合併作業）完成後才重新計算資料量。Compaction 會定期合并小檔案並清除冗餘資料。

因此，資料寫入、更新或刪除後，短期內表的儲存量可能不會立即變化。儲存量統計周期與系統執行 Compaction 的周期一致。