[[203180]]

Mysql 安裝簡(jiǎn)單，速度較快，功能豐富。另外它還是開(kāi)源運(yùn)動(dòng)的標(biāo)桿，它的偉大成就向我們展示了一個(gè)成功的公司是可以建立在開(kāi)源代碼之上的。

然而用過(guò) mysql 的人都曾對(duì)著顯示器揮舞過(guò)拳頭。但你不可能發(fā)明一種每秒能保存成千上萬(wàn)行互聯(lián)網(wǎng)數(shù)據(jù)，并且一點(diǎn)錯(cuò)誤都沒(méi)有的技術(shù)吧。

為了在這個(gè)秋天躁起來(lái)，我們列舉了 8 個(gè)抱怨開(kāi)源關(guān)系型數(shù)據(jù)庫(kù)的理由。下面列舉的理由中不僅限于 MySQL，有一些是針對(duì)關(guān)系型數(shù)據(jù)庫(kù)的。如果我們沒(méi)有理清楚關(guān)系型數(shù)據(jù)庫(kù)和 MySQL，我們將會(huì)永遠(yuǎn)陷入 90 年代的思想上。我們需要推倒然后重建這些?；蛘呶覀冝D(zhuǎn)向使用一個(gè)最近流行的，存在時(shí)間沒(méi)有長(zhǎng)到可以列出一堆像下面一樣的理由的數(shù)據(jù)庫(kù)。

根深蒂固的 bugs

任何大的軟件包都有 bug。但稍微深入了解一下，就會(huì)發(fā)現(xiàn)和 Mysql 相關(guān)的 bugs 自成體系。突然你就需要留心，因?yàn)?NULL 并不是以同樣的方式出現(xiàn)，外鍵約束也沒(méi)有像你想像的那樣執(zhí)行，連主鍵自動(dòng)增長(zhǎng)也會(huì)出錯(cuò)。

小問(wèn)題大量存在，而且并不總是可以修復(fù)，這就是為什么一些人保持一個(gè)列表。還好 MySQL 維護(hù)著一個(gè)非常好的 bug 報(bào)告系統(tǒng)，讓我們可以知道我些我們無(wú)法想像的事情，知道其他人也在經(jīng)受同樣的磨難。

關(guān)系表的不靈活性

關(guān)系表具有條理性，條理性是好的——但是，它使得程序員不得不編造或硬塞一些數(shù)據(jù)到已經(jīng)定義好模式的列中。NoSQL 開(kāi)始越來(lái)越受到歡迎的原因之一，就是它為程序員提供了足夠的靈活性，來(lái)加速數(shù)據(jù)庫(kù)的使用。如果一個(gè)街道地址需要增加一行，那么，你可以將它很容易地插入到一個(gè) NoSQL 文檔中。如果你想添加一個(gè)完整的新的數(shù)據(jù)塊，無(wú)論它包含什么內(nèi)容，文檔模型也可以原封不動(dòng)地接受你的數(shù)據(jù)，而不必改為它要求的數(shù)據(jù)格式。

試想一下，你用整數(shù)格式建立了一個(gè)全部是郵編的表格。這個(gè)表是十分高效的，它執(zhí)行的規(guī)則也很好。突然一次，有人上傳了一個(gè)使用了連字符的九位數(shù)郵編?；蛘哌€有可能，你得到了一位來(lái)自加拿大客戶的信件，上面寫(xiě)有郵政編碼。

這時(shí)，一切都亂了。老板要求網(wǎng)站要在幾小時(shí)內(nèi)恢復(fù)正常工作。然而，現(xiàn)在已經(jīng)沒(méi)有時(shí)間來(lái)重建數(shù)據(jù)庫(kù)。程序員可以做什么?也許，可以使用黑客手段把加拿大郵政編碼由 base64 的數(shù)字格式改為 base 10 格式?或者設(shè)置一個(gè)使用轉(zhuǎn)義編碼的輔助表格，用來(lái)說(shuō)明真正的郵政編碼或者其他?誰(shuí)知道呢?到處都有黑客，他們都是危險(xiǎn)的。但你沒(méi)有時(shí)間來(lái)搞定它。

MySQL 的關(guān)聯(lián)規(guī)則讓每個(gè)人都誠(chéng)實(shí)和謹(jǐn)慎，但它能強(qiáng)制我們避開(kāi)易受攻擊和欺騙的麻煩。

JOIN 聯(lián)合查詢

曾幾何時(shí)，將數(shù)據(jù)分表保存是計(jì)算機(jī)科學(xué)史上的偉大創(chuàng)新。分開(kāi)后的表不僅結(jié)構(gòu)簡(jiǎn)單，也簡(jiǎn)化了使用。但它卻需要使用 join 語(yǔ)句進(jìn)行查詢。

sql 通過(guò)一系列 join 構(gòu)建的復(fù)雜查詢將開(kāi)發(fā)者推入了困惑與絕望的深淵。而且存儲(chǔ)引擎也需要以最優(yōu)的方式來(lái)高效地解析 join 語(yǔ)句。開(kāi)發(fā)者需要絞盡腦汁編寫(xiě)查詢語(yǔ)句，然后數(shù)據(jù)庫(kù)對(duì)其進(jìn)行解析。

這就是很多注重運(yùn)行速度的開(kāi)發(fā)者放棄數(shù)據(jù)分表轉(zhuǎn)而使用不規(guī)范數(shù)據(jù)表的原因。不區(qū)分?jǐn)?shù)據(jù)實(shí)體，將所有數(shù)據(jù)保存到一個(gè)大表中——以避免復(fù)雜的查詢。這樣確實(shí)很快，并且服務(wù)器也不會(huì)耗盡內(nèi)存。

磁盤(pán)空間現(xiàn)在很廉價(jià)。8TB 的磁盤(pán)已經(jīng)在售，更大的也要上市了。我們不再需要為使用 join 而絞盡腦汁了。

分支的混亂

是的，一個(gè)可靠的、得到良好支持的 MySQL 分支，可以帶來(lái)競(jìng)爭(zhēng)和選擇，但是它也引起困惑和混亂。更糟糕的是，一個(gè)稱為 MariaDB 的MySQL 分支，由 Monty Widenius 維護(hù)著。他同樣也在參與編寫(xiě) MySQL。那么，MariaDB 是真正獨(dú)立的值得我們擁護(hù)的嗎?或者它是 MySQL?我們是否應(yīng)該堅(jiān)持使用由創(chuàng)建原始 MySQL 數(shù)據(jù)庫(kù)的組織運(yùn)營(yíng)的核心代碼?或者我們應(yīng)該加入那些被認(rèn)為更聰明的，往往很酷的背叛者?

還有，我們應(yīng)當(dāng)如何獲得關(guān)于兼容性的信息?一方面，我們被確信 MariaDB 和 MySQL 十分地相似。另一方面，我們要相信有差異——不然為什么大家都在爭(zhēng)論它?也許它們?cè)谛阅芎臀覀儾樵兊姆秶鷥?nèi)，在兩個(gè)陣營(yíng)中工作方式相同?但也許他們不同 - 或者將來(lái)會(huì)不同。

存儲(chǔ)引擎混亂

MySQL 不是事實(shí)上的同一的數(shù)據(jù)庫(kù);它由幾個(gè)數(shù)據(jù)庫(kù)組成，它們的大多數(shù)細(xì)節(jié)都被統(tǒng)一的表面所掩蓋。在開(kāi)始的時(shí)候，有一個(gè) MyISAM 引擎，它很快但是在前后一致上不能做到完備。有時(shí)候你需要速度并且可以接受不一致的結(jié)果時(shí)是很好的。

當(dāng)人們需要更多時(shí)，具備完整事務(wù)支持的 InnoDB 出現(xiàn)了。但這還不夠。現(xiàn)在，它可能有 20 種存儲(chǔ)引擎的選擇——這足以使一個(gè)數(shù)據(jù)庫(kù)管理員瘋狂。當(dāng)然，有些時(shí)候在不同的存儲(chǔ)引擎之間切換而不必重寫(xiě)你的 SQL 是很好的，但是切換后總會(huì)帶來(lái)混亂。這個(gè)表格我選擇的引擎是 MyISAM 還是 innoDB 呢?或者，我決定輸出的數(shù)據(jù)是 CSV 格式的嗎?

盈利的動(dòng)機(jī)

雖然 MySQL 是一款成功的開(kāi)源產(chǎn)品，但它仍然是一門(mén)生意，里面滿是靠它獲得薪水的專業(yè)開(kāi)發(fā)者。當(dāng)大多數(shù)用戶在持續(xù)地享受開(kāi)源許可證帶來(lái)的最佳體驗(yàn)時(shí)，毫無(wú)疑問(wèn)這家公司還在為賺取足夠的錢(qián)來(lái)維持運(yùn)營(yíng)而努力。這導(dǎo)致自由代碼在 “社區(qū)版” 和出售給企業(yè)的完整產(chǎn)品之間產(chǎn)生了奇怪的分岐。

你應(yīng)該付錢(qián)嗎?你在這里掙到了多少錢(qián)?在社區(qū)版之上開(kāi)展經(jīng)營(yíng)行為是否公平?企業(yè)版中額外的功能，是否只是一個(gè)噱頭來(lái)引誘我們不斷付費(fèi)呢?這至少說(shuō)明一點(diǎn)，它是另一組需要回答的問(wèn)題。選用哪個(gè)版本?遵照哪種許可證?選用它的哪個(gè)功能集?

原生 JSON 支持的缺乏

看 MySQL 的年齡最好的辦法是安裝它，然后你會(huì)意識(shí)到需要添加更多的驅(qū)動(dòng)程序使它可用。MySQL 通常在 3306 端口上通信，它一般輸出的是它自己難以理解的格式化數(shù)據(jù)。如果你想讓你的代碼和它通信，你必須添加另一層的代碼，將 MySQL 的語(yǔ)言轉(zhuǎn)換成有用的東西。這些層的代碼，以庫(kù)的形式分發(fā)，經(jīng)常需要人們購(gòu)買(mǎi)一個(gè)商業(yè)的許可證。

現(xiàn)代數(shù)據(jù)存儲(chǔ)層通常直接以 JSON 通信。雖然 MySQL 和 MariaDB 現(xiàn)在有能力解析 SQL 中的 JSON 部分，但這還遠(yuǎn)遠(yuǎn)不夠好，原生的 JSON 接口已經(jīng)在 CouchDB，MongoDB，或任何最新的工具中廣泛使用。

封閉源和專有模塊的興起

我說(shuō)過(guò) MySQL 是開(kāi)源的嗎?它是，但除了一些在” 開(kāi)源核心 “周邊開(kāi)發(fā)的一些較新的、非開(kāi)源的代碼、專有模塊。程序員需要吃飯，Oracle 需要拿它的辛苦成果來(lái)?yè)Q錢(qián)，這是商業(yè)的現(xiàn)實(shí)之一。它不像那些醫(yī)院，使用 MySQL 可以免費(fèi)醫(yī)療護(hù)理。它不象那些農(nóng)民，使用 MySQL 可以贈(zèng)送食物。

要求 MySQL 始終堅(jiān)持在一個(gè)很高的標(biāo)準(zhǔn)是有點(diǎn)不公平的，因?yàn)殚_(kāi)源的成功可能是一個(gè)圈套。這是因?yàn)樗_(kāi)始可以免費(fèi)，但并不意味著它可以始終如此。如果企業(yè)需要許多新的功能，他們將不得不用這種或那種方式付費(fèi)。有時(shí)向 Oracle 付費(fèi)，比自己來(lái)編寫(xiě)代碼要便宜得多。有時(shí)商業(yè)的、不開(kāi)源的代碼是有意義的。事實(shí)不言而喻。