這篇文章是用英文寫(xiě)的，由于某種原因，這篇文章可以很直接的說(shuō)是Anti-MongoDB一個(gè)和諧的DB（一）。寫(xiě)一的時(shí)候其實(shí)有很多問(wèn)題，還是不很清楚的。所以有了以下的問(wèn)題：
I has some questions about the nosql and the document database solutions because I just touch the nosql solutions these days,
I tried to understand and find the benefit of the NOSQL solutions (performance and scalability), but I cannot convince myself for the reasons, specially for the complex business related cases,
After read a lot of the articles and find the CAP, relational and Scalability are the three points for the NOSQL solutions,
CAP : only can pickup two of the three factors, and the NOSQL solutions pickup the AP, and use the eventually consistency to handle the consistency, now, let's check the RDBMS, if we have a lot of database servers, we also cannot have a good Consistency because of the performance issues, so we can choose the Master/Slave and asynchronize copy to handle the consistency (Similar with Eventually Consistency) which is similar with the NOSQL, so what is the benefit of the NOSQL (specify document database) from the CAP theory?
No-Relational object : the NOSQL is good at the no-relationship objects, for example, log. but log also can save to the RDBMS without relationship, so for the no-relationship objects, I think the mongo solution and the RDBMS solutions should be have the same performance and scalability. right?
Relational : in the mongodb.org there is a good example as following,
the address is embedded into the student which is reasonable and will make the performance better if we need load the address from the student in the UI, but the RDBMS also can do it for the 1-1 relationship, and the scores need ref to the another collection and which is also similar with the RDBMS and also need touch database two times when we load the course which also similar with RDBMS. so what is the benefit.
Partition and Sharding : RDBMS also provide the solutions (although need change some codes), and RDBMS also can handle them.
NOSQL數(shù)據(jù)庫(kù)經(jīng)過(guò)了風(fēng)風(fēng)火火的一年，各個(gè)解決方案做的一個(gè)比一個(gè)有個(gè)性，并且大部分都有了商業(yè)應(yīng)用，總體來(lái)說(shuō)自己創(chuàng)造出來(lái)并且可以進(jìn)行自行優(yōu)化的東東還是經(jīng)得起歷練的。
MongoDB在過(guò)去的一年中，變化非常之大，剛開(kāi)始關(guān)注它的時(shí)候，它只是一個(gè)沒(méi)有1.0版本的東東，但是現(xiàn)在已經(jīng)加上太多太多的功能了，其中包括 MapReduce，Auto Sharding，等。
經(jīng)過(guò)了比較深入的研究（還會(huì)繼續(xù)研究），發(fā)現(xiàn)這個(gè)最像關(guān)系型數(shù)據(jù)庫(kù)的數(shù)據(jù)確實(shí)做的很強(qiáng)大。有很多東西還是非常值得探討的。我們先從以下方面進(jìn)行研究關(guān)系型數(shù)據(jù)庫(kù)和非關(guān)系型數(shù)據(jù)庫(kù)的區(qū)別，以及為什么要在某種條件下擯棄關(guān)系型數(shù)據(jù)庫(kù)。
1. 關(guān)系型數(shù)據(jù)庫(kù)的產(chǎn)生就是為關(guān)系所生，如果一條條的都不是關(guān)系型的數(shù)據(jù)，需要進(jìn)行關(guān)系型數(shù)據(jù)庫(kù)嗎？ 答案很簡(jiǎn)單：不需要
經(jīng)典應(yīng)用：Log的存儲(chǔ) （存儲(chǔ)到關(guān)系型數(shù)據(jù)庫(kù)的話(huà)，耽誤了我們可憐的不好擴(kuò)張的數(shù)據(jù)庫(kù)呀，如果存儲(chǔ)在文件里面，那又不好進(jìn)行管理，所以非關(guān)系型數(shù)據(jù)庫(kù)是一個(gè)很好的解決方案）
2. 關(guān)系型數(shù)據(jù)庫(kù)過(guò)多的強(qiáng)調(diào)了關(guān)系，關(guān)系型數(shù)據(jù)庫(kù)的目標(biāo)是把我們的數(shù)據(jù)庫(kù)打造成一個(gè)第三范式遍布的數(shù)據(jù)結(jié)構(gòu)（無(wú)傳遞函數(shù)依賴(lài)和部分函數(shù)依賴(lài)）。但是這種拆解變相的多了一次數(shù)據(jù)庫(kù)操作，也就是一次IO，性能也就會(huì)下降了。 例子如下：當(dāng)我們想打開(kāi)一個(gè)帖子的時(shí)候，我們肯定還是想把下面的Comments都拿到的，如果我們直接能把Comments存在這個(gè)帖子之下就很容解決了吧。
3. 關(guān)系型數(shù)據(jù)庫(kù)過(guò)的關(guān)注consistency，其實(shí)我們很多的系統(tǒng)中并不需要這么好的consistency，起碼很多的Web2.0或者是普通的網(wǎng)站來(lái)說(shuō)，只要把Support，維護(hù)，alert機(jī)制做好，不需要太多的consistency一樣可以做出很好的系統(tǒng)。當(dāng)然我們也可以通過(guò)一些機(jī)制實(shí)現(xiàn) eventually consistency （沒(méi)有很深入的研究過(guò)）。太多的consistency的關(guān)注必然導(dǎo)致最后的available不會(huì)做到很好。進(jìn)而關(guān)系型數(shù)據(jù)庫(kù)很難scaling out。為了scaling out read，我們只能去做partition，但是partition很難做呀，一半都會(huì)牽扯到很多代碼的改動(dòng)。這些代碼的改動(dòng)會(huì)嚴(yán)重影響項(xiàng)目的穩(wěn)定性而且風(fēng)險(xiǎn)性很大。而為了scaling out write 只能去做master-slave的解決方案（async和sync每種都有自己的問(wèn)題）。很多NOSQL都解決了這個(gè)問(wèn)題，無(wú)論是auto- sharding（因?yàn)槭莐ey做主的東西，可以很好的拆分）還是replication。（這一塊要進(jìn)一步研究）
4. Schema問(wèn)題。關(guān)系型數(shù)據(jù)的schema都是一定的，如果增加或減少一個(gè)column那可是一個(gè)大動(dòng)呀。但是NOSQL卻是能很容易的解決這個(gè)問(wèn)題，因?yàn)樗麄兙褪莐ey-value而已。
NOSQL的提出是一個(gè)思想的進(jìn)步，是一種編程理念的進(jìn)步，數(shù)據(jù)庫(kù)只是一個(gè)存儲(chǔ)的庫(kù)而已，他不應(yīng)該過(guò)多的關(guān)注于其他的business相關(guān)的東西。將來(lái)發(fā)展的前景是我們所有的business的邏輯都應(yīng)該在Domain里面體現(xiàn)，我們不用關(guān)注下面到底存儲(chǔ)到那里。