Tablestore：資料操作篇

拆分屬性列訪問熱度差異大的表

如果行的屬性列較多，但是每次操作只訪問一部分屬性列，可以考慮將表拆分成多個表，將不同訪問頻率的屬性列放到不同的表中。

例如，在商品管理系統中，每行存放商品數量、商品價格和商品簡介。商品數量和商品價格均為佔用空間較小的 Integer 類型，商品簡介是 String 類型佔用空間較大。大多數操作僅更新商品數量與商品價格，而不修改商品簡介，所以商品簡介的修改頻率較低。這時候可以考慮將這個表拆分為兩個，一個表格儲存體商品數量和商品價格，另一個表格儲存體商品簡介。

壓縮較大的屬性列文本

如果屬性列是較大的文本，應用程式可以考慮將屬性列壓縮之後再以 Binary 類型儲存到Table Store中。這樣做節省了空間、減少了訪問的服務能力單元消耗，從而可以降低使用Table Store的成本。

將資料量超出限制的屬性列儲存到 OSS 中

Table Store限制單個屬性列值不超過 2 MB。如果需要儲存單個值超過 2 MB 的需求，如圖片、音樂、檔案等，可以使用 OSS（Object Storage Service）對其進行儲存。OSS是阿里雲提供的開放儲存服務，用以應對海量資料的儲存和訪問。OSS 的儲存單價比Table Store更低，更適合隱藏檔。

如果應用程式不方便使用 OSS，可以將超過 2 MB 的單個值拆分成多個行，儲存在Table Store中。

錯誤重試加入時間間隔

Table Store可能會遇到軟硬體問題，導致應用程式的部分請求失敗，並返回可重試的錯誤。建議應用程式遇到此類錯誤時等待一段時間後再進行重試，每兩次重試之間應該加大時間間隔或引入隨機時間間隔，避免重試的請求堆積到一個時間點上引發雪崩效應。