背鍋我們是被迫的

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

架構(gòu)替換選型開始

綜合考慮數(shù)據(jù)庫的性能和成本，決定使用Oracle/PostgreSql+ClickHouse/GreenPlum的架構(gòu)

備選架構(gòu)生產(chǎn)數(shù)倉

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

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

選型重回對比階段

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

架構(gòu)框架對比

整體架構(gòu)來對比，YMatrix架構(gòu)更簡潔，融合了生產(chǎn)庫和數(shù)倉，對于整個數(shù)據(jù)流動、數(shù)據(jù)存儲、運維、開發(fā)來說，成本大大的降低了。

架構(gòu)要求對比

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

技術(shù)發(fā)展趨勢

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

成本對比

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

撥開云霧見青天

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。