据我了解，查询视图时会更新CouchDB索引。假设读取数多于写入数，那么扩展规模是否不错？我将如何配置CouchDB以按写入或者更好地按计划更新索引？

解决方案

CouchDB确实会在更新时重新生成视图，但只会重新生成自上次对该视图的读取访问以来发生的更改。假设读取量大大超过了写入量，那么这应该不是问题。

当我们一次更改大量文档时，这可能会导致首次读取请求花费大量时间。为了减轻这种情况，已经提出了几种不同的可能性。大多数依赖于向CouchDB的更新通知进行注册并自动触发读取。

CouchDB Wiki上的[1]提供了一个用于执行此操作的示例脚本。

[1] http://wiki.apache.org/couchdb/RegeneratingViewsOnUpdate

我们不能，为什么呢？

像这样思考：

• 当我们将数据导入MySQL时，由于每次插入更新索引要比一次更新100次写入索引(或者导入的行数多)要昂贵，因此可以进行索引化。
• 这就是为什么CouchDB在读取时更新索引的原因，因为同时集成这100个更改然后写入每个更改的成本较低。

这是CouchDB的优点之一！ :)我并不是说这只是CouchDB的功能，但是在读取时执行此操作很聪明。

我们可以做的一件事是使用update = false进行读取，这是一个肮脏的读取，可能不会返回我们期望的结果。如果我们始终这样做，则可以安排对cronjob的"常规"读取，并以此来更新索引。我只是认为这没有道理。

a)"缩放"是一个重载的术语。我们指的是什么"种类"的缩放？ (无论哪种方式，我都看不出它如何对我们产生负面影响)。

b)写入更新：写入后仅查询视图。请注意，将大量数据添加到索引对资源更友好(不是特定于CouchDB)。因此，我们可能希望每N次写入触发一次视图。

c)预定：设置一个cronjob，每隔M分钟查询一次视图。

d)等待CouchDB发展为我们提供基础架构，使我们可以使用配置参数进行设置。

e)(最佳选项)。让手变脏，并帮助我们完善CouchDB！任何贡献都受到高度赞赏。

d)RTFM(闪烁：)