TSDB之KairosDB：Tag對性能的影響測試命題1：是否可以不斷增加标簽？命題2：标簽值的值域對KairosDB的性能有多大影響？命題3：應該選擇多少标簽較為合适？其它總結

在使用TSDB時，在進行資料模組化與項目實施時，都需要考慮如何設定标簽？

按常識标簽的數量，對性能是有影響的，是以在如何平衡“使用者統計需求”與“性能”之間，我們需要進行權衡。

那麼，問題出現了：

結論：不可以！增加标簽會犧牲性能

标簽個數從3到6，寫入性能下降20%，讀出性能下降40%。

應謹慎選擇标簽，當建立一些有用的标簽時，也應考慮去除一些無用的标簽。

比如地理位置這樣的标簽，值域是很窄的，不會上千。

但host這樣的标簽，會随着使用者的裝置規模增加。

而如果使用一些帶時間資訊的标簽，其值域則随着時間的推移會不斷增加

結論：有較大的影響

标簽值域從1000做到30000（擴大30倍），寫入性能下降14%，讀出性能下降30%。

結論：建議選擇5個以下的标簽數

由于kairosdb與opentsdb不同，以下是其生成的真實rowkey：

rowkey=0x73797374656d2e6370752e7573616765000000015923d3cc00000d6b6169726f735f646f75626c657461676b6b6b6b6b6b6b6b6b6b6b6b6b313d746167767676767676767676767676363a7461676b6b6b6b6b6b6b6b6b6b6b6b6b323d74616776767676767676767676767631313a7461676b6b6b6b6b6b6b6b6b6b6b6b6b333d7461677676767676767676767676763231333a

轉成string後

system.cpu.usage____Y#ÓÌ___kairos_doubletagkkkkkkkkkkkkk1=tagvvvvvvvvvvvv6:tagkkkkkkkkkkkkk2=tagvvvvvvvvvvvv11:tagkkkkkkkkkkkkk3=tagvvvvvvvvvvvv213:

可以看出，對于kairosdb來說，是直接使用字元串相加的方式，生成rowkey的，是以名額名與标簽的長度越長，rowkey越長。

因為與時間有關的屬性，其标簽值數量總是會随着運作時長不斷增長，導緻string_index表會一直增長。

像一些項目中的日志檔案名，就含有時間屬性，是以不應該用來作為标簽。

通過閱讀kairosdb的源代碼可以發現，其内部使用了以下代碼邏輯：

接收請求的線程，隻是簡單的把請求收到，并轉存到資料桶中

資料桶有個數配置，使用配置項kairosdb.datastore.cassandra.write_buffer_job_queue_size來設定

使用獨立的線程，消費資料桶。

是以當資料桶消費失敗時（如無法連接配接到cassandra、java線程池滿拒絕任務），無法把消息通知到kairosdb的client，導緻client會以為寫入是順利的，一直不停的寫入。

通過修改kairosdb的TelnetServer子產品，可實作寫入失敗時，阻塞client，避免client一直寫入資料，導緻資料丢失。

在測試過程中搭建了多個環境，發現cassandra與kairosdb無法在windows平台上充分利用機器性能，通過一些配置，都無法把CPU使用率與RAM提高。

但在linux下無此問題，虛拟機裡的性能甚至好于windows主控端。

kairosdb在處理寫入或查詢操作時，其過程如下：

接收查詢參數：名額、時間範圍、标簽範圍、彙聚參數

根據“名額與時間範圍”，生成rowkey_range_start與rowkey_range_end

向cassandra查詢rowkey_range_start與rowkey_range_end間的所有rowkey，生成match1_rowkeys

針對match1_rowkeys進行計算，分析是否包含了“标簽範圍”中指定的标簽，将包含的rowkeys，生成match2_rowkeys

根據match2_rowkeys查詢資料，并根據“彙聚參數”進行彙聚與傳回

由于上述step3 cassandra可以快速的利用叢集能力查詢出所在範圍段内的rowkey，是以這裡的成本很低，最大的成本在于step 4，這裡需要大量的資料contains計算。

是以從上述原理可以看出：

名額數量增加，影響非常小，因為step3的成本很低

時間的增加，影響非常小，因為step3的成本很低

标簽組合出來的值域越大，性能越低。因為導緻step4的成本較高

測試方案與資料

編寫一個程式，使用不同的tag組合，20線程并發寫入與10線程并發讀取3000萬筆名額，組合如下：

序号

标簽數

标簽組合

測試次數

寫入TPS

讀取TPS

rowkey長度

1

3

1. TagPolicy{key='tagkkkkkkkkkkkkk1', value='tagvvvvvvvvvvvv0~10'}

2. TagPolicy{key='tagkkkkkkkkkkkkk2', value='tagvvvvvvvvvvvv0~30'}

3. TagPolicy{key='tagkkkkkkkkkkkkk3', value='tagvvvvvvvvvvvv0~1000'}

33406

1.55

148

2

6

4. TagPolicy{key='tagkkkkkkkkkkkkk4', value='tagvvvvvvvvvvvv0~10'}

5. TagPolicy{key='tagkkkkkkkkkkkkk5', value='tagvvvvvvvvvvvv0~10'}

6. TagPolicy{key='tagkkkkkkkkkkkkk6', value='tagvvvvvvvvvvvv0~10'}

26860

0.95

無

9

7. TagPolicy{key='tagkkkkkkkkkkkkk7', value='tagvvvvvvvvvvvv0~10'}

8. TagPolicy{key='tagkkkkkkkkkkkkk8', value='tagvvvvvvvvvvvv0~10'}

9. TagPolicy{key='tagkkkkkkkkkkkkk9', value='tagvvvvvvvvvvvv0~10'}

23610

0.8

364

4

1. TagPolicy{key='tagkkkkkkkkkkkkk1', value='tagvvvvvvvvvvvv0~10', uniqure=true}

2. TagPolicy{key='tagkkkkkkkkkkkkk2', value='tagvvvvvvvvvvvv0~30', uniqure=true}

3. TagPolicy{key='tagkkkkkkkkkkkkk3', value='tagvvvvvvvvvvvv0~1000', uniqure=true}

4. TagPolicy{key='tagkkkkkkkkkkkkk4', value='tagvvvvvvvvvvvv0~300000', uniqure=false}

26065

5

1. TagPolicy{key='tagkkkkkkkkkkkkk1', value='tagvvvvvvvvvvvv0~1000', uniqure=true}

2. TagPolicy{key='tagkkkkkkkkkkkkk3', value='tagvvvvvvvvvvvv0~30000', uniqure=false}

3. TagPolicy{key='tagkkkkkkkkkkkkk2', value='tagvvvvvvvvvvvv0~300', uniqure=true}

28841

1.1

154