背景
Starrocks和clickhouse都是非常優秀的OLAP數據庫，那么什么情況下使用clickhouse，什么場景下使用starrocks呢，本文就簡單列舉一下他們的優缺點
理由
首先兩者都是列存儲，并且都實現了列壓縮，所以從存儲中兩者的壓縮比是差不多的，所以對應的I/O消耗也是相差不大的
介紹一下Starrocks計算資源的底層實現：
- MPP并行查詢，可以充分利用多臺機器的資源
- 單機通過pineline并行執行，充分利用單機的多線程資源
- 單核CPU利用SIMD向量化進行查詢
備注： Starrocks的MPP并行是設計之初就完善好的，他自身支持動態擴展
對應的clickhouse計算資源的底層實現: - 可以通過分布式表的方式利用多臺機器的資源
- 單機利用多核的實現利用的不夠充分
- 單核CPU利用SIMD向量化進行查詢
備注：clickhouse嚴格來說是單機數據庫，他的分布式的實現都需要手動完成
OK，回到最初的問題，對于Starrocks來說，分布式的實現從設計之初就已經完成，而clickhouse分布式完全是通過手動的方式應用方組裝起來的，使用起來非常不方便，我們列舉下使用Starrocks替換Clickhouse的幾個理由
1.如果我們的表可以做成中等大小的寬表的，那么使用Starrocks和Clickhouse的實現都無所謂，兩者的性能都很出色
2.starrocks具有主鍵表，這個是真正擁有去重能力的表，同一個主鍵的數據合并雖然也是延遲進行(磁盤還是占用)，但是查詢的時候也會進行過濾獲取最新版本的主鍵記錄，所以這是一個真正意義的主鍵表，而clickhouse沒有嚴格意義的主鍵表，最接近主鍵的實現是ReplacingMergeTree，但是他的主鍵數據合并是延遲進行的，而且在這期間，查詢時會有返回新舊的主鍵記錄，需要應用自身進行處理，非常麻煩
3.Starrocks對于多表join的支持非常完善，starrocks從設計之初就考慮到了多表join的分布式實現的問題，多表join時依然可以充分利用多機/多核/SIMD的并行化能力，所以幾乎可以理解成使用starrocks的join和Mysql的join的性能相差不大，而Clickhouse對于join的實現可以用災難來形容，特別是在分布式表的join的時候，容易出錯并且性能大打折扣，當然這里并不是說starrocks的join性能有多好，只是說他可以非常好的支持join的實現
4.Starrocks的qps請求可以比clickhouse要高很多，原因在于它的FE可以擴展支持更多的QPS，但是底層的BE的瓶頸還是有限的，畢竟BE要進行數據IO和計算，此外，網絡資源也是有限的，畢竟join等操作需要進行數據的移動，所以Starrocks可以支持比較高的qps，但是由于他們都是OLAP引擎，不可能支持類似OLTP數據庫那樣的QPS，充其量也就是使用了類似后臺，定時任務等幾百到幾千左右的qps，不可能用于C端的應用
5.Starrocks的部分列更新功能，Starrocks可以更新部分列，這對于當一個表的數據是來源于多個業務方，每個業務方只更新自己對應的列的寬表來說非常有用，clickhouse是不支持部分列更新的功能的，這個功能真的很有用
6.Starrocks的物化視圖在查詢時是會進行自動改寫的，也就是不需要類似clickhouse一樣需要應用方根據不同的應用場景選擇對應的物化視圖
結論
Starrocks替換clickhouse的優點是很多的，幾乎每個功能Starrocks都可以幾乎無損的替換掉clickhouse，再加上Starrocks擁有clickhouse沒有的一些功能，所以使用Starrocks替換clickhouse除了歷史數據遷移問題外，幾乎不需要猶豫
