随着时间的推移，CouchDB _changes API变得越来越慢

Question

CouchDB-1.6.1，数据库大约有3300万个文件。

我以三种方式从CouchDB数据库中提取数据：

• 使用ElasticSearch River插件（数据进入ElasticSearch-1.x）
• 使用Logstash couchdb_changes输入插件（数据进入ElasticSearch-1.x或2.x）
• 使用CouchDB-to-CouchDB复制（数据进入CouchDB - 仅用于比较和速度测试）

所有3个都使用Couch中的_changes API作为数据源。这三个都开始非常快 - 每秒至少有数千个文档被复制。但随后他们都放慢了速度。

大约2000万份文件被复制后，River减速到大约20个文件/秒。 Logstash大致相同。

Couch-2-couch复制也会变慢，但在这种情况下，我可以通过增加并行性（连接数和批量大小）来加快速度，因此最终它的表现足够快：

"http_connections": 200, "worker_processes": 40, "worker_batch_size": 1000

但是对于River和Logstash，没有办法做到这一点。使用River我至少可以增加批量大小，但它仍然只使用1个连接到Couch。

"max_concurrent_bulk" : 1000, "bulk_size" : "10000", "bulk_timeout" : "1000ms"

问题是，对于一个大型数据库，在ElasticSearch中吸收它的总时间大约是几天，或者一周，并且由于速度一直在下降，所以关注它最终将无法跟上。速度几乎与1 / x成正比，其中x是到目前为止导入的文档数。

瓶颈不在ElasticSearch端（目的地）; ES有足够的内存，CPU使用率最终降至接近零。瓶颈在于Couch（来源）;那里有一个进程或线程，在整个进程期间CPU占用率为100％。但是具有所有源数据的CouchDB实例具有大量CPU内核并且处于空闲状态，因此似乎有一些关于_changes API的单线程。

我有什么办法可以加快将数据从CouchDB导入ElasticSearch的过程吗？