3 ms·
I would strongly advise against this. For a long time, the only reason ElasticSearch was not the ugly duckling of distributed systems was because MongoDB exist
by luizfelberti 7y ago
I would strongly advise against this.
For a long time, the only reason ElasticSearch was not the ugly duckling of distributed systems was because MongoDB existed. It does not have a good history at all. There was a time that Elastic even claimed that it beat the CAP theorem, which always makes me chuckle when I'm reminded of it, and historically they also have been quite vague about the distributed properties (and shortcomings) of ES.
It works fine as a secondary datastore when you would benefit from all of the implemented search functions, but I wouldn't trust it for consistency (so I guess in a way it is a replacement for mongo \s)
Not only that but having operated ES clusters before, it's a tricky thing to manage, and depending on your workload they can be very resource hungry.
PostgreSQL is very solid though, and will scale well for the majority of people. I highly recommend this over ES, not to mention it does have some search features too, you should check them out.
- craigching 7y agoDepends on the version of elasticsearch you’re running and the use-case. If you’re running a single index with a well-defined schema, I think elasticsearch works very well. If you need many indices and can’t have a defined scheme, then it can be tough. I work on a team at Target that provides a log aggregation product and we’re finding that a single index with a well-defined schema used to troubleshoot applications via logs is very easy to manage and scale. We support some legacy patterns like “index per application” that are a pain in the ass to manage. Just to provide some context, we manage about 40 clusters that range from a few data nodes to about 160 data nodes with the majority falling in the 16-60 node ballpark. We don’t have a problem with data loss due to elasticsearch, generally speaking.