CouchDB 的缺點

Question

我最近愛上了CouchDB 。 我對它的巨大好處和美麗感到非常興奮。 現在我想確保我沒有錯過任何令人矚目的缺點。

你想到了什么？ 附上我收集的點數清單。 有什么要補充的嗎？

• 遲至 2010 年的博客文章聲稱“不夠成熟”（無論這值多少錢）。
• 比內存 DBMS 慢。
• 就地更新需要服務器端邏輯（更新處理程序） 。
• 交換磁盤與速度：與其他 DBMS 相比，數據庫可能變得巨大（盡管存在壓縮功能）。
• “僅”最終一致性。
• 大型數據集的臨時視圖非常慢。
• 大型數據庫的復制可能會失敗。
• Map/Reduce 范式需要重新思考（僅出於完整性考慮）。

唯一讓我擔心的是#3（就地更新），因為它很不方便。

Answer 1

• 數據為 JSON

這意味着文檔非常大（大數據、網絡帶寬、速度），並且具有描述性的鍵名實際上是有害的，因為它們加起來等於文檔大小。

• 沒有內置的全文搜索

  雖然有辦法： couchdb-lucene ， elasticsearch

再加上一些：

• 它不支持交易

這意味着在所有文檔中強制一個字段的唯一性是不安全的，例如，強制用戶名是唯一的。 CouchDB 無法支持事務的典型概念的另一個后果是，諸如增加/減少值並將其保存回來的事情也是危險的。 沒有多少實例是我們想要簡單地增加/減少一些值，我們不能單獨存儲單個文檔並將它們與視圖聚合。

• 關系數據

如果數據采用第三范式很有意義，而我們嘗試在 CouchDB 中遵循這種形式，我們將遇到很多麻煩。 解決這個問題的一種可能方法是使用視圖排序規則，但我們可能會不斷地與系統作斗爭。 如果數據可以重新格式化為更加非規范化，那么 CouchDB 將正常工作。

• 數據倉庫

問題在於 CouchDB 中大型數據集的臨時視圖非常慢。 使用 CouchDB 和永久視圖可以很好地工作。 然而，在大多數情況下，某種類型的面向列的數據庫對於數據倉庫工作來說是一個更好的工具。

但是 CouchDB 太棒了！

但是不要讓它讓您失望：用 Erlang（CouchDB、Riak）編寫的 NoSQL DB 是最好的，因為 Erlang 是為分布式系統設計的。 有沙發的樂趣！

Answer 2

還有兩件事讓我在使用 CouchDB 時哭了（雖然它很棒）：

• 它不是為頻繁更新的數據而設計的
• 它沒有內置的全文搜索

Answer 3

• 缺少讀者 ACL（但是對於作者來說確實存在）

作為一名老 Lotus Domino 專家，我希望將 CouchDB 作為我正在啟動的新項目的替代方案，但發現 Couch 與 Domino 對讀者的限制非常弱。 在我的應用程序中，安全性是一個重要的考慮因素，Couch 需要一個中間件層來處理閱讀器的安全性。

如果您的數據庫中所有定義的用戶都可以看到所有文檔，那么 Couch 看起來是一個有趣的平台。

如果需要限制讀取，那么您需要尋找中間件解決方案或考慮其他替代方案。

CouchDB 開發人員注意事項：改進平台安全選項。 我意識到它們在使用時會降低性能，但請注意並提供該選項。

現在回到確定要使用的數據庫......

Answer 4

• 目前不支持即席查詢（可能會隨着 UnQL 的出現而改變）
• 缺乏二進制協議支持以加快通信速度

Answer 5

1. 缺乏對數據歸檔的支持——沒有官方對數據的支持
   歸檔是隨 couch db 開源分發提供的。
2. 從 db 中刪除記錄並不簡單
3. 沒有為文檔設置過期 (TTL) 標志的選項

Answer 6

這與 CouchDB 本身無關，但是作為一個相對較新的人，大多數系統管理員仍然不熟悉它，並且不會允許它靠近“他們的”數據中心。 如果您處於部署到無法控制自己的環境的情況，這可能是一場戰斗。