POC：POC測試，即Proof of Concept，是業界流行的針對客戶具體應用的驗證性測試，根據用戶對采用系統提出的性能要求和擴展需求的指標，在選用服務器上進行真實數據的運行，對承載用戶數據量和運行時間進行實際測算，并根據用戶未來業務擴展的需求加大數據量以驗證系統和平臺的承載能力和性能變化。

Vertica：Vertica是一款基于列存儲的MPP （massively parallel processing）架構的數據庫。它可以支持存放多至PB（Petabyte）級別的結構化數據。Vertica是由關系數據庫大師Michael Stonebraker(2014 年圖靈獎獲得者)所創建，于2011年被惠普收購并成為其核心大數據平臺軟件。

Altinity:Altinity是一家ClickHouse的服務供應商。

ClickHouse是一個非常好的分析數據庫選擇，不僅適用于初創公司，也適用于那些已經將大量資源投入分析解決方案，但對結果并不完全滿意的公司。

在本文中，我們將討論企業如何以及何時考慮ClickHouse遷移項目，以及他們可能會面臨的挑戰。我們沒有透露公司名字，但每個例子都有一個真實世界的原型。

1.什么時候遷移？

遷移總是一個痛苦的過程。如果你搬到另外一個房子或者另一個數據庫，這并不重要，但是總是要付出很多努力，這期間會經歷困擾，挫折等等。但是最后的結果是值得挑戰的，這是激勵你繼續前進的動力。那么考慮遷移到ClickHouse的動機是什么？

1.1 性能問題

其中一個主要原因是數據量大增，性能下降。使用流行的開源MySQL或PostreSQL數據庫來實現一個demo甚至是生產系統是非常容易的。數據大小比較小，索引大小適合內存，數據緩存命中率足夠高，在這樣的情形下它能夠正常提供服務。不幸的是，這樣一個理想情形最終會走到盡頭，查詢會變得越來越慢。你可以通過增加更多的內存，訂購更快的磁盤等等來解決問題，（這只是在縱向擴展），但這只是拖延解決本質問題：你該如何橫向擴展你的數據庫系統？

ClickHouse在這里可以幫到很多。即使在同一臺物理服務器上運行，與OLTP數據庫相比，它通?？梢员萇LTP負載快100-500倍的查詢性能。如果還不夠，ClickHouse集群可以很容易地堆出來，以解決任何規模的問題。

許多在性能問題上苦苦掙扎的公司，嘗試了不同的開源替代方案，最終他們發現ClickHouse是他們的銀彈。

1.2 橫向擴展成本

在ClickHouse上市之前，很多公司已經使用商用DBMS部署了分析解決方案?；萜誚ertica可能是最好的商用分析解決方案。Vertica價格是昂貴滴，但在不太大的TB級業務上，對于小公司來說價格也還負擔的起。當業務要求將數據擴展10或100倍時，畫面就不那么好看了（注意，數據量的成倍增加并不總是意味著公司利潤的成倍增加）。商業數據庫管理系統擴大數據收費會大大增加（雖然會提供一定量的折扣）。這種場景下有些公司可能會考慮更換數據平臺。看這里，ClickHouse通過一系列專業知識來使硬件最大化發揮它們的功力。

1.3 持有成本

云數據庫為分布式數據庫部署提供了最快捷的解決方案。Google Big Query，Amazon RedShift或SnowflakeDB是非常好的產品。他們允許非?？焖俚匕惭b并使系統能夠正常運行。但是，一段時間以來，一些公司想知道快速啟動的價格是否是長期合理的。我們已經在亞馬遜和專用服務器上運行了一些ClickHouse的基準測試，并將其與RedShift進行了比較。例如，【通過這篇文章分析】，我們得出結論：在Amazon中運行ClickHouse的成本比類似執行的RedShift實例要低幾倍。【這篇文章有介紹如何評估成本降低】，與Google Big Query和Athena相比ClickHouse明顯勝出，并且會顯著降低成本。

這里的另一個考慮是ClickHouse部署不是供應商鎖定的。公司可以將ClickHouse解決方案部署到Amazon，專用服務器，私有云或KodiakData等專用云，從而以最靈活的方式優化其部署和成本結構。

2.如何遷移？

ClickHouse是一個不尋常的數據庫，有很多很酷的功能和設計決策，以獲得最佳性能。然而，學習如何最有效地使用ClickHouse需要一段時間。ClickHouse的限制顯示了硬幣的另一面。ClickHouse缺少一些比較成熟的數據庫提供的功能。這使遷移項目變得復雜。

CH的一些限制：

不支持真正的刪除/更新支持 不支持事務（與Spark和大部分大數據系統一樣）

不支持二級索引（和Spark和大部分大數據系統一樣）

自己的協議（不支持MySQL協議）

有限的SQL支持，join實現與眾不同。如果需要在從MySQL或Spark進行遷移，則可能必須重新編寫包含聯接的所有查詢。

不支持窗口功能

2.1 ClickHouse遷移的主要挑戰

遷移到ClickHouse時，您可能會遇到以下挑戰。

2.1.1 模式確認：

架構是性能的關鍵。因此，需要對ClickHouse最佳實踐有很好的理解，表引擎如何工作，字典是什么等等。適當的模式能更好的發揮出ClickHouse的能力。

2.1.2 可靠的數據吞吐：

ClickHouse允許在一致性和速度之間進行平衡，這些權衡對于理解和管理很重要，特別是在分布式環境中。數據分配和復制、可擴展和可靠的系統需要恰當的設計。ClickHouse在數據分發和復制方面非常靈活，沒有特定的方法。

2.1.3 客戶端界面：

迄今為止，主要的ClickHouse問題之一是非標準的SQL語法。它是非常強大的，有很多擴展，但它不是標準的。這使得有時很難與使用SQL的客戶端工具進行交互。這個問題已經被ClickHouse開發者很好的理解，我們可以期待ClickHouse在將來支持SQL-92或更高版本的標準。

2.2 做好準備

任何移植項目都應該從計劃開始。我們提出以下方法來降低風險并確保遷移項目取得成功。

2.2.1 確認使用情況

確認ClickHouse是否適配業務是非常重要的。ClickHouse可能更適合流式或批次入庫的時序數據。正如邁克爾·斯通布拉克（Michael Stonebraker）在10年前的游戲改變文章中所寫的：“One size does not fit all” - ClickHouse不應該被用作通用數據庫。

2.2.2 檢查基準

有許多基準測試可用，您可以根據您已經使用的數據庫找到基準。一些基準的鏈接可以【看看這里】。

2.2.3 運行自己的基準

眼見為實，使用真實數據運行基準并與現有生產系統進行比較總是很有意義。

2.2.4 仔細分析ClickHouse限制，而非功能

管理人員經常只注意功能，但忽略了局限性。開發人員往往更加懷疑這玩意是不是真的好用。ClickHose的特性確實好用，但更多的時候，它的限制可能會成為絆腳石。

你需要評估ClickHouse的各種限制，例如ClickHouse的分區限制，不支持更新和刪除，不支持事務等等的缺點，是否和你的業務情形匹配。

但是并不要無端的害怕這些缺點，大多數情況下ClickHouse的限制可以被解決，甚至可以轉化為好處。

2.2.5 做一個POC測試

部署并完整驗證一個端到端的產品，并從中學習涉及到的ClickHouse知識、獲得實踐的專業知識等等。這些經驗有助于真正的業務系統設計，也能夠提前暴露系統實施時可能面臨的大部分問題。

2.2.6 獲取社區幫助

ClickHouse是一個開源數據庫。所以最好的支持是社區。Yandex支持的telegram和google group是最好的地方，讓新手學習更多，提出問題等等。即使你計劃在某個時候獲得Altinity的專業支持，自己也可以盡可能地學習。

3. 下一步工作

一旦上述所講的先決條件步驟完成，你將獲得適用于你方業務用例的一些ClickHouse專業知識，并且有信心評估ClickHouse是否適用于你的業務。如何進一步推進取決于你的系統的復雜性。之前的POC可能演變成生產部署，也可能你需要從頭開始鼓搗點兒新玩意兒（因為某個業務的POC的場景不一定適用所有業務）。如果一個業務需要遷移，需要分析生產數據的時間要求，需要設計集成方案等等。正確的QA和測試也需要列入計劃。

對于一些公司來說，只需幾個星期就可以完全切換到ClickHouse，而龐大的項目可能需要一年的時間。