Elasticsearch Reviews

Elasticsearch really excels in search performance, so if you have massive amounts of data you need to search from, Elasticsearch is surely a great fit. I woud advise against using it as the main database or the only source of truth, because data corruption can happen in rare cases, and in that case a reindexing will have to take place.

Not great for highly structured data where SQL thrives, e.g., heavy use of JOINs.
Not great for image data.

Easiest recommendation of my career. The capability and speed are out of this world, and pricing compared to enterprise logging solutions is a fraction of the cost. That'd come with a caveat, that you must be ready to devote some time to it to learn it and get it working. It's not turnkey, but it's one of the best all-around.

Elasticsearch is very well suited within an IT architecture where a lot of open-source software is already being used and where the developers strongly appreciate open-source software. Elasticsearch might be less appropriate in an organisation where there is less space to master the tool. The tool is quite difficult to learn once you start working on the CLI-level search queries.

It is well suited for searching through logs generated by an application running in production, staging, testing or development.

Elasticsearch is a great tool, but remember as every other tool, needs knowledge and expertise to work with. My first option would be using the cloud version provided by Elastic company, but unfortunately it is over my budget, then I need to manage by myself. Also according to your company's area, it wouldn't be possible to keep your data into third's cloud environment. In this case, there is no option other than keeping it by yourself.

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's best use case is when you want to store loosely-structured data and be able to search for it near-instantly. And you want to do that in a highly tolerant distributed system. My company doesn't use it this way but I've heard of other companies using ES to store system logs. Another company uses it to store giant store-catalogs.

Elasticsearch is great for full-text search and some aggregation use-cases. It is ideal for small to medium-sized data sets.

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 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.

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.

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 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.