3

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

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

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

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

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

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

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

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

4

1 回答 1

4

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

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

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

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

生成视图后,即使您正在谈论的大小,它也会非常快。

于 2009-12-23T19:20:49.340 回答