過去兩天我一直在閱讀和學習NoSQL和MongoDB，CouchDB等，但我仍然無法判斷這是否適合我。使用NoSQL是否對非分佈式系統有意義？ （試圖理解最終的一致性）
我擔心的是最終的一致性。這種類型的一致性只在使用集羣時才起作用嗎？ （我在一個專用服務器上託管我的站點，所以我不知道我是否可以從NoSQL中受益）哪種類型的應用程序可以具有最終的一致性（而不是ACID），哪些應用程序不是「 T'你能舉幾個例子嗎？在可以最終保持一致性的應用程序中可能發生的最糟糕的事情是什麼？
我讀到的另一件事是MongoDB在內存中保存了很多東西。在文檔中，它提到了一些有關2位數據限制的32位系統。那是因爲32位系統的RAM限制嗎？
NoSQL數據庫解決了難以用傳統RDMS解決的set of problems。如果你的任何問題都在那個集合中，NoSQL可以是the right storage for you。
最終一致性「在踢」當你可能從剛堅持一個讀取數據的回不同的/以前的版本。例如：
您將相同的數據保留到多於一個的位置，讓我們假設A和B.根據配置，持久操作可能會在僅持續到A之後返回（而不僅僅持續到B ）。在此之後，您從B讀取那些尚未存在的數據。 最終它會在那裏，但不幸的是不是當你讀回
NOT OK =>您有這有一個可用的$ 100家的銀行賬戶。現在你和你的配偶試圖以100美元同時購買（在不同的商店）。如果銀行採用「最終一致性」模式實施，例如超過一個節點，那麼在您花費所有費用後，您的配偶可能花費100美元幾毫秒。對銀行來說，這不會是一個好日子。
OK =>你在Twitter上有10000個關注者。你推送了「嘿，今晚誰想要做黑客攻擊？」。 100％一致性意味着所有這些10000個人將同時收到您的邀請。但是，如果約翰在瑪麗之後2秒鐘看到你的推文，真的不會有什麼不好的事情發生。
例如，當節點A獲取數據時，節點B獲取相同的數據[它們同步]。如果NoSQL解決方案具有可靠性，那將是最糟糕的事情。
：
「MongoDB是在Linux，Windows和OS X上運行的服務器進程可以同時運行一個32位或64位應用程序，我們建議在運行。 64位模式，因爲對於32位模式的所有數據庫，Mongo限制爲大約2GB的總數據大小。「
Brewers CAP theorem是瞭解什麼是可用的選項的最佳來源。我可以說這一切都取決於，但如果我們談論Mongo，那麼它提供了開箱即用的橫向擴展性，並且在某些情況下它總是很好。
現在關於一致性。實際上，您有三種選擇讓數據保持最新狀態：
1）首先要考慮的是安全性指示的「安全」模式或「getLastError（）」。如果您發出「安全」寫入，則知道數據庫已收到插入並應用寫入。但是，MongoDB只會每60秒刷新一次磁盤，所以服務器可能會在沒有磁盤上的數據的情況下發生故障。
2）要考慮的第二件事是「日記」（v1.8 +）。打開日記功能後，數據每隔100ms刷新一次。所以你在失敗之前有一個較小的時間窗口。驅動程序有一個比「安全」更進一步的「fsync」選項（檢查該名稱），它等待確認數據已刷新到磁盤（即日誌文件）。但是，這僅涵蓋一臺服務器。如果服務器上的硬盤驅動器死了會發生什麼？那麼你需要第二個副本。
3）要考慮的第三件事是複製。驅動程序在返回之前支持一個「W」參數，該參數表示「將此數據複製到N個節點」。如果在某個超時之前寫入未達到「N」個節點，則寫入失敗（拋出異常）。但是，您必須根據副本集中的節點數量正確配置「W」。同樣，由於硬盤驅動器可能會失敗，即使使用日記功能，也需要考慮複製。然後跨越數據中心進行復制，這些時間太長而無法進入。最後要考慮的是你的要求「回滾」。據我瞭解，MongoDB沒有這種「回滾」能力。如果您正在進行批量插入，您將得到的最好結果是指示哪些元素失敗。
無論如何，當數據一致性成爲開發人員的責任時，存在很多情況，並且由您決定要小心幷包含所有場景並調整數據庫模式，因爲沒有「這是正確的方式」在Mongo中就像我們習慣RDB-s一樣。
關於內存 - 這完全是一個性能問題，MongoDB將索引和「工作集」保存在RAM中。通過限制你的RAM限制你的工作集。你實際上可以擁有一個固態硬盤和更少量的內存，而不是大量的內存和硬盤 - 至少這些是官方建議。無論如何，這個問題是個人的，你應該爲你的具體使用情況做性能測試
我只能說CouchDB，但不需要在最終一致性和ACID之間進行選擇，它們不在同一個類別中。
CouchDB完全是ACID。文檔更新是原子性，一致性，隔離性和持久性（使用CouchDB推薦的delayed_commits = false的生產設置，在返回201成功代碼之前將更新刷新到磁盤）。什麼CouchDB不提供而不是提供的是多項目交易（因爲當項目存儲在不同的服務器中時這些交易非常難以擴展）。 「交易」和「ACID」之間的混淆是令人遺憾的，但由於典型的RDBMS通常支持兩者，所以這是令人遺憾的。
最終一致性是關於數據庫副本如何在同一數據集上進行匯聚。考慮傳統RDBMS中的主從設置。這種關係的一些配置將使用分佈式事務機制，從而使主機和從機始終處於鎖定階段。但是，出於性能原因，放鬆這種情況很常見。主人可以在本地進行交易，然後通過交易日誌將他們懶惰地轉發給奴隸。這也是「最終的一致性」，當期刊完全耗盡時，兩臺服務器將收斂在相同的數據集上。 CouchDB更進一步，消除了主從與主從之間的區別。也就是說，可以將CouchDB服務器視爲相同的對等方，並將任何主機所做的更改正確地複製到其他主機。
最終一致性的訣竅在於如何處理不同主機上同一項目的更新。在CouchDB中，這些單獨的更新在同一項上被檢測爲「衝突」，並且複製可確保所有主機上都存在所有衝突的更新。 CouchDB然後選擇其中之一作爲當前修訂。可以通過刪除不想保留的衝突來修改此選項。