Couch DB 扩展和性能

Question

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

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

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

这听起来很适合 Couch，根据我的研究，它看起来会很好用。

我的问题是，它在适当的硬件上的扩展性如何？我们有 150-2 亿个这样的文档，每个文档有 11-30 个属性。元数据最多只有几 KB。

我最初希望有一个四核服务器 (VM) 用于测试，但我需要它扩展以同时支持 100-250 个用户。

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

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

Answer 1

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

您是否认为您必须动态生成新的地图功能，因为听起来有点像？

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

如果您使用 erlang 视图，它们的生成速度比 javascript 视图快得多，因为它们没有达到 JSON 序列化步骤，这可以显着提高视图生成性能。

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