背鍋我們是被迫的

數據庫問題‘觸發’越來越頻繁了，開發、業務人員也一直抱怨數據庫不行，作為運維人員，天天各種處理問題，還被其他部門噴，有問題矛頭全部指向數據庫。剛上任的部門領導整天也是壓力山大，內部會議分析了當前的情況，最終解決方案是架構變更。當前的生產系統運行在Mysql上，從開始的保留半年的數據，到現在縮減到保留不足三個月的數據，全量數據實時同步到Hadoop，隨著業務的發展，Mysql和Hadoop的數據量都越來越多，系統已經不堪重負了。

架構替換選型開始

綜合考慮數據庫的性能和成本，決定使用Oracle/PostgreSql+ClickHouse/GreenPlum的架構

備選架構生產數倉

1	Oracle	ClickHouse
2	Oracle	GreenPlum
3	PostgreSql	ClickHouse
4	PostgreSql	GreenPlum

當前公司的運維人員普遍對Oracle、Mysql、Hadoop比較熟悉。綜合考慮數據庫的軟件成本和人員的學習成本。領導傾向于使用Oracle+ClickHouse的方案，簡單的測試后性能確實提升了不少，由于使用ClickHouse需要對數倉的表進行寬表改造，表改造方案需要的人力和時間太長，故該方案一直卡在寬表改造階段。

選型重回對比階段

一次偶然的機會，領導接觸到了YMatrix數據庫。據說是一款同時支持在線事務處理（OLTP）、在線分析處理（OLAP）和物聯網時序應用的超融合型分布式國產數據庫產品，兼容PostgreSQL/Greenplum協議。領導說，現在方案還未實施，要不你抽時間測試一下。ClickHouse實施過程還不知道什么時候能開始，如果有一種新架構能滿足現在的需求（性能成本綜合考慮），對我們來說是一件好事。通過對YMatrix的慢慢了解，我感覺這個架構正是我們期盼出現的架構。話不多說，直接對比測試，看效果。

架構框架對比

整體架構來對比，YMatrix架構更簡潔，融合了生產庫和數倉，對于整個數據流動、數據存儲、運維、開發來說，成本大大的降低了。

架構要求對比

當前架構系統需要滿足以下要求：
? 高可用
? 高吞吐
? 高性能
? 支持事務
? 大數據生態友好
? 集群的擴展性好
兩種架構基于架構要求對比：
高可用
對于兩種架構而言。Oracle Rac是一種高可用架構，ClickHouse通過副本實現高可用；YMatrix通過primary和mirror實現高可用。兩種架構都是可以保證數據庫系統的高可用性
高吞吐
Oracle作為OLTP數據庫的佼佼者，能滿足高吞吐的需求，ClickHouse作為一個純OLAP數據庫，在吞吐方面需避免出現高吞吐情況，官方建議每秒最多查詢100次，更新和插入也盡量使用批的方式進行。Oracle和ClicHouse的組合架構可以忽略掉ClickHouse的短板。YMatrix支持高并發連接下的毫秒級OLTP業務的增、刪、改、查操作。支持上千直連并發，借助連接池可以到上萬并發。
高性能
兩種架構都屬于高性能架構。Oracle常用的有星型模型、雪花模型等，單表、多表關聯小數據量查詢性能優異，ClickHouse單表查詢效率快，多表關聯性能差，主要使用場景是大寬表，對于數據分析而言靈活性差。YMatrix支持大寬表、星型模型、雪花模型等，不管是單表查詢還是多表多表關聯性能都極佳。當前的報表業務場景，多表關聯分析占主導，前期的Oracle+ClickHouse方案就卡在寬表改造階段。
支持事務
Oracle和YMatrix都是支持事務的，ClickHouse不支持事務。Oracle+ClickHouse組合架構，需借助Oracle支持事務的能力來保證數據的質量，然后定時同步到ClickHouse。
大數據生態的友好性
ClickHouse數據模型單一化，對相對固定的場景，需將業務表改造成寬表，效率快的同時極大的損失了數據分析靈活性。盡管業務線的用戶對此感知并不強，但是哪有什么歲月靜好，不過是有人替你負重前行。數據模型要多樣化、具備靈活性，才大數據分析場景的需求形態。例如常用的星型模型、雪花模型不僅靈活還不損失性能，這種模式才能讓數據分析既輕松又暢快。YMatrix數據模型多樣化，不管是寬表的單表查詢或者多表關聯星型模型、雪花模型都有很好的效率，數據分析靈活。從管理、分析與應用長遠來看，YMatrix更適合做大數據生態建設。
集群擴展性
ClickHouse和YMatrix都支持集群的擴容。ClickHouse需要在所主機修改配置文件，因此需要停機擴容。數據無法自動均衡，需要在新節點手動創建本地表，修改節點的權重，讓新數據優先寫新節點，當新節點數據量與舊節點差不多時，把權重調一致。YMatrix支持通過UI界面在線擴容，操作簡單，可以自定義數據重分布時間，將原數據重新分布到所有節點。

技術發展趨勢

話說天下大勢，合久必分，分久必合，數據庫的發展也遵從這個規律，畢竟業務的發展需求是不確定的。數據庫從1960年起源到現在。從最開始的ONE到現在的ONE TO ALL，未來引領發展趨勢必將是ALL IN ONE，伴隨新需求的是專用數據庫，專用數據庫不斷的融合進ALL IN ONE。數據庫發展到現在國內已經呈現了百花齊放的狀態，這個時候需要ALL IN ONE來解決一個系統中多種數據庫并存帶來的管理和使用上的不便。ClickHouse是ONE TO ALL的衍生品，不符合未來發展的趨勢。YMatrix緊隨未來發展的趨勢，最先提出超融合和ALL IN ONE的概念，數據庫的設計也是基于ALL IN ONE的思想。綜合技術考慮，用未來的技術解決現在以至未來幾年的問題才是王道。

成本對比

開發成本
相對于Oracle+ClickHouse技術架構，使用YMatrix，開發工程師無需在不同的數據源之間來回切換，無需把數據從不同數據源拉到內存中進行復雜計算，無需重新發明輪子而借助強大的SQL進行業務數據處理，實現數據獨立性、應用層和數據層的解耦，大幅提升開發效率。特別在產品快速迭代，需要頻繁增減字段的時候，更加高效。
運維成本
運維人員只需要維護一種數據庫，無需將精力分攤到多種數據庫上，大幅降低數據處理核心架構的復雜性、提升運維的效率。
軟硬件成本及數據管理成本
避免采購眾多的單體產品，大幅降低產品投入；避免數據在不同系統間冗余存儲，大幅降低存儲空間投入；避免復雜的數據流動，大幅減低數據管理投入；超融合架構大幅降低了運維投入。

撥開云霧見青天

綜合對比YMatrix架構與Oracle+ClickHouse架構，領導決定對兩種架構做一個業務開發上的對比。部署Oracle+ClickHouse數據庫后，開發人員測試反饋，比之前的架構效率快了一些，但是表數據同步改造方面比較繁瑣。對業務開發而言，沒有很明顯的改變。部署YMatrix架構后，開發人員在測試的當天，跑來問我們采用的什么架構，可以做到多個數據庫同時接入，數據質量驗證也沒問題，效率比之前有了很大的提升，以后是不是就定下來使用這套架構了？我反問道：你還有更好的推薦嗎？
終于完成了這次架構選型改造，接下來就是數據和業務遷移了，未來很久都不在為數據庫選型犯愁了。

總結

以上是生活随笔為你收集整理的数据库选型之路YMatrix与Clickhouse对比的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。