Elasticsearch Reviews

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.

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.

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.

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

As the name implies, when you need to search thousands, millions, or billions text-based documents for keywords, Elasticsearch is great. The way it indexes and internally analyzes the content of your documents is very powerful. Assuming you have enough servers in your cluster with fast enough storage, querying those documents becomes a breeze.

It does the thing that it was designed for (quickly searching through bulk load of data) very very well. Also, it's scalable and flexible. Don't try it for other cases. It's not a NoSQL data store where you will want to store and retrieve data. Also, don't try any complex computations. That will make the retrieval slow and the benefits will be lost.

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

Elasticsearch does one thing very well. Search and index data. Trying to go outside that realm is doable but not recommended. For example, I would not use elasticsearch as a document store. But rather treat it as a rebuildable index that can be rebuilt from a persistent database like Postgres, or MySQL.

The only scenario where I see Elasticsearch is less appropriate is when there are transactions involved. If data is corrupted there is no rollback.

Web app analytics is a great example of use for it because logging messages isn’t necessarily structured. Elasticsearch does a great job of indexing structured or unstructured data. Think of Elasticsearch and Kibana being an open source "Splunk" replacement. It may not be appropriate to use Elasticsearch for true real-time data. It is not a time series database although it may be used as one. Perhaps a better solution for time series data would be InfluxDB or Graphite, whereas Elasticsearch is more of a search engine.

Elasticsearch is good for any production stack for data analysis, and error monitoring and alerting. The only thing you need is an engineer who's willing to dig through log lines, write queries, and build graphs which accurately track the health of your production systems. I equate this tool to something like New Relic, where if used the right way can provide a lot of insight. If used incorrectly, it doesn't do a whole lot out of the box. It needs to be set up by someone who knows the system and cares to monitor it.

Great for storing big data, very scalable. Many great features.