- Why should I NOT use ElasticSearch as my primary datastore?
- Log Aggregation with Fluentd, ElasticSearch, and Kibana
- Chewy
- ElasticSearch is very well documented (example: failure scenarios are well known and understood
- ElasticSearch scales very well with additional hardware. ElasicSearch performance increases with each ES shard in a cluster of nodes (performance = shards per node * number of nodes in a cluster)
- ElasticSearch is very easy to query with non-specialized clients (HTTP REST, ruby, javascript, etc)
- Kibana - a very nice dashboard interface to ES that can be used to visualize ad-hock queries that may be saved for later viewing
- ElasticSearch optimizes for availability and partition tolerance (AP). It is not ideal for use-cases where data loss must NEVER happen
- ElasicSearch needs at least two or three shards on a single node to be performant; otherwise a single Lucene or Sphinx instance will outperform it
- It is not safe to directly expose ES to the internet without some sort of proxy/authentication layer
- ElasticSearch does not perform well (whithout a lot of hardware) in cases where a rapidly changing dataset is being queried frequently