軟體公司為何要放棄MongoDB？_ZenDei技術網路在線

本文轉至：http://database.51cto.com/art/201503/469510_all.htm(只作轉載, 不代表本站和博主同意文中觀點或證實文中信息)Olery成立於2010年，總部位於阿姆斯特丹。該初創公司為酒店行業提供聲譽管理與媒體監控工具，幫助酒店將網路評論和社交媒體反饋轉...

本文轉至：http://database.51cto.com/art/201503/469510_all.htm
(只作轉載, 不代表本站和博主同意文中觀點或證實文中信息)

Olery成立於2010年，總部位於阿姆斯特丹。該初創公司為酒店行業提供聲譽管理與媒體監控工具，幫助酒店將網路評論和社交媒體反饋轉化成可執行的商業智能分析。

Olery成立最初是使用MySQL來存儲(用戶、合同等等)核心數據，用MongoDB來存儲評論及其類似的數據(即哪些在數據丟失的情況下很容易恢復的數據)。一開始，這樣的安裝運行的非常好，然而，隨著公司的成長，開始遇到了各種各樣的問題，尤其是MongoDB的問題居多。其中一些問題是由於應用與資料庫的交互方式而引起的，一些則是由資料庫本身而產生的。

例如，某個時刻，Olery需要從MongoDB中刪除一百萬個文檔，以後再把這些數據重新插入到MongoDB里。這樣的處理方法使得整個資料庫幾乎要被鎖定數個小時，自然服務性能就會降低。而且直到對資料庫執行修複(即在 MongoDB上執行repairDatabase命令)後才會解鎖。而且完成修複還要花費數個小時，修複所花的小時數要根據資料庫的大小來確定。

在另一實例中Olery註意到應用程式的性能降低和設法跟蹤到的 MongoDB 集群。然而，經過進一步檢查，無法找到問題的真正原因。無論怎麼安裝，或使用什麼工具敲了什麼命令都找不到原因。直到Olery更換了集群的初選，性能才恢復正常。

這隻是兩個例子，Olery已經有過許多這樣的情況。這個問題的核心是，這不只資料庫在運行，而且無論何時察看它都沒有絕對的跡象表明是什麼原因導致的問題。

無模式的問題

另外，Olery面對的核心問題是mongoDB的重要特征之一：模式的缺乏。模式的缺乏可能聽起來是有趣的，並且在一些情況下是有好處的。然而，對於許多無模式存儲引擎的用法，其導致了一些模式之間的內部問題。這些模式沒有通過存儲引擎定義而是通過應用的行為及其可能的需要而定義的。

例如：你可能有一頁存儲你的應用需要的字元串類型的title欄位的集合。這兒這個模式是非常符合當前情形的，即使它沒有被明確的定義。但如果這個數據結果改變超時，尤其是如果原來的數據沒有被遷移到新的數據結構，這就成了問題(在一些無模式的存儲引擎上是相當有問題的)。例如，你可能有下麵這樣的 Ruby代碼：

post_slug = post.title.downcase.gsub(/\W+/, '-')

這樣，針對每一個有“title”欄位並返回一個String的文檔，它都能正常工作。然而，對於那些使用不同欄位名字(例如：post_title)或者根本沒有標題欄位的文檔來說，它將不能正常工作。為了處理這種情況，你需要將代碼調整為下麵內容：

if post.title
post_slug = post.title.downcase.gsub(/\W+/, '-')
else
# ...
end

另一種處理方法是，在你的模型中定義一個模式。例如 Mongoid，一個流行的針對Ruby的MongoDB ODM，就能讓你做到這一點。然而，當使用這些工具定義一個模式時，你可能會好奇為什麼它們不在資料庫內定義該模式。實際上，這樣做可以解決另一個問題：可重用性。如果你只有一個應用程式，那麼在代碼中定義模式並不是什麼大問題。然而，如果你有許多應用程式的話，這將很快會成為一個大麻煩。

無模式存儲引擎希望通過刪除對模式的限制的方式，讓你的工作變得更簡單。但現實的情況是，確保數據一致性的責任推到了用戶自己的身上。有時候無模式引擎可以工作，但我打賭，更多的時候是事與願違。

好資料庫的需求

有了更多的特殊需求後，迫使Olery尋求一款更好的資料庫來解決問題。對於系統，特別是資料庫，Olery非常註重以下幾點:

一致性
數據和系統行為的可視化
正確性和明確性
可拓展

一致性是重要的在於它有助於幫助Olery對系統設定明確的期望。如果數據總是按照同樣的方式存儲，那麼系統可以很方便的使用這些數據。如果在資料庫層面要求表的莫一列必須存在，那麼在應用層面就不用檢查這列數據是否存在。資料庫即使實在高壓情況下，也必須保證每一次操作的完整性。沒有什麼事情比單純的插入數據，過了幾分鐘後卻找不到數據的事更讓人沮喪了。

可見性包含了兩點：系統本身以及從中獲取數據的容易程度。如果一個系統出錯那麼應該易於調試。反過來，用戶應很容易查到想要查詢的數據。

正確性是指系統的行為如Olery所期望的那樣。如果某個欄位定義為一個數值型，沒有人可以像其中插入文本。這方面MySQL是臭名昭著，一旦你這樣做你將得到偽結果。

可擴展性不僅針對性能而言，而且也涉及財務方面和系統能夠多麼好地應對不斷變化的需求。一個系統在沒有大量資金成本或減緩系統所依賴的開發周期情況下，很難表現得非常好。

放棄MongoDB

上面的需求牢記於心後，Olery就開始尋找一個取代MongoDB的資料庫。上面提到的特性通常是傳統RDBM特征的一組核心集，所以Olery鎖定了兩個候選者：MySQL和PostgreSQL。

本來，MySQL是第一候選，因為Olery的一些關鍵數據已經在使用它存儲。然而，MySQL也有一些問題。例如，當將一個欄位定義為int(11)時，你卻可以輕鬆地向該欄位插入文本數據，因為MySQL會試圖對它進行轉換。下麵是一些例子：

mysql> create table example ( `number` int(11) not null );
Query OK, 0 rows affected (0.08 sec)
mysql> insert into example (number) values (10);
Query OK, 1 row affected (0.08 sec)
mysql> insert into example (number) values ('wat');
Query OK, 1 row affected, 1 warning (0.10 sec)
mysql> insert into example (number) values ('what is this 10 nonsense');
Query OK, 1 row affected, 1 warning (0.14 sec)
mysql> insert into example (number) values ('10 a');
Query OK, 1 row affected, 1 warning (0.09 sec)
mysql> select * from example;
+--------+
| number |
+--------+
| 10 |
| 0 |
| 0 |
| 10 |
+--------+
4 rows in set (0.00 sec)

值得註意的是，MySQL在這些情況下會發出警告。但是，僅僅是警告而已，它們通常(若非總是)會被忽略。

此外，MySQL的另一個問題是，任何表的修改操作(例如：添加一列)都會導致表被鎖，此時將無法進行讀或寫操作。這就意味著，使用這種表的任何操作都不得不等待修改完成之後才能進行。對於包含有大量數據的表，這可能會花費幾個小時才能完成，很可能會導致應用程式宕機。這已經導致一些公司(例如 SoundCloud)不得不自己開發工具(例如lhm)來解決該問題。

瞭解到上面的問題後，Olery開始考察PostgreSQL。PostgreSQL可以解決很多MySQL不能解決的問題。例如，PostgreSQL中你不能將文本數據插入一個數字欄位：

olery_development=# create table example ( number int not null );
CREATE TABLE
olery_development=# insert into example (number) values (10);
INSERT 0 1
olery_development=# insert into example (number) values ('wat');
ERROR: invalid input syntax for integer: "wat"
LINE 1: insert into example (number) values ('wat');
^
olery_development=# insert into example (number) values ('what is this 10 nonsense');
ERROR: invalid input syntax for integer: "what is this 10 nonsense"
LINE 1: insert into example (number) values ('what is this 10 nonsen...
^
olery_development=# insert into example (number) values ('10 a');
ERROR: invalid input syntax for integer: "10 a"
LINE