Elasticsearch Reviews

Initially, we were using Elasticsearch for just product searches. It is also becoming useful as our product repository to display all data needed for the product detail pages.

Elasticsearch is so versatile and so easy to set up that it's really a no-brainer including it in most projects as the indexing and search engine components, as well as for analytics and aggregations. It's not so well-suited to be used as the main database, as there's a minor risk of data loss.

Elasticsearch can be used perfectly inside a site for searching features in order to respond quickly to user queries. It can be used to act as a Centralized Log Server, where you can define events based on pattern detection for anomaly detection.
Elasticsearch has potent visualization features with Canvas and OOB Dashboards that can respond to business and technical requirements.

Elasticsearch is well suited for environments where multiple logs are being generated and investigation needs to be done in relation to multiple log files with each other.
Elasticsearch can help to provide a better visualization of the logs and an easy (sql like) search capability.
It also provides analytics capabilities powered with machine learning tools to help make decisions based on the log data.

It works well for what we need. Short sharp logs of data from ongoing consistent processes.

ElasticSearch is great when you need a lot of data indexed really fast, as well as when you need to retrieve a large number of documents based on a complex query. Searching is super-fast.

If you need a large data store for documents where not everything needs to be indexed, don't use JUST ElasticSearch. We use one KV database system to store all of our data and use ElasticSearch as our Index. All searches are run off of ElasticSearch, and the main data store that it pulls from is the other database.

Elasticsearch is great for development/research projects: It's fast, and *fairly* simple to set up. Project ideas of the calibre of: Watching a marketing feed from Twitter, or scraping sites. But for High availability in (say) a SCADA environment, probably not helpful. Though, I would recommend it for logging system nodes: such as a data center, trouble ticketing dashboard, or health/status visualizations.

Elasticsearch is the gold standard for text-based search. Across large data sets it performs admirably, and we will certainly make it our first choice search solution in the future. For a use case where needs are simple and regular database queries might suffice, Elasticsearch may or may not provide any benefits.

Elasticsearch is a great fit for a data lake environment that is being created to get rid of the typical siloed environment in so many data centers today. Being able to easily search, analyze, and correlate device information in easy to read JSON files is crazy valuable to our internal team.

Elasticsearch is extremely well suited for structured (faceted) search, full-text search, and analytics workloads. Elasticsearch and the ELK stack are also a good fit for operations teams that want to be able to interrogate their logs in an online (read: fast) query tool. Elastic is amazing at creating super fast search experiences over very large datasets, where traditional RDBMS systems are either too costly or too slow.

Elasticsearch has a very fast an efficient searching process. If you've searched a heavy project, you can't just be dependent on databases. Plus, they have a REST API for everything, making it easy to use with any programming language or database.

It is well suited for anything involving large data - searching, filtering, aggregations, analytics, reporting, etc.

If you are in a scenario where you are constantly trying to optimize queries to get better performance from your database searches, Elasticsearch is probably a product worth trying out. With the amount of data we have, doing text searches via SQL isn't even an option. If you aren't struggling with getting reasonably fast queries getting Elasticsearch up probably isn't going to be worth the hassle.

The best situation where we have found elasticsearch to help was when you have searches and your database just isn't doing them with the speed that you want, and even where the DB is going the speed needed Elasticsearch can take some of the processing from the database(which isn't necessarily built specifically for searching) to a system that was designed for searches.

If you are doing searching, then I would suggest going with Elasticsearch.

Elasticsearch is a great solution if you want lightening quick querying of data, especially text-based querying. If you are doing a lot of writing/updating to your database, this is not the best use case and you may want to evaluate other NoSQL solutions.

If you are building an application that requires fast retrieval, Elasticsearch would provide an excellent backend database. The distributed architecture provides high-availability and data replication natively without a large performance sacrifice. Elasticsearch also runs on minimal hardware requirements when compared to other DB solutions.

ElasticSearch is very well suited to index and search data but it not made to store data like a database.

ElasticSearch is hands down, the absolute best solution for logging in a virtualization environment. The Kibana front end to ElasticSearch is extremely intuitive, even computer novices can be trained on how to chain together tags in the Apache Lucene syntax to extract the data they need. Once the deploy process is nailed down and system is engineered, the logging structure can remain fairly static until the next major revision. Compared to Splunk, with an administrator well versed in the ElasticSearch suite, will save an organization upwards of 10's of thousands of dollars a year even with the caveats mentioned earlier.

As a developer looking for a quick and simple search engine which has little configuration required, ElasticSearch is fast and perfect for that solution. Literally throw JSON records in to the database and push a request to get JSON out, exceptionally straightforward.

Elk is great for app logs and search. It comes with Kibana which is great query tool. Logstash is great. It can autodetect datatype but can be tuned if needed which is awesome. It has lots of integrations such as filesystem, syslog, kafka etc., which make setting it up a breeze. It is also sometimes used for metrics. But [I] would rather use timseries db such as influx db, prometheus for metrics. Using logs for metrics tend to be expensive and inefficient.

I have noticed Elasticsearch is good in following scenarios:
Faster Aggregation
Full-text search features
Scalable
Great performance
Stability
Complete Ecosystems of applications

It could have been slightly better in handling indexing. (Should index all the items and create index overhead)
Better load balancing
Elasticsearch aggregations are not always precise, because of how data in the shards is placed

Elasticsearch is a great choice for search scenarios, for architectures that heavily rely on search capabilities. It's also great for analytics using Kibana. It's also great for log aggregations and again search. It can be even used as the main database layer for critical search infrastructures. But you need to [take] care with data that may change the structure and type of fields.

[Elasticsearch is well suited for] Data Analysis, Reporting, Searching across large datasets, Speed

I would say ElasticSearch is the best option on the market for web-driven document search.