POC：POC測試屋谭，即Proof of Concept，是業(yè)界流行的針對客戶具體應用的驗證性測試，根據(jù)用戶對采用系統(tǒng)提出的性能要求和擴展需求的指標，在選用服務器上進行真實數(shù)據(jù)的運行课竣，對承載用戶數(shù)據(jù)量和運行時間進行實際測算，并根據(jù)用戶未來業(yè)務擴展的需求加大數(shù)據(jù)量以驗證系統(tǒng)和平臺的承載能力和性能變化置媳。
Vertica：Vertica是一款基于列存儲的MPP （massively parallel processing）架構的數(shù)據(jù)庫于樟。它可以支持存放多至PB（Petabyte）級別的結構化數(shù)據(jù)。Vertica是由關系數(shù)據(jù)庫大師Michael Stonebraker(2014 年圖靈獎獲得者)所創(chuàng)建拇囊，于2011年被惠普收購并成為其核心大數(shù)據(jù)平臺軟件迂曲。
Altinity:Altinity是一家ClickHouse的服務供應商。
ClickHouse是一個非常好的分析數(shù)據(jù)庫選擇寥袭，不僅適用于初創(chuàng)公司路捧，也適用于那些已經(jīng)將大量資源投入分析解決方案，但對結果并不完全滿意的公司传黄。
在本文中杰扫，我們將討論企業(yè)如何以及何時考慮ClickHouse遷移項目，以及他們可能會面臨的挑戰(zhàn)尝江。我們沒有透露公司名字涉波，但每個例子都有一個真實世界的原型英上。
1.什么時候遷移炭序？
遷移總是一個痛苦的過程。如果你搬到另外一個房子或者另一個數(shù)據(jù)庫苍日，這并不重要惭聂，但是總是要付出很多努力，這期間會經(jīng)歷困擾相恃，挫折等等辜纲。但是最后的結果是值得挑戰(zhàn)的，這是激勵你繼續(xù)前進的動力柠掂。那么考慮遷移到ClickHouse的動機是什么凯砍？
1.1 性能問題
其中一個主要原因是數(shù)據(jù)量大增，性能下降喻杈。使用流行的開源MySQL或PostreSQL數(shù)據(jù)庫來實現(xiàn)一個demo甚至是生產(chǎn)系統(tǒng)是非常容易的扫俺。數(shù)據(jù)大小比較小苍苞，索引大小適合內(nèi)存，數(shù)據(jù)緩存命中率足夠高狼纬，在這樣的情形下它能夠正常提供服務羹呵。不幸的是，這樣一個理想情形最終會走到盡頭疗琉，查詢會變得越來越慢冈欢。你可以通過增加更多的內(nèi)存，訂購更快的磁盤等等來解決問題盈简，（這只是在縱向擴展）凑耻，但這只是拖延解決本質(zhì)問題：你該如何橫向擴展你的數(shù)據(jù)庫系統(tǒng)？
ClickHouse在這里可以幫到很多柠贤。即使在同一臺物理服務器上運行拳话，與OLTP數(shù)據(jù)庫相比，它通持治可以比OLTP負載快100-500倍的查詢性能弃衍。如果還不夠，ClickHouse集群可以很容易地堆出來坚俗，以解決任何規(guī)模的問題镜盯。
許多在性能問題上苦苦掙扎的公司，嘗試了不同的開源替代方案猖败，最終他們發(fā)現(xiàn)ClickHouse是他們的銀彈速缆。
1.2 橫向擴展成本
在ClickHouse上市之前，很多公司已經(jīng)使用商用DBMS部署了分析解決方案恩闻∫彰樱惠普Vertica可能是最好的商用分析解決方案。Vertica價格是昂貴滴幢尚，但在不太大的TB級業(yè)務上破停，對于小公司來說價格也還負擔的起。當業(yè)務要求將數(shù)據(jù)擴展10或100倍時尉剩，畫面就不那么好看了（注意真慢，數(shù)據(jù)量的成倍增加并不總是意味著公司利潤的成倍增加）。商業(yè)數(shù)據(jù)庫管理系統(tǒng)擴大數(shù)據(jù)收費會大大增加（雖然會提供一定量的折扣）理茎。這種場景下有些公司可能會考慮更換數(shù)據(jù)平臺黑界」苕遥看這里，ClickHouse通過一系列專業(yè)知識來使硬件最大化發(fā)揮它們的功力朗鸠。
1.3 持有成本
云數(shù)據(jù)庫為分布式數(shù)據(jù)庫部署提供了最快捷的解決方案蚯撩。Google Big Query，Amazon RedShift或SnowflakeDB是非常好的產(chǎn)品烛占。他們允許非城蟛蓿快速地安裝并使系統(tǒng)能夠正常運行。但是扰楼，一段時間以來呀癣，一些公司想知道快速啟動的價格是否是長期合理的。我們已經(jīng)在亞馬遜和專用服務器上運行了一些ClickHouse的基準測試弦赖，并將其與RedShift進行了比較项栏。例如，【通過這篇文章分析】蹬竖，我們得出結論：在Amazon中運行ClickHouse的成本比類似執(zhí)行的RedShift實例要低幾倍沼沈。【這篇文章有介紹如何評估成本降低】币厕，與Google Big Query和Athena相比ClickHouse明顯勝出列另，并且會顯著降低成本。
這里的另一個考慮是ClickHouse部署不是供應商鎖定的旦装。公司可以將ClickHouse解決方案部署到Amazon页衙，專用服務器，私有云或KodiakData等專用云阴绢，從而以最靈活的方式優(yōu)化其部署和成本結構店乐。
2.如何遷移？
ClickHouse是一個不尋常的數(shù)據(jù)庫呻袭，有很多很酷的功能和設計決策眨八，以獲得最佳性能。然而左电，學習如何最有效地使用ClickHouse需要一段時間廉侧。ClickHouse的限制顯示了硬幣的另一面。ClickHouse缺少一些比較成熟的數(shù)據(jù)庫提供的功能篓足。這使遷移項目變得復雜段誊。
CH的一些限制：
不支持真正的刪除/更新支持 不支持事務（與Spark和大部分大數(shù)據(jù)系統(tǒng)一樣）
不支持二級索引（和Spark和大部分大數(shù)據(jù)系統(tǒng)一樣）
自己的協(xié)議（不支持MySQL協(xié)議）
有限的SQL支持，join實現(xiàn)與眾不同纷纫。如果需要在從MySQL或Spark進行遷移枕扫，則可能必須重新編寫包含聯(lián)接的所有查詢陪腌。
不支持窗口功能
2.1 ClickHouse遷移的主要挑戰(zhàn)
遷移到ClickHouse時辱魁，您可能會遇到以下挑戰(zhàn)烟瞧。
2.1.1 模式確認：
架構是性能的關鍵。因此染簇，需要對ClickHouse最佳實踐有很好的理解参滴，表引擎如何工作，字典是什么等等锻弓。適當?shù)哪Ｊ侥芨玫陌l(fā)揮出ClickHouse的能力砾赔。
2.1.2 可靠的數(shù)據(jù)吞吐：
ClickHouse允許在一致性和速度之間進行平衡，這些權衡對于理解和管理很重要青灼，特別是在分布式環(huán)境中暴心。數(shù)據(jù)分配和復制、可擴展和可靠的系統(tǒng)需要恰當?shù)脑O計杂拨。ClickHouse在數(shù)據(jù)分發(fā)和復制方面非常靈活专普，沒有特定的方法。
2.1.3 客戶端界面：
迄今為止弹沽，主要的ClickHouse問題之一是非標準的SQL語法檀夹。它是非常強大的，有很多擴展策橘，但它不是標準的炸渡。這使得有時很難與使用SQL的客戶端工具進行交互。這個問題已經(jīng)被ClickHouse開發(fā)者很好的理解丽已，我們可以期待ClickHouse在將來支持SQL-92或更高版本的標準蚌堵。
2.2 做好準備
任何移植項目都應該從計劃開始。我們提出以下方法來降低風險并確保遷移項目取得成功沛婴。
2.2.1 確認使用情況
確認ClickHouse是否適配業(yè)務是非常重要的辰斋。ClickHouse可能更適合流式或批次入庫的時序數(shù)據(jù)。正如邁克爾·斯通布拉克（Michael Stonebraker）在10年前的游戲改變文章中所寫的：“One size does not fit all” - ClickHouse不應該被用作通用數(shù)據(jù)庫瘸味。
2.2.2 檢查基準
有許多基準測試可用宫仗，您可以根據(jù)您已經(jīng)使用的數(shù)據(jù)庫找到基準。一些基準的鏈接可以【看看這里】旁仿。
2.2.3 運行自己的基準
眼見為實藕夫，使用真實數(shù)據(jù)運行基準并與現(xiàn)有生產(chǎn)系統(tǒng)進行比較總是很有意義。
2.2.4 仔細分析ClickHouse限制枯冈，而非功能
管理人員經(jīng)常只注意功能毅贮，但忽略了局限性。開發(fā)人員往往更加懷疑這玩意是不是真的好用尘奏。ClickHose的特性確實好用滩褥，但更多的時候，它的限制可能會成為絆腳石炫加。
你需要評估ClickHouse的各種限制瑰煎，例如ClickHouse的分區(qū)限制铺然，不支持更新和刪除，不支持事務等等的缺點酒甸，是否和你的業(yè)務情形匹配魄健。
但是并不要無端的害怕這些缺點，大多數(shù)情況下ClickHouse的限制可以被解決插勤，甚至可以轉化為好處沽瘦。
2.2.5 做一個POC測試
部署并完整驗證一個端到端的產(chǎn)品，并從中學習涉及到的ClickHouse知識农尖、獲得實踐的專業(yè)知識等等析恋。這些經(jīng)驗有助于真正的業(yè)務系統(tǒng)設計，也能夠提前暴露系統(tǒng)實施時可能面臨的大部分問題盛卡。
2.2.6 獲取社區(qū)幫助
ClickHouse是一個開源數(shù)據(jù)庫绿满。所以最好的支持是社區(qū)。Yandex支持的telegram和google group是最好的地方窟扑，讓新手學習更多喇颁，提出問題等等。即使你計劃在某個時候獲得Altinity的專業(yè)支持嚎货，自己也可以盡可能地學習橘霎。
3. 下一步工作
一旦上述所講的先決條件步驟完成，你將獲得適用于你方業(yè)務用例的一些ClickHouse專業(yè)知識殖属，并且有信心評估ClickHouse是否適用于你的業(yè)務姐叁。如何進一步推進取決于你的系統(tǒng)的復雜性。之前的POC可能演變成生產(chǎn)部署洗显，也可能你需要從頭開始鼓搗點兒新玩意兒（因為某個業(yè)務的POC的場景不一定適用所有業(yè)務）外潜。如果一個業(yè)務需要遷移，需要分析生產(chǎn)數(shù)據(jù)的時間要求挠唆，需要設計集成方案等等处窥。正確的QA和測試也需要列入計劃。
對于一些公司來說玄组，只需幾個星期就可以完全切換到ClickHouse滔驾，而龐大的項目可能需要一年的時間。
