我喜歡文檔數據庫的想法，特別是MongoDB。它允許更快的開發，因爲我們不必調整數據庫模式。然而，MongoDB不支持多文檔事務，並且不能保證修改能夠像普通數據庫一樣立即寫入磁盤（我知道你可以使兩次刷新之間的時間相當短，但仍然無法保證）。是否有可靠的（單服務器）MongoDB替代方案？
我們的大部分項目都不是那麼大，他們需要像多服務器環境這樣的東西。所以記住這一點。是否有任何支持多文檔交易和可靠刷新到磁盤的單服務器MongoDB類文檔數據庫？
一個非常簡短的回答您的具體（但短暫的）要求：
是否有支持多文檔交易和可靠的沖洗到磁盤上任何一臺服務器的MongoDB類的文檔數據庫？
所以你可能想知道這三種解決方案有什麼不同？大部分時間是他們的查詢支持（我認爲RethinkDB具有最先進的功能，涵蓋幾乎所有類型的查詢：子查詢，JOIN，聚合等），他們的歷史（閱讀：生產準備 - 在這裏我可能會說CouchDB處於領先地位），他們的分佈模型（你提到的對你來說並不感興趣），他們的許可（RavenDB：商業，CouchDB：Apache許可，Rethinkdb：AGPL）。
下一步應該是讓您簡要了解他們的功能集並找出哪一個接近您的需求並嘗試一下。
最終一貫的技術如couchdb不提供持久的寫入，它在事實上打破了耐久性。除非他們有確保立即寫入磁盤和立即複製的方法 – Sammaye 2013-02-22 10:03:24
@Sammaye CouchDB是一個單一的服務器數據庫。它允許你設置主 - 主複製，但這是一個不同的故事。在確認操作之前，CouchDB寫入磁盤。最終一致性與耐久性本身幾乎沒有關係：基本上同步複製的數據庫可能不耐用。 – 2013-02-22 20:07:42
奇怪我讀了這個頁面：http：//guide.couchdb.org/draft/performance.html，它說：...「緩衝區在將數據提交到磁盤之前將數據存儲在內存中，以確保更高的數據吞吐量。 （硬件或軟件）的電力損失或崩潰，數據就消失了。「...上次我檢查立即複製是單服務器設置之外的真正耐久性的要求，我也不確定你的人它是一個單一的服務器數據庫，我相當肯定couchdb可以設置在一個集羣中：http://guide.couchdb.org/draft/clustering.html – Sammaye 2013-02-22 20:21:33
您不必調整文檔數據存儲中的模式，但這並不意味着您不需要某種模式，因爲您可能想對數據做一些有意義的事情。看起來你想要一個ACID數據庫。如果您有關係數據，並且您需要與該數據進行交易，那麼聽起來非常像您需要關係數據庫。
對於像Mongo這樣的「NoSQL」數據庫，您放棄了許多可寫副本，分片和快速訪問文檔數據等功能的ACID。聽起來你沒有從中受益，所以爲什麼要權衡？通過將關係表中的文檔存儲爲JSON斑點，許多人最近一直在使用PostgreSQL來進行混合方法。有了這個，您可以將數據存儲爲不需要嚴格構造的列。
因此，如果您有多個需要在更新時進行事務處理的文檔，您可以列出關鍵字，並且有一個「文檔」列或其中只是一串JSON的序列化和反序列化。這不是批評Mongo或其他文檔商店作爲數據庫，但它不是一個真正的交易型多文檔數據的好選擇。 MarkLogic我相信也可以處理多個文檔的ACID。
我認爲很多人會因爲模式不足而發現mongodb的吸引力，但我認爲最終他們會試圖通過嘗試將關係模型強加給它。所以數據庫的選擇取決於你的數據是如何。
有這麼多的nosql數據庫，肯定很難選擇一個。你將不得不提出適當的要求，並確切知道你想要什麼。 繼環比幾乎所有流行的NoSQL數據庫 http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
我希望這有助於。
我個人認爲你確實需要檢查你的要求是什麼。
由於您的服務器的操作系統工作原理的動態性，即使您告訴它，即使「立即」立即執行，也很複雜。當然，我知道像SQL這樣的ACID技術人員容易受到未完成業務的部分腐敗和單個服務器宕機時在特定窗口內丟失操作的影響，不幸的是，這是使用單個服務器的問題之一;你別無選擇，只能接受它。
我應該注意到事務不能確保你的服務器在失敗前會收到全部數據（http://en.wikipedia.org/wiki/Database_transaction），我的意思是如果服務器在事務中中途中斷？
您可以基於事務約束執行安全回滾，但很少數據庫將提供繼續播放事務的能力，除非他們已經收到了所有必要的數據（通常不是這種情況），到那個時候無論如何，數據甚至可能是陳舊的。
實際上，由於某些事務的重要性以及在它們中執行的查詢量，我認爲您可能會使用事務處理的操作丟失的窗口超過您在MongoDB上有時從磁盤窗口執行60ms的操作。但是，當然這取決於濫用，但是，就像存儲過程一樣，這種濫用是常見的地方。
在級聯刪除和像銀行賬戶中轉移貨幣這樣的典型場景上發光，但是，級聯刪除通常會更好地完成（如大多數站點所做的那樣），通過cronjob將應用程序標記爲已刪除的行（以避免回滾交易顯示刪除的數據再次返回給用戶）;這樣你可以做很多事情來確保用戶在使用應用程序時不能實時執行的一致性。
所以你應該真的質疑爲什麼你需要一種技術，它會成功做什麼，atm你的問題的簡潔告訴我你完全不知道你的需求。
崩潰的MongoDB實例可能會導致數據庫中的數據損壞（因爲要執行的操作中有一半是執行的，因爲它不支持多文檔事務）。據我所知，這是PostgreSQL不可能的。這是我們需要的。 – Tim 2013-02-19 19:19:54
@Tim如果您希望自己的速度爬到不會超越小型站點的地步，那麼這是不可能的，交易只能真正用於重要的關鍵任務程序。 – Sammaye 2013-02-19 19:42:39
@Tim基本上，如果你使用除交易以外的任何東西，並且有人告訴你你不能腐敗，那麼這個數據庫可能會違反計算規律。即使使用交易，交易也可能被損壞的機會很小 – Sammaye 2013-02-19 19:45:08
如果我是你，我會仔細看看Solr。底層數據層（Lucene）是迄今爲止最成熟的NoSQL數據庫，Solr可以安裝，配置和集成單主機lucene存儲。
在回答您的問題時，它支持用戶劃定的交易。 Lucene的讀取優化特性可能使其不適用於許多應用程序，但其中大多數非常適合Solr/Lucene + [SQL，Cassandra，CouchDB，RDF]，具體取決於要求。我個人傾向於從Solr + SQL或Solr + RDF開始，但我知道一些熱愛整個NodeJS + CouchDB風格的人，並且我確信提供的靈活性的價值。
底線是，有足夠的NoSQL和SQL擴展，關心數據完整性以滿足您的任何需求，而無需泄露您或用戶的數據。
幾年前我使用solr時，它不適合這種用途。它在高承諾量下崩潰，提交緩慢。近期有關NRT的一些工作，但仍有一段路要走。看到這裏列出的警告：http://wiki.apache.org/solr/NearRealtimeSearch – 2013-02-20 01:41:00
@FrankFarmer不幸的是，提問者沒有提供他們使系統的'使用'的細節。我只能假設你的情況是高容量小寫。我在低容量大寫/大容量大讀項目上運行Lucene，完全沒有任何不穩定問題，並且沒有發現比Lucene更好的用途。具有一小組hv-sw數據和大量lv-lw數據的應用程序類別非常重要，Solr +？是一個很好的候選人。 – Recurse 2013-02-20 02:37:14
伯克利DB是我們用過的。它支持ACID。它確實有交易，但對於您的術語「多文檔」適用，我不完全確定。我想象，只要每個數據庫（即單個文檔）共享相同的BDB環境（即存儲事務的地方），那麼可能會得到你想要的。儘管BDB確實有其他的折衷。憑藉完全的持久性和高併發性，提交非常緩慢。
給一個嘗試：http://www.orientdb.org/
「OrientDB具有文檔數據庫的靈活性和圖形數據庫的權力來管理關係，可以在無模式的模式，架構完整或混合使用。支持ACID Transactions，Fast Indexes，Native和SQL查詢等高級功能，它使用JSON導入和導出文檔，OrientDB使用一種新的索引算法MVRB-Tree，該算法派生自紅黑樹和B +有兩種好處的樹：快速插入和超快速查找「。
這可能是值得看ArangoDB。它是一個多模型數據庫，具有靈活的文檔，圖形和鍵值數據模型。根據您的具體要求，ArangoDB數據庫具有完整的ACID交易，可跨越同一集合中的多個文檔以及多個集合（請參閱Transactions in ArangoDB）。也就是說，您可以在事務中一起對您的文檔執行一組操作，並保證原子性和隔離性。如果您另外設置了waitForSync: true （如所述頁面的下面所述），則在事務處理報告完成之前，您會保證與磁盤同步。請注意，如果您的交易跨多個集合，則會自動發生。
我使用CouchDB和ArangoDB一些經驗，我可以分享：
可以與耐久性運行的CouchDB開啓（DELAYED_COMMITS = FALSE），所以它也將同步你的數據到硬盤。 但是，這是一個全局設置，因此會影響所有寫入。 AFAIK不能在每個集合級別上設置它（CouchDB的「集合」術語將是「數據庫」）。
關於多文檔操作：CouchDB具有MVCC，因此即使面對並行編寫器，從同一數據庫讀取多個文檔也能提供一致的結果。將多個文檔寫入同一數據庫也可以針對特殊情況進行交易，例如，當使用批量文檔API時。 但是沒有辦法在CouchDB中執行跨數據庫操作。這只是沒有打算。
在ArangoDB上：在ArangoDB中，您可以在每個集合級別打開立即同步到磁盤：您可以將其打開用於無法容忍任何數據丟失的集合。您可以立即關閉不需要的同步出於性能原因的重要收藏。然後，它會頻繁地將修改同步到磁盤，但不會立即。它提供了多文檔和多集合交易。
我建議你看看Couchbase。
Couchbase可以運行單個服務器&如果需要，您可以稍後添加節點。
Couchbase具有集成的memcached，因此您可以快速緩存常用數據，並具有將更新寫入磁盤的可靠方法。
他們也有一種叫做NQL（「鎳」）的新查詢語言（在開發中，但你可以使用它），如果這對你很重要，它可以爲你提供SQL訪問權限。
使用跨數據中心複製，可以使不同機器或數據中心上的兩個數據庫同步，這對於進行非現場備份很有用。如果您希望針對這些類型的查詢擁有全文搜索引擎，還可以添加彈性搜索。簡而言之，Couchbase是一個非常完整的解決方案，所有開源代碼都具有智能（在我看來）架構，用於解決分佈式數據庫的典型問題（例如：每個文檔由給定節點「擁有」，因此所有更改到那個節點，然後更新被複制，我認爲比Riak更好，在那裏你可以讓更新進入兩個節點，然後必須協調。）
你可以在一個上使用Couchbase節點通過將項目分成不同的桶來運行許多項目的數據庫。
你是什麼意思，「像正常數據庫一樣立即寫入磁盤」？高性能數據庫通常使用日誌（或預寫日誌）在批處理寫入操作時最大化寫入一致性。 MongoDB具有[this]（http://docs.mongodb.org/manual/administration/journaling/），強烈推薦（並且在64位2.0+中默認）。儘管MongoDB沒有立即/強制寫入日誌的選項（有些DB）。對於MongoDB - 它可以在2-300ms內配置。 – WiredPrairie 2013-02-19 16:48:49
這就是我的意思。有了像PostgreSQL這樣的數據庫，如果我向數據庫寫入數據並且事務成功了，那麼如果機器出現故障，我確信數據將在那裏。 MongoDB通過日誌來接近這一點。但正如你注意到它不保證它。 – Tim 2013-02-19 16:56:35
是的，這是ACID中的'D'。 – 2013-02-19 17:03:02