[[256902]]

了解如何選擇最適合你的需求的開(kāi)源數(shù)據(jù)庫(kù)。

在現(xiàn)代的企業(yè)級(jí)技術(shù)領(lǐng)域中，開(kāi)源軟件已經(jīng)成為了一股不可忽視的重要力量。借助開(kāi)源運(yùn)動(dòng)open source movement的東風(fēng)，涌現(xiàn)出了許多重大的技術(shù)突破。

個(gè)中原因顯而易見(jiàn)，盡管一些基于 Linux 的開(kāi)源網(wǎng)絡(luò)標(biāo)準(zhǔn)可能不如專(zhuān)有廠商的那么受歡迎，但是不同制造商的智能設(shè)備之間能夠互相通信，開(kāi)源技術(shù)功不可沒(méi)。當(dāng)然也有不少人認(rèn)為開(kāi)源開(kāi)發(fā)出來(lái)的應(yīng)用比廠商提供的產(chǎn)品更加好，所以無(wú)論如何，使用開(kāi)源數(shù)據(jù)庫(kù)進(jìn)行開(kāi)發(fā)確實(shí)是相當(dāng)有利的。

和其它類(lèi)型的應(yīng)用軟件一樣，不同的開(kāi)源數(shù)據(jù)庫(kù)管理系統(tǒng)之間在功能和特性上可能會(huì)存在著比較大的差異。換言之，不是所有的開(kāi)源數(shù)據(jù)庫(kù)都是平等的。因此，如果要為整個(gè)組織選擇一個(gè)開(kāi)源數(shù)據(jù)庫(kù)，那么應(yīng)該重點(diǎn)考察數(shù)據(jù)庫(kù)是否對(duì)用戶友好、是否能夠持續(xù)適應(yīng)團(tuán)隊(duì)需求、是否能夠提供足夠安全的功能等方面的因素。

出于這方面考慮，我們?cè)谶@篇文章中對(duì)一些開(kāi)源數(shù)據(jù)庫(kù)進(jìn)行了概述和優(yōu)缺點(diǎn)對(duì)比。遺憾的是，我們必須忽略一些最常用的數(shù)據(jù)庫(kù)。值得注意的是，MongoDB 最近更改了它的許可證，因此它已經(jīng)不是真正的開(kāi)源產(chǎn)品了。從商業(yè)角度來(lái)看，這個(gè)決定是很有意義的，因?yàn)?MongoDB 已經(jīng)成為了數(shù)據(jù)庫(kù)托管實(shí)際上的解決方案，約 27000 家公司在使用它，但這也意味著 MongoDB 已經(jīng)不再被視為真正的開(kāi)源產(chǎn)品。

另外，自從 MySQL 被 Oracle 收購(gòu)之后，這個(gè)產(chǎn)品就已經(jīng)不再具有開(kāi)源性質(zhì)了，MySQL 可以說(shuō)是數(shù)十年來(lái)首選的開(kāi)源數(shù)據(jù)庫(kù)。然而，這為其它真正的開(kāi)源數(shù)據(jù)庫(kù)解決方案提供了挑戰(zhàn)它的空間。

下面是三個(gè)值得考慮的開(kāi)源數(shù)據(jù)庫(kù)。

PostgreSQL

沒(méi)有 PostgreSQL 的開(kāi)源數(shù)據(jù)庫(kù)清單肯定是不完整的。PostgreSQL 一直都是各種規(guī)模企業(yè)的首選解決方案。Oracle 對(duì) MySQL 的收購(gòu)在當(dāng)時(shí)來(lái)說(shuō)可能具有一定的商業(yè)意義，但是隨著云存儲(chǔ)的日益壯大，開(kāi)發(fā)者對(duì) MySQL 的依賴程度或許并不如以前那么大了。

盡管 PostgreSQL 不是一個(gè)最近幾年才面世的新產(chǎn)品，但它卻是借助了 MySQL 相對(duì)衰落的機(jī)會(huì)才逐漸成為最受歡迎的開(kāi)源數(shù)據(jù)庫(kù)之一。由于它和 MySQL 的工作方式非常相似，因此很多熱衷于使用開(kāi)源軟件的開(kāi)發(fā)者都紛紛轉(zhuǎn)向 PostgreSQL。

優(yōu)勢(shì)

• 目前 PostgreSQL 最顯著的優(yōu)點(diǎn)是它的核心算法的效率，這意味著它的性能優(yōu)于許多宣稱更先進(jìn)數(shù)據(jù)庫(kù)。這一點(diǎn)在處理大型數(shù)據(jù)集的時(shí)候就可以很明顯地體現(xiàn)出來(lái)了，否則 I/O 處理會(huì)成為瓶頸。
• PostgreSQL 也是最靈活的開(kāi)源數(shù)據(jù)庫(kù)之一，使用 Python、Perl、Java、Ruby、C 或者 R 都能夠很方便地調(diào)用數(shù)據(jù)庫(kù)。
• 作為最常用的幾個(gè)開(kāi)源數(shù)據(jù)庫(kù)之中，PostgreSQL 的社區(qū)支持是做得最好的。

劣勢(shì)

• 在數(shù)據(jù)量比較大的時(shí)候，PostgreSQL 的效率毋庸置疑是很高的，但對(duì)于數(shù)據(jù)量較小的情況，使用 PostgreSQL 就顯得不如其它的一些工具快了。
• 盡管擁有一個(gè)很優(yōu)秀的社區(qū)支持，但 PostgreSQL 的核心文檔仍然需要作出改進(jìn)。
• 如果你需要使用并行計(jì)算或者集群化等高級(jí)工具，就需要安裝 PostgreSQL 的第三方插件。盡管官方有計(jì)劃將這些功能逐步添加到主要版本當(dāng)中，但可能會(huì)需要再等待好幾年才能出現(xiàn)在標(biāo)準(zhǔn)版本中。

MariaDB

MariaDB 是 MySQL 的真正開(kāi)源的發(fā)行版本（在 GNU GPLv2 下發(fā)布）。在 Oracle 收購(gòu) MySQL 之后，MySQL 的一些核心開(kāi)發(fā)人員認(rèn)為 Oracle 會(huì)破壞 MySQL 的開(kāi)源理念，因此建立了 MariaDB 這個(gè)獨(dú)立的分支。

MariaDB 在開(kāi)發(fā)過(guò)程中替換了 MySQL 的幾個(gè)關(guān)鍵組件，但仍然盡可能地保持兼容 MySQL。MariaDB 使用了 Aria 作為存儲(chǔ)引擎，這個(gè)存儲(chǔ)引擎既可以作為事務(wù)式引擎，也可以作為非事務(wù)式引擎。在 MariaDB 分叉出來(lái)之前，就有一些人推測(cè) Aria 會(huì)成為 MySQL 未來(lái)版本中的標(biāo)準(zhǔn)引擎。

優(yōu)勢(shì)

• 由于 MariaDB 頻繁進(jìn)行安全發(fā)布，很多用戶選擇使用 MariaDB 而不選擇 MySQL。盡管這不一定代表 MariaDB 會(huì)比 MySQL 更加安全，但確實(shí)表明它的開(kāi)發(fā)社區(qū)對(duì)安全性十分重視。
• 有一些人認(rèn)為，MariaDB 的主要優(yōu)點(diǎn)就是它在堅(jiān)持開(kāi)源的同時(shí)會(huì)與 MySQL 保持高度兼容，這就意味著從 MySQL 向 MariaDB 的遷移會(huì)非常容易。
• 也正是由于這種兼容性，MariaDB 也可以和其它常用于 MySQL 的語(yǔ)言配合使用，因此從 MySQL 遷移到 MariaDB 之后，學(xué)習(xí)和調(diào)試代碼的時(shí)間成本會(huì)非常低。
• 你可以將 WordPress 和 MariaDB（而不是 MySQL）配合使用從而獲得更好的性能和更豐富的功能。WordPress 是最受歡迎的內(nèi)容管理系統(tǒng)Content Management System（CMS），占據(jù)了一半的互聯(lián)網(wǎng)份額，并且擁有活躍的開(kāi)源開(kāi)發(fā)者社區(qū)。各種第三方插件在 WordPress 和 MariaDB 配合使用時(shí)都能夠正常工作。

劣勢(shì)

• MariaDB 有時(shí)會(huì)變得比較臃腫，尤其是它的 IDX 日志文件在長(zhǎng)期使用之后會(huì)變得非常大，最終導(dǎo)致性能下降。
• 緩存是 MariaDB 的另一個(gè)工作領(lǐng)域，并沒(méi)有期望中那么快，這可能會(huì)讓人有所失望。
• 盡管 MariaDB 最初承諾兼容 MySQL，但目前 MariaDB 已經(jīng)不是完全兼容 MySQL。如果要從 MySQL 遷移到 MariaDB，就需要額外做一些兼容工作。

SQLite

SQLite 可以說(shuō)是世界上實(shí)現(xiàn)最多的數(shù)據(jù)庫(kù)引擎，因?yàn)樗缓芏嗔餍械?web 瀏覽器、操作系統(tǒng)和手機(jī)所采用。它最初是作為 MySQL 的輕量級(jí)分支所開(kāi)發(fā)的。SQLite 和很多其它的數(shù)據(jù)庫(kù)不同，它不采用客戶端-服務(wù)端的引擎架構(gòu)，而是將整個(gè)軟件嵌入到每個(gè)實(shí)現(xiàn)當(dāng)中。

這樣的架構(gòu)讓 SQLite 擁有一個(gè)強(qiáng)大的優(yōu)勢(shì)，就是在嵌入式系統(tǒng)或者分布式系統(tǒng)中，每臺(tái)機(jī)器都搭載了數(shù)據(jù)庫(kù)的整個(gè)實(shí)現(xiàn)。這樣的做法減少了系統(tǒng)間的調(diào)用，從而大大提高了數(shù)據(jù)庫(kù)的性能。

優(yōu)勢(shì)

• 如果你需要構(gòu)建和實(shí)現(xiàn)一個(gè)小型數(shù)據(jù)庫(kù)，SQLite 可能是最好的選擇。它小而靈活，不需要費(fèi)工夫?qū)で蟾鞣N變通方案，就可以在嵌入式系統(tǒng)中實(shí)現(xiàn)。
• SQLite 體積很小，因此速度極快。其它的一些高級(jí)數(shù)據(jù)庫(kù)可能會(huì)使用復(fù)雜的優(yōu)化方式來(lái)提高效率，但SQLite 采用了一種更簡(jiǎn)單的方法：通過(guò)減小數(shù)據(jù)庫(kù)及其處理軟件的大小，以使處理的數(shù)據(jù)更少。
• SQLite 被廣泛采用也導(dǎo)致它可能是兼容性最高的數(shù)據(jù)庫(kù)。如果你希望將應(yīng)用程序集成到智能手機(jī)上，這一點(diǎn)尤為重要：只要是可以工作于廣泛環(huán)境中的第三方應(yīng)用程序，就可以原生運(yùn)行于 iOS 上。

劣勢(shì)

• SQLite 的體積小意味著它缺少了很多其它大型數(shù)據(jù)庫(kù)的常見(jiàn)功能。例如數(shù)據(jù)加密就是抵御黑客攻擊的標(biāo)準(zhǔn)功能，而 SQLite 卻沒(méi)有內(nèi)置這個(gè)功能。
• SQLite 的廣泛流行和源碼公開(kāi)使它易于使用，但是也讓它更容易遭受攻擊。這是它最大的劣勢(shì)。SQLite 經(jīng)常被發(fā)現(xiàn)高危的漏洞，例如最近的 Magellan。
• 盡管 SQLite 單文件的方式擁有速度上的優(yōu)勢(shì)，但是要使用它實(shí)現(xiàn)多用戶環(huán)境卻比較困難。

哪個(gè)開(kāi)源數(shù)據(jù)庫(kù)才是最好的？

當(dāng)然，對(duì)于開(kāi)源數(shù)據(jù)庫(kù)的選擇還是取決于業(yè)務(wù)的需求，尤其是系統(tǒng)的體量。對(duì)于小型數(shù)據(jù)庫(kù)或者是使用量比較小的數(shù)據(jù)庫(kù)，可以使用比較輕量級(jí)的解決方案，這樣不僅可以加快實(shí)現(xiàn)的速度，而且由于系統(tǒng)的復(fù)雜程度不算太高，花在調(diào)試上的時(shí)間成本也不會(huì)太高。

而對(duì)于大型的系統(tǒng)，尤其是在成長(zhǎng)性企業(yè)中，最好還是花時(shí)間使用更復(fù)雜的數(shù)據(jù)庫(kù)（例如 PostgreSQL）。這是一個(gè)磨刀不誤砍柴工的選擇，能夠讓你不至于在后期再重新選擇另一款數(shù)據(jù)庫(kù)。