Oracle 也有做失敗的數(shù)據(jù)庫系統(tǒng)？是的今天我們來說說他

哪個國際數(shù)據(jù)庫軟件，做了一個不靠譜的數(shù)據(jù)庫項目，被人所詬病。Oracle，當然是大名鼎鼎的ORACLE。

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

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

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

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

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

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

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

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

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

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

同時一些自身的ORACLE的專家，還試圖給ORACLE刷白，我們來看這段。

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

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

繼續(xù)辯解為mysql cluster

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

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

總結(jié)為：

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

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

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

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

5、應該主鍵查詢，且對于范圍查詢十分的不友好。

MySQL Cluster 文檔

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

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

PPT

PPT

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

愛立信

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

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

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

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

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

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

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

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

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

另外一些論壇中對于NDB系統(tǒng)的有一個用戶的評價，就怕出問題，出了問題，一修就是半天。

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

NDB 測試場景（順便說一句，ORACLE在官方文檔開始淡化 NDB CLUSTER）