Hello，大家好，歡迎使用Webfunny前端監控、Webfunny前端埋點系統。
最近一段時間，我們整個團隊都在忙着改造webfunny的clickhouse版，改造的內容非常之多，工作量非常之大，大家都忙得焦頭爛額的。所以很多小夥伴提的優化建議，在這段時間都擱置了，除非是比較嚴重的bug，基本上都延後了，我能感受到大家着急的心情。其實，我比你們更着急，只是這塊“骨頭”太大，我們真的是啃了好久，到目前爲止，基礎版本至少已經接近尾聲了。趁着喘息之機，我來記錄下，同時也向那些提了建議，卻沒有得到滿足的小夥伴表達歉意，敬請理解哈。
一、 爲什麼webfunny要做改造呢？
如果大家所知，Webfunny的部署非常簡便。在準備好數據庫後，我們的部署幾乎可以通過一鍵完成。我們採用Node.js和MySQL來處理服務器層和持久化存儲，同時Node.js也作爲靜態服務器。這一設置極大地簡化了整個系統的部署流程，因爲只需一個命令，就能啓動一整套集收集、存儲、分析、展示和警報於一體的分析體系。此外，Node.js對前端開發人員非常友好且輕量，而MySQL則無需贅述，兩者組合雖然高效，但也有一些明顯的弊端。
首先、查詢壓力大：mysql當初並不是爲了大數據存儲而設計的，面對高併發和海量數據存儲的場景都顯得尤爲喫力。同時，mysql單張表的數據存儲達到千萬級別後，查詢效率也變成了一大難題。在webfunny的使用場景中，或者說用戶更期待的是即席查詢，這就讓本就已經不堪重負的mysql數據庫更是雪上加霜了。所以我們不得不採取按天分表的策略來存儲日誌，這就導致了webfunny每天要創建很多日誌表。
其次、日誌表數量龐大，硬盤消耗快：日誌表的數量創建過多，就會增加管理成本。雖然表的數量不會影響mysql的性能，但是服務器的文件數量一般會有限制。隨着時間的推移，可能會產生幾萬張表，這就導致了存儲週期沒辦法設置太長，一般只能設置在30內。另外，由於mysql沒有設計數據壓縮的機制，所以面對海量日誌數據的時候，硬盤就會喫緊。如果存儲時間過長，很快硬盤就會撐不住了。
最後、mysql不適合做集羣化。基於上述兩點，如果msyql不做集羣化，那麼webfunny的數據量級也只能保持在千萬級，想要突破 億級/天顯得非常的困難了，所以、爲了提升的支持的數量級，我們不得不做一些改變了。
二、 Mysql能不能做集羣化呢？
mysql不適合做集羣化，並不代表它不能做集羣化。對於webfunny的場景來說，集羣化最大的難點是不好區分用戶UV數據，導致數據無法進行歸類和分析，也就比較難做集羣。
本來準備嘗試阿里雲的mysql集羣版，後來發現這個集羣版跟我們想象的不太一樣。我們可以先看下阿里雲上售賣的mysql集羣版的結構圖，實際它只有一個主節點，剩下的是備節點，可以簡單理解爲讀寫分離。所以它並不能做到集羣化，且不能明顯提升數據存儲的量級。
那麼，在webfunny的場景下，mysql該怎麼做集羣化呢？如下圖所示：
首先、單個節點中，利用userId的特徵分發到不同的數據庫中，這樣就可以保證每個userId只會存入到唯一的數據庫裏，再進行分庫查詢，然後綜合統計數據就可以了。
其次、由於單個節點的承受能力是有限的，所以必然要面臨擴容的情況，但是同一個項目數據必須上報到同一個節點中，否則多個節點之間是無法聚合查詢的。因此我們需要在多個節點上層再增加一個分發邏輯，來保證同一個項目一定會進入固定的節點中。
這樣就可以完成集羣化了，且具備了擴容的能力，但是要加代碼中加入很多聚合邏輯。
三、 用Clickhouse改造會有哪些優勢呢？
雖然、在上一條中，我們說了，webfunny其實是可以做mysql的集羣版，但是需要耗費高昂的成本，對我們來說並不是最優方案。所以我們最終選定，使用clickhouse進行改造。
1. 查詢效率高、clickhouse號稱10億數據，毫秒級查詢返回結果，也有各路前輩做到了20萬億行數據，1秒返回。讓我們不得不心動。
2. 數據壓縮率高、它採用了列式存儲，同一列的數據相同率很高，所以列式存儲對數據壓縮有天然優勢，節省硬盤資源。
3. 集羣化、clickhouse天生支持集羣化，同時有分區和分片設計，已經涵蓋了我們按天分表的設計，能夠讓webfunny存儲更大的數據量級。
四、 壓力測試效果
壓力測試效果僅以單機測試效果爲例：
mysql版：2C4G，單機，最高峯支持2.8萬/分鐘的日誌併發量
clickhouse版：4C16G，單機，最高峯支持20萬+/分鐘的日誌併發量
從測試效果來看，clickhouse的效果更好，當然機器硬件有區別，但是這個數據量級的提升還是很明顯的。
寫在最後、webfunny改造完成後，能夠支持更大的數據量級，在使用體驗方便也會有更大的提升，歡迎繼續關注。