測試模型 - Tablestore

表結構


主鍵名	類型	編碼方式	長度
userid	string	4-Byte-Hash + Long.toHexString	20

屬性列


屬性列名	類型	長度
field0	string	100
field1	string	100
field2	string	100
field3	string	100
field4	string	100

分區數量

Tablestore的自動負載平衡機制能夠根據表下各個分區的資料量、訪問壓力對資料分區進行動態分裂，該過程不需要人工介入，本次測試，選取了具有代表性的1、4和16個分區情況下表的效能資料。

新建立的資料表預設為1個資料分區，如果您對錶有分區的需求，請提交工單。

測試案例

每台壓力器啟動N個線程，每個壓力線程建立一個com.alicloud.openservices.tablestore.SyncClient，同步調用Tablestore的API。

測試案例包括：
- 隨機寫：調用SyncClient.putRow，每次請求包含1行資料，持續1小時。
- 批量寫：調用SyncClient.batchWriteRow，每次請求包含200行資料，持續1小時。
- 隨機讀：首先調用BatchWriteRow寫資料，每個分區寫入約20GB資料；然後調用SyncClient.getRow，每次請求獲得1行資料，持續0.5小時。
- 隨機範圍讀：首先調用BatchWriteRow寫資料，每個分區寫入約20GB資料；然後調用SyncClient.getRange，每次請求獲得100行資料，持續0.5小時。
為了避免網路環境的影響，所有測試案例都直接請求Tablestore執行個體的私網地址。

本次效能測試不是產品能力的極限測試，因此並沒有觸發Tablestore服務端的流控措施，Tablestore的自動負載平衡機制也儘可能地保證使用者單表提供的服務能力能夠水平擴充。大規模的壓力測試可能會觸發後端流控並且可能會產生較貴的費用，如果需要做大規模的效能測試，請提交工單，保證測試結果並控制測試費用。

Tablestore的BatchWriteRow會以分區維度並發處理，每個分區的資料會最終變成一次寫磁碟操作。建議您在組織BatchWriteRow請求時，按資料的分區鍵進行彙總，可以減少每次BatchWriteRow的寫磁碟數量，有效提高寫入效能。

隨機讀和隨機範圍讀兩個測試案例由於在測試時無寫入壓力，故其cache命中率會隨測試時間逐漸升高。對於低壓力的情境，其cache命中率升高的速度比較慢，受磁碟IO能力的影響會大一些；對於高壓力的情境，其cache命中率升高的速度比較快，受磁碟IO能力的影響會小一些。

BatchWriteRow和GetRange兩個測試案例會使用比較多的網路頻寬，如果您遇到讀寫Tablestore的效能不符合預期時，可以檢查機器的網路頻寬是否已經用滿。

Tablestore的讀取效能受使用者的資料量與快取命中率影響比較大。因此GetRow和GetRange這兩個測試案例無法覆蓋到所有的使用者情境。我們保證這兩個測試案例的效能資料是使用者可複現的，它的意義在於，如果您的使用情境與之類似，可以使用本報告的資料作為一個參考。如果您的讀寫吞吐或延時與本報告的資料偏差較大，可以聯絡Tablestore的工作人員幫忙分析原因。