Sounds like a good solution. That layer on top of couchdb is something
that I am working on as a "side" project. Its part of a larger effort I call
"indexer". I will post something on it once I have more concrete things to
Multi data center is always an interesting problem for distributed
systems, and its not easy to solve it, and any solution comes with its
drawbacks. Even so called nosql solutions that can span multiple data
centers easily sacrifice things to achieve that (and no, I am not talking
about consistency here, which is eventual in those solutions, but on the
fact that you can actually loose data).
I do plan to attack this problem in elasticsearch. For now, the best
solution is doing something similar to what you suggest (couchdb) or using a
messaging later between the two clusters.
On Mon, Sep 13, 2010 at 9:21 PM, Tal email@example.com wrote:
I've recently started looking into deploying ElasticSearch in two data
My initial though is to build an ES cluster on each of the data
centers and in addition to have couchdb instances on each of the data
When indexing, I will push the JSON into couch and ES and will let
couch do its sync magic between the data centers and then index the
JSON again on the other end.
I can suffer some delays in sync between the data centers.
The one thing I don't really like about this solution is that I need
to build a layer ontop of ES and couch and that I need to duplicate