7

我目前正在编写一个应用程序，在非常不同的层有很多不同的数据持久性需求，我一直想知道......什么时候合适，什么时候不适合使用 couchDB 来满足我的持久性需求？

4

4 回答 4

3

在非关系数据库之上实现了两个生产系统之后，我得出结论，非关系数据库需要更接近 sql 才能真正“替代”它。我将替代理解为“您获得相同的功能，而质量、工作量或成本没有巨大差异”。

简短的回答：不经常

长答案。非关系数据库的主要好处是高可用性、无模式和可扩展性。所有这一切都伴随着巨大的代价。如果您的应用程序需要查询灵活性（和/或，排序顺序，..）并且没有大数据或性能要求，那么您最好使用 mysql 或更好的 postgres 等传统数据库。非关系数据库的主要挑战是，如果您需要新的方法来组合数据（如用户按时间顺序喜欢的所有帖子），您将需要新的文档来插入和查看以实现查询。Couchdb 是基于文档的，有利于灵活性，因为您不需要在数据库中维护模式，并且可以“忘记”缺少新字段的旧数据。

非关系数据库需要推送架构。当您插入或更新数据时，需要推送所有可能查询的所有数据（甚至是罕见的管理员查询）。这需要 cpu 和磁盘的成本，但您可以获得快速查询。在基于 SQL 的数据库中，您可以只插入行并作为慢查询付出代价。CouchDB 在第一次查询时构建索引，在插入时构建其他一些数据库（MongoDB、Google App Engine）

Couchdb 查询被定义为功能强大但很难编写、维护和调试的 javascript 视图。视图更改意味着如果您有数百万或更多文档，couchdb 需要重新索引所有非常慢的文档。普通管理员无法解读来自 couchdb 的错误消息。

Couchdb 维护需要一些手动操作来压缩数据文件和索引，新版本虽然具有自动压缩，但使用它需要小心。压缩需要安排在非高峰期等。不过，这可以很容易地编写脚本。数据库转储、备份和此类工具还很幼稚。

简而言之，如果您不需要 couchdb 的性能或可扩展性，那么不值得付出努力。就我个人而言，我认为使用 sql db、redis 和 memcache 堆栈可以“模拟”大多数非关系数据库的性能优势。至少只要没有太多数据。

于 2012-02-08T07:10:33.697 回答
2

你有关系要求吗？CouchDb（如您所知）没有普通数据库的关系结构。

CouchDb 的 RESTful 特性对您的工作是否重要？

也许最重要的是，谁将支持这一进程，他们是否有能力处理 CouchDb？这是一个相当小众的工具，要找到有经验的人并不容易。

于 2009-04-03T18:36:08.427 回答
1

我会说，这真的是一个个案。CouchDB 只是一种数据库，根据您的项目，它可能是完美的选择，也可能是令人痛苦的限制——就像 RDBMS 可能是完美的选择或噩梦一样。

更多细节？

于 2009-04-06T23:02:03.753 回答