couchdb - Couch DB 扩展和性能

Question

我正在考虑实现一个 CouchDB 服务器，以提供对我们为内部业务运营存储的一些元数据的临时搜索。

我们在内部流程中存储了许多“属性”，例如“职位”的大小、来源、提交日期和 URL。

这在我们的关系数据库中一切都很好，但我们的用户希望通过提供类似于谷歌搜索的“搜索条件”来构建类似职位的列表。因此，用户可以说“显示所有大于 XXX 且在 YYY 之后提交的作业”，然后获取描述和 URL 列表。

这听起来非常适合 Couch，而且根据我的研究，它看起来效果很好。

我的问题是它在适当的硬件下的扩展效果如何？我们有 150-2 亿个此类文档，每个文档有 11-30 个属性。元数据的大小最多为几KB。

我最初考虑使用四核服务器 (VM) 来提供此服务以进行测试，但我需要将其扩展到同时支持 100-250 个用户。

我知道我可以对大多数数据库服务器执行此操作，但我正在寻找提供即席查询方面的东西(通过 REST 或 HTTP 很好，我们有自己的搜索工具)。

有人有设置 Couch 并将其用于此级别生产负载的经验吗？

Answer 1

并发连接不是问题，erlang 和 CouchDB 是为并发性能而构建的。

您是否认为必须动态生成新的 map 函数，因为听起来有点像？

每当您添加新的 View map 功能时，您都会在初始 View 生成中遇到很大的瓶颈。

如果您使用 erlang View ，它们的生成速度比 javascript View 快得多，因为它们不执行 JSON 序列化步骤，这可以显着提高 View 生成性能。

一旦生成 View ，即使您所说的大小，它也会非常快。