在表格存儲内部，一個表在建立的時候需要定義主鍵，主鍵會由多列組成，我們會選擇主鍵的第一列作為分片鍵。當表的大小逐漸增大後，表會分裂，由原來的一個分區自動分裂成多個分區。觸發分裂的因素會有很多，其中一個很關鍵的因素就是資料量。分裂後，每個分區會負責某個獨立的分片鍵範圍，每個分區管理的分片鍵範圍都是無重合的，且範圍是連續的。在後端會根據寫入資料行的分片鍵的範圍，來定位到是哪個分片。
表會以分區為機關，被均勻的配置設定到各個後端伺服器上，提供分布式的服務。
<b>那在使用表格存儲來存儲時間序列資料時，我們應該如何設計表的結構，避免熱點分片的問題？</b>
<b></b>
<b> </b>假設我們需要設計一張表，用于存儲監控資訊，監控資訊包括：時間戳（timestamp）、監控名額名稱（metric）、主機名（host）和監控名額值（value）。而我們的查詢場景為，指定監控名額名稱和時間範圍，查詢該監控名額的所有值。通常我們會這樣設計我們的表結構：
<b>表設計一：</b>
該設計以metric列為分片鍵，能夠滿足查詢的場景，但是有很嚴重的分片熱點問題。假設一個metric下每秒采集一個點，而我們有上百台裝置，則該分片每秒需要能夠提供上百的寫入能力，這點也沒有問題。但是由于使用了metric作為分片鍵，metric的值為常量，随着資料量的上漲，其無法再進行分裂，會導緻該分片下的資料量不斷膨脹，可能超過一台實體機所能承受的上限，存在分片資料量的熱點。
為了解決這個問題，我們對分片鍵做一個調整：
<b>表設計二：</b>
我們将第一列主鍵和第二列主鍵合并為一列主鍵作為分片鍵，在資料的分布模式上并沒有什麼變更，但是引入了時間這個次元後，我們避免了分片資料量的熱點。但是當host規模變大，從上百膨脹到上萬，則該張表需要每秒提供上萬并發的寫入能力。我們需要将該表的寫入壓力均勻的分散到各個分片上，但是由于其資料的特點，每次寫入的資料都是最新時間的資料，其寫入壓力永遠集中在最新時間戳所在的分片上。
為了将寫入壓力均勻的分散到分片上，我們再對表做一個重新設計：
<b>表設計三：</b>
<b>總結</b>
在時間序列存儲的場景，例如監控資料或者日志資料，通常比較難解決的是寫入的問題，傳統的資料庫難以承載如此大資料量、高并發的寫入壓力。
表格存儲能夠提供非常優秀的寫入能力，在阿裡内部得到到了正好的實踐和證明。但是若要發揮其強度的寫入能力，需要有一個良好的表結構設計。
本篇文章給出了一個存儲時間序列資料庫的最佳實踐，供參考。但表結構設計并不是千篇一律的，需要根據不同的業務場景設計做靈活的調整，歡迎一起探讨。