哪個(gè)國(guó)際數(shù)據(jù)庫(kù)軟件，做了一個(gè)不靠譜的數(shù)據(jù)庫(kù)項(xiàng)目，被人所詬病。Oracle，當(dāng)然是大名鼎鼎的ORACLE。

大家是否記得 Oracle的一個(gè)數(shù)據(jù)庫(kù)產(chǎn)品 MySQL中的一個(gè)項(xiàng)目 NDB，說(shuō)這個(gè)可能還有人想不起來(lái)，MySQL Cluster，想起來(lái)了吧。

曾經(jīng)MySQL推出的一個(gè)MySQL的高可用模式MySQL Cluster， 為什么說(shuō)這是一個(gè)失敗的產(chǎn)品，因?yàn)檫@個(gè)產(chǎn)品在以下幾個(gè)地方，有一些值得人思考的問(wèn)題。

產(chǎn)品設(shè)計(jì)混亂，如果ORACLE有 RAC，Oracle Real Applicaiton Clusters，那么這個(gè)產(chǎn)品就是在此概念上做出來(lái)的，MySQL也應(yīng)該有一個(gè)和Oracle 一樣的高可用產(chǎn)品的思路。

可我特別想問(wèn)幾個(gè)問(wèn)題，如果ORACLE 有RAC ，那么客戶關(guān)注的是什么，用MySQL的客戶為什么也要關(guān)心這個(gè)事情。ORACLE 的客戶畫像是什么，ORACLE的產(chǎn)品經(jīng)理應(yīng)該有這個(gè)分析和報(bào)告。

那么按照ORACLE的客戶畫像來(lái)，翻印的MySQL客戶也有這個(gè)需求，是從何而來(lái)的這個(gè)結(jié)論。Oracle RAC 是一種“共享一切”的數(shù)據(jù)庫(kù)集群架構(gòu)。它由兩個(gè)或多個(gè)計(jì)算機(jī)構(gòu)成一個(gè)集群，這些計(jì)算機(jī)（節(jié)點(diǎn)）通過(guò)高速網(wǎng)絡(luò)（Interconnect）連接，并共享同一組磁盤存儲(chǔ)（Shared Storage）。

MySQL的NDB，一個(gè)類似Oracle 的RAC的東西，最初是為電信計(jì)費(fèi)設(shè)計(jì)的，他強(qiáng)調(diào)的是毫秒響應(yīng)時(shí)間，高可用以及分布式冗余，并且要求在此上的事務(wù)高度結(jié)構(gòu)化，且短事務(wù)。

此時(shí)不禁要問(wèn)一句，ORACLE 你已經(jīng)有了ORACLE這樣的數(shù)據(jù)庫(kù)巨無(wú)霸，而搞出MySQL NDB的緣由是什么。

NDB的核心設(shè)計(jì)是在分片和shared nothing的架構(gòu)上，數(shù)據(jù)分布在多個(gè)節(jié)點(diǎn)，對(duì)于主鍵的查詢速度非?？?，而只要涉及到普通數(shù)據(jù)庫(kù)的 join, group by 等就馬上不行了。

同時(shí)ORACLE在NDB上進(jìn)行了一些努力，但是基于分布式的概念在0RACLE天生的缺陷，如設(shè)計(jì)了協(xié)調(diào)器而數(shù)據(jù)的性能大量損耗在網(wǎng)絡(luò)通信和數(shù)據(jù)傳輸中。

同時(shí)基于NDB非常不擅長(zhǎng)復(fù)雜查詢的特性，雖然也研究了下推的方式減少網(wǎng)絡(luò)和節(jié)點(diǎn)傳輸數(shù)據(jù)，但存在JOIN的列的類型限制等諸多問(wèn)題。

同時(shí)一些自身的ORACLE的專家，還試圖給ORACLE刷白，我們來(lái)看這段。

But the way MySQL Cluster splits data in a sharded manner over the data node pairs means that it supports queries best if they are lookups for specific rows by their primary key. Range queries likely have to span many data nodes. Join queries also have to span many data nodes. Complex reporting queries have terrible performance.

Many people who don't understand this tradeoff attempt to port their existing application to use MySQL Cluster, and are disappointed in the performance. It may give no improvement over using InnoDB, or it can even show a drop in performance.

This isn't a weakness of MySQL Cluster -- it's a weakness of a physically sharded architecture in general.

但是 MySQL Cluster 在數(shù)據(jù)節(jié)點(diǎn)對(duì)上以分片方式分割數(shù)據(jù)的方式意味著，如果查詢是通過(guò)主鍵查找特定行，它最支持查詢。范圍查詢可能必須跨越許多數(shù)據(jù)節(jié)點(diǎn)。連接查詢也必須跨越許多數(shù)據(jù)節(jié)點(diǎn)。復(fù)雜的報(bào)告查詢性能很差。 許多不理解這種權(quán)衡的人試圖將他們現(xiàn)有的應(yīng)用程序移植到使用 MySQL 集群，并對(duì)性能感到失望。它可能不會(huì)比使用 InnoDB 有任何改進(jìn)，甚至?xí)@示性能下降。 這不是 MySQL Cluster 的弱點(diǎn) —— 這是一般物理分片架構(gòu)的弱點(diǎn)。

這上面這位仁兄的解釋是，不支持復(fù)雜查詢不是MySQL Cluster的弱點(diǎn)，而是分片結(jié)構(gòu)的弱點(diǎn)。

繼續(xù)辯解為mysql cluster

硬件預(yù)算。您需要大量服務(wù)器，而每臺(tái)服務(wù)器都需要大量 RAM。您可能還需要將集群放在專用子網(wǎng)上，并為您的所有主機(jī)購(gòu)買高端 NIC。軟件是免費(fèi)的，但基礎(chǔ)設(shè)施和操作可能很昂貴。 配置和調(diào)優(yōu)知識(shí)。NDB 不是 MySQL 站點(diǎn)中最常用的存儲(chǔ)引擎 InnoDB。所以很多調(diào)優(yōu)智慧和留檔并不適用。找到能夠有效操作 MySQL 集群站點(diǎn)的 DBA 很難?；蛘吣憧梢詮囊粋€(gè)有主流 MySQL 知識(shí)的稱職 DBA 開始，給他們時(shí)間來(lái)培訓(xùn) NDB，但這也既耗時(shí)又昂貴。 模式設(shè)計(jì)。任何分片架構(gòu)都需要有一個(gè)旨在利用分片的模式。如果查詢只觸及一個(gè)分片，查詢效果很好。但有時(shí)您還需要運(yùn)行一個(gè)范圍查詢，該查詢將觸及所有分片。我的雇主Percona為幾家公司提供咨詢，他們閱讀了 MySQL 集群的高基準(zhǔn)數(shù)字，因此他們簡(jiǎn)單地將現(xiàn)有應(yīng)用程序?qū)?MySQL 集群實(shí)例，發(fā)現(xiàn)它比使用傳統(tǒng) MySQL 實(shí)例時(shí)性能更差。

上面一些國(guó)外數(shù)據(jù)庫(kù)專家為MySQL Cluster的辯解，讓我們可以窺見更多的MySQL Cluster的缺陷。

總結(jié)為：

1、需要大內(nèi)存，以及更多的主機(jī)，因?yàn)閿?shù)據(jù)全部要在內(nèi)存中處理

2、數(shù)據(jù)的格式和數(shù)據(jù)的操作方式，并不和MySQL完全兼容

3、之前在MySQL可以很好解決的一般復(fù)雜SQL查詢的問(wèn)題，在NDB集群并不能很好的解決

4、現(xiàn)有的應(yīng)用程序，如果構(gòu)建在MySQL上，是無(wú)法安全的且完全的移植到

5、應(yīng)該主鍵查詢，且對(duì)于范圍查詢十分的不友好。

MySQL Cluster 文檔

而官方的我找到的MYSQL CLUSTER的文檔，對(duì)于以上問(wèn)題，一概不談，都是圍繞數(shù)據(jù)庫(kù)的高可用去談?wù)摂?shù)據(jù)庫(kù)產(chǎn)品的，對(duì)于數(shù)據(jù)查詢的難點(diǎn)，和應(yīng)用的改造只字不提。

后來(lái)查了一下這個(gè)系統(tǒng)的歷史，這個(gè)系統(tǒng)并不是Oracle自研的，而是收購(gòu)Ericsson 而來(lái)了，而當(dāng)初這個(gè)系統(tǒng)的產(chǎn)生完全是針對(duì)電信行業(yè)特定的系統(tǒng)而生，并不是為了廣泛的數(shù)據(jù)庫(kù)應(yīng)用而設(shè)定的。

PPT

PPT

所以從上述的信息收集和信息的分析，MySQL Cluster本身就不是為了廣泛的數(shù)據(jù)庫(kù)客戶服務(wù)的，他出自瑞典愛立信的內(nèi)部的數(shù)據(jù)庫(kù)系統(tǒng)。

愛立信

最后根據(jù)網(wǎng)絡(luò)查詢的NDB的問(wèn)題點(diǎn)總結(jié)如下：

1、核心是同步內(nèi)存分布式架構(gòu)，shared Nothing In Memory

2、數(shù)據(jù)節(jié)點(diǎn)全部?jī)?nèi)存駐留，雖然后期支持磁盤，但是性能會(huì)急劇下降

3、所有更新操作都需要兩階段在多個(gè)節(jié)點(diǎn)提交完成，節(jié)點(diǎn)數(shù)量變大將導(dǎo)致寫放大，和網(wǎng)絡(luò)數(shù)據(jù)同步的消耗變大

4、無(wú)法完成JOIN 的數(shù)據(jù)查詢，導(dǎo)致數(shù)據(jù)庫(kù)無(wú)法完成普通數(shù)據(jù)庫(kù)可以完成的任務(wù)，官方建議使用 KEY VALUE進(jìn)行數(shù)據(jù)的提取和存儲(chǔ)。

5、系統(tǒng)沒(méi)有分布式性能優(yōu)化器，僅僅支持 RC的隔離級(jí)別

6、對(duì)于MYSQL 本身支持的功能不支持，全文索引，空間索引，約束，外鍵，觸發(fā)器，存儲(chǔ)過(guò)程，等

7、管理極其復(fù)雜，包含了 NDB_MGMD , NDBD ,MYSQLD 等組件配置極其復(fù)雜對(duì)于系統(tǒng)啟動(dòng)順序要求非常敏感。

寫到這里，讓我想起另一個(gè)數(shù)據(jù)庫(kù)的類似杰作，POSTGRESQL XL XC系統(tǒng)。

另外一些論壇中對(duì)于NDB系統(tǒng)的有一個(gè)用戶的評(píng)價(jià)，就怕出問(wèn)題，出了問(wèn)題，一修就是半天。

綜上所述，MySQL CLUSTER 系統(tǒng)是一個(gè)ORACLE 在自己數(shù)據(jù)庫(kù)產(chǎn)品中失敗的杰作，收購(gòu)，且針對(duì)極為特殊的業(yè)務(wù)場(chǎng)景，與當(dāng)前的大部分?jǐn)?shù)據(jù)庫(kù)系統(tǒng)相比，無(wú)法完成基本的JOIN SQL查詢的工作，系統(tǒng)擴(kuò)展后，并不能得到系統(tǒng)的性能提升，種種問(wèn)題。

NDB 測(cè)試場(chǎng)景（順便說(shuō)一句，ORACLE在官方文檔開始淡化 NDB CLUSTER）