Elastic Search Reviews

We use it for locating and retrieving documents, particularly in scenarios where the data lacks a predefined structure. These documents may encompass various types of information, such as logs or other records.

It is highly valuable because of its simplicity in maintenance, where most tasks are handled for you, and it offers a plethora of built-in features.

Currently, their focus seems to be on expanding integrations and introducing more external tools, somewhat diverging from enhancing the core product. While integrating with tools like agents for ingesting data from sources like firewalls is valuable, I believe prioritizing improvements to the core product would be more beneficial. For instance, the development of a multi-step query engine could significantly enhance user experience. The ability to execute queries, receive results, and then perform subsequent queries based on those results is a fundamental feature that, while achievable through code, seems to be lacking as a built-in capability. While they possess a robust infrastructure, the current upgrade process isn't seamless and can result in downtime. As a customer, this can be frustrating, especially when there are methods like replicating to a new instance, performing the upgrade, and then transitioning back, which could potentially minimize downtime. This is crucial in a cloud service where ensuring availability is paramount, considering the significant investment in such services.

I have been working with it for two years.

It offers good stability capabilities.

It is a scalable tool, but it's not impressive. The challenge arises when scaling out becomes prohibitively expensive. Instead of offering end-users the flexibility to specify the number of instances, there's a tendency to provide preconfigured packages. This approach may not be ideal, particularly for those seeking smaller scale-ups.

Their documentation is commendable as it provides a clear understanding of their offerings. Also, the accessibility to their support further enhances user-friendliness, making it a straightforward and user-friendly experience. While it may be slow, their competence in what they do is evident. I would rate it eight out of ten.

Positive

The initial setup was straightforward.

Setting up the system initially is quite straightforward, but when it comes to upgrades, the process becomes more challenging. It was an in-house deployment. The primary focus is on designing the solution, considering factors like the importance of replication, cluster size, speed, and disk space. I appreciate their approach of guiding you through these considerations, making it easier to grasp the bigger picture. This initial design phase is a complex but crucial step. Once that's sorted, the subsequent steps are relatively straightforward—just a few clicks to establish the baseline. If you're working on a standard deployment, it's a hassle-free process.

The pricing structure depends on the scalability steps. It begins as quite affordable and maintains affordability for a while. However, there's a turning point where it transitions from being reasonably priced to becoming notably expensive.

We've explored a few alternatives, but I believe Elasticsearch, particularly with Elastic and Elastic Cloud, stands out as the current industry standard. Opting for a widely used platform is advantageous due to the larger community it attracts. A substantial user base means more people to consult, numerous information sources, and a wealth of case studies. While there are smaller, medium, and even large alternatives, having around eighty percent of the community share provides a significant pool of expertise and resources to tap into.

The main reason we opted for it is because the installation is straightforward, and maintenance is made easy as they handle that aspect for you. The extensive knowledge base offers substantial assistance, making it less reliant on individual expertise. I believe it's a solid product, especially for beginners. While it's not free, it's well-suited for more complex tasks. Keep in mind that for intricate functionalities, you might need to develop and create tools beyond what Elastic Cloud offers. If you're considering a cloud-based solution for schema-less documents, Elasticsearch is a solid choice. On the other hand, if you have the resources to handle on-premises installation, I would recommend it for companies with the capability to manage the deployment themselves. Overall, I would rate it eight out of ten.

We are using the solution for our products. We are keeping some DBs where we are doing pattern searches. On the application side, we are keeping those in Elastic and a huge amount of data for our different product lines.

The way we access it is great.

The scalability that Elastic is providing is quite useful. 

We can do a lot of archiving. 

It is stable. 

The technical support is quite good. 

The cost is too high once you deploy the solution. 

They're making changes in their architecture too frequently. We'd like less frequent updates. 

I've been using the solution for five or six years. 

The solution is quite stable. There are no bugs or glitches. It doesn't crash. It is reliable. 

It's a scalable solution. We can expand it if needed. We have 50 to 60 users on the solution right now. We do not have plans to increase usage at this time. 

We've dealt with technical support in the past and have had very positive experiences. We are satisfied with the level of support we get. 

Positive

The initial setup has a moderate amount of difficulty. It's not simple and not overly complex. 

Since we are paying more for the license, we have not seen a very high ROI. 

The developer and tester licenses are one thing that is not hurting us. However, the deployment license cost is very, very high for Elastic.

We did look at other options five or six years ago. We chose Elastic for multiple reasons in the end. 

I would recommend the solution to others. 

I'd rate the solution nine out of ten. 

The primary use case for Elasticsearch is to serve as a non-SQL database platform to replace traditional SQL processes. It is used in situations where unstructured data needs to be studied and searched.

Elasticsearch has been helpful due to its ability to handle unstructured data effectively compared to SQL. It provides a fast and interesting search capability which is advantageous for our needs.

The most valuable feature of Elasticsearch is its convenience in handling unstructured data, making it easy to use.

Elasticsearch could be improved in terms of scalability. If the database becomes too large, its efficiency is not as good as SQL. Additionally, the initial setup could be a little easier.

We have been using Elasticsearch for about two to three years.

We have faced shutdown issues, but these are mostly related to problems with our own machines and not due to Elasticsearch itself.

Elasticsearch is not scalable when dealing with very large databases. The efficiency decreases for huge databases because it deals with unstructured data, which presents an inherent problem.

The initial setup is of medium difficulty since it requires some understanding of the disk and related concepts.

Elasticsearch can be expensive. It requires some support and unlocking of features.

I recommend Elasticsearch for anyone looking to build a simple database, as it should be a top choice.

I'd rate the solution seven out of ten.

For me, the primary use case of Elasticsearch is log analysis, as it is a text-based search tool. To explain how it works, let's consider its role at the backend. Elasticsearch operates on keywords used to fetch data. This is in contrast to some databases, where operations might be based on a key order or a primary key, allowing for various maintenance and analysis tasks.

Many people use Elasticsearch to store their application logs in JSON format. These logs are indexed, facilitating efficient search and analysis. Additionally, Elasticsearch integrates well with tools like Grafana and Kibana, enabling users to create diverse dashboards for data visualization.

There's also the text-based search scenario. For instance, if a user wants to search for something using a specific keyword, Elasticsearch excels in this area by creating multiple indices. 

Elasticsearch is a versatile tool that can store and retrieve information effectively, making it suitable for various applications across different industries.

Elasticsearch is a quick search engine tool. A good use case is saving metadata of your systems for data cataloging. Various systems, like those opened in metadata and similar applications, use Elasticsearch to store their text data. However, the major use case for many is to store application logs and build different dashboards on top of it.

The use of Elasticsearch is very specific. It is not helpful for storing your OLTP data. Elasticsearch's specific use is when you need to provide text-based search functionality. That's when Elasticsearch becomes relevant. 

For instance, for log analysis or searching values, Elasticsearch performs very well. However, there are challenges with performance management and scalability, particularly how developers manage these aspects. 

For example, Kubernetes is a popular choice as it offers the needed features to run your application and allows performance optimization in response to increased system load, and managing itself. If you plan to deploy Elasticsearch with limited or predefined resources, it may not be the ideal setup. 

Therefore, it's better to create ultimate commerce capabilities for it. This is the challenge people are facing in the market and the solution for it. So, this answer combines two aspects: the challenge and its solution.

I have been using Elasticsearch for almost a year now. I'm comfortable working with it and understand its functionalities. 

In our organization, it's not so much about the number of people as it is about the number of products utilizing it. Currently, we use Elasticsearch in more than 12 products. 

It's become essential for any component that requires text-based functionality. Besides that, it's also used for logging to analyze application performance, peak times, etc. Elasticsearch is a basic component of the architecture for each of these products.

Most of our deployments are not exposed to the Internet or public networks; they're restricted to closed networks. We don’t frequently upgrade from previous versions unless a specific use case arises. 

In such cases, we usually turn to the developer community for support. 

Another scenario is when running the application in a careful mode, where the main requirement is to change the image name in the configuration. Then, we check for any changes or incompatibilities with previous versions. Upgrades can sometimes introduce issues if they’re not compatible with existing configuration files, but it's generally not too problematic to handle.

Deploying in Kubernetes is not complex. There are many resources in the market, like DevOps guys and guides, which make the process straightforward. The deployment can be done in a matter of minutes. You basically run a configuration file to set up your application, define replicas, and so on. It shouldn't take much time; even with an expert, it's a matter of a few hours. 

However, the key lies in following best practices and configuring your files properly. If you follow the best practices, you'll likely face fewer issues. But if not, problems are inevitable. 

It’s crucial to analyze these practices, considering factors like bandwidth, data volume, user interaction, and how it's read by different applications. These considerations help in managing resources and scalability, including scaling up and down your Elasticsearch container. These points are vital for running Elasticsearch efficiently, especially for text-based search applications.

You can deploy it as required. Elasticsearch is versatile; you can run it on Kubernetes, in the cloud, or on-premises. There is no limitation in terms of deployment options.

The cost varies based on factors like usage volume, network load, data storage size, and service utilization. If your usage isn't too extensive, the cost will be lower. 

However, if you're dealing with high volumes, you'll need to reconsider the cost-effectiveness. If there are no challenges or bottlenecks in buying a service from a cloud service provider, that might be a viable option. 

But if you're concerned about price or issues like exposing your data to the public cloud, then deploying on-premises and conducting stress testing becomes important. It’s a part of the learning and development process, not just a deployment for production. 

You need to pass through testing processes in the development environment and then move to staging and production. This involves various tests to understand user access patterns, data push, and performance assessment. Deploying on your own requires considering all these factors. On the other hand, if you use a cloud service, many of these concerns aren't your responsibility.

If you're interested in using Elasticsearch as a search tool and for cloud data integration, comparing it with alternatives like Amazon Cloud Search or Azure Search is valid. Many cloud service providers that offer text-search services are utilizing Elasticsearch. They've implemented best practices and resolved a myriad of issues experienced by companies using Azure, AWS, or GCP. 

These providers have integrated Elasticsearch into their cloud offerings effectively. Choosing their services might be preferable due to lower operational costs on your side. 

In case of any disaster or issue, their development and DevOps teams are available to support you. However, if you face limitations, like client requirements prohibiting data storage in public or private clouds, then deploying Elasticsearch on-premises would be your alternative.

I would definitely rate it an eight out of ten,  which is very good. The reason is the active community continuously working on it, and the support from contributors and the support team is notable. Because Elasticsearch is very specific in its use cases. 

It excels in text-based search and creating dashboards for application logs. It provides results and functionality that are hard to find in alternative tools. So, if you have a use case that fits, Elasticsearch is a great service without any direct alternatives.

Using real-time search functionality to support operational decisions has been helpful. However, it is not functioning correctly, as the real-time search consumes significant system resources.

The search feature is one of the valuable features of Elasticsearch.

There are areas for improvement in Elasticsearch.

The real-time search functionality is not operational due to its impact on system resources. There are some stability issues.

My overall experience with support was positive.

Neutral

The initial setup is complex.

I do not have specific details about the implementation team. The process might require certain expertise.

The pricing is not cheap and is expensive.

I compared the differences between Elastic and other SIEM solutions.

I am more like an implementer than a customer.

I'd rate the solution seven out of ten.

We use the solution to monitor our website and APIs request and response cycle, also for log aggregation. We also used it for APM and searching for slow and database queries. 

It helped a lot in identifying bottlenecks and events happening simultaneously among several services, since we can aggregate the logs into a single repository of data

I am impressed with the product's Logstash. The tool is fast and customizable. You can build beautiful dashboards Kibana using Logstash as data source. It is useful and reliable. 

It was not possible to use authentication three years back. You needed to buy the product's services for authentication. 

I have been working with the product for three years. 

The tool itself is stable but depends on your infrastructure. If you have slow disks, the searches tend to take more time. If you need more data retention, be sure to keep an eye on disk space. Otherwise, the service crashes easily.

The tool's scalability is tied to your infrastructure. You need to have the money and resources to scale your infrastructure. To scale up, you need faster disks and more servers.  My company had 15 users using the product for a small API, and the cost was not so high.

The product's tech support is very helpful and skilled.

Positive

The product's setup is difficult, since you need at least 5 servers in a distributed topology to achieve its full potential: 3 machines for elasticsearch, 1 for logstash and another for kibana

In house

"The tool is an open-source product, but you have to self-host it and you need specialized personnel to maintain it.

If you are self hosting the solution, you need to take care of indexes and understand cluster sharding and distributed systems' election system

Our company uses the solution for centralized logging and monitoring. We have slowly moved our Stackdriver to the solution as a cost-cutting measure. 

We have more than 100 technicians using the solution. 

The observability is the best available because it provides granular insights that identify reasons for defects. The observability is more powerful than Grafana because it is so granular.

The UI point of view is not very powerful because it is dependent on Kibana. This can be a struggle because it is not clear where observability features such as logging originate. The UI visualization could be more interesting.

For example, a centralized login for a strike driver only provides two choices for viewing. You can either view the log for an individual system or view the log at the centralized level. A more granular approach with locations, pods, and servers is preferred. 

For comparison, Stackdriver is awesome because it includes all information with respect to the UI point of view. 

I have been using the solution for a few months. 

We are still exploring the solution but find it to be very stable at the enterprise level. It is not a new product, its stability is trusted, and it is well suited for enterprise applications. Extra features are released with no stability issues. 

The solution is definitely scalable and that is one of the reasons we moved from Grafana. We use Spring Boot but the Spring Actuator's micrometer does not scale properly and is very slow. The solution can scale and manage all our monitoring needs in one place. 

Our team is able to solve issues so we do not need technical support. 

I previously used Stackdriver. 

The initial setup is difficult because the solution is an independent product that requires integration with the running system. A one-time configuration is needed for both cloud and on-premises systems. This is common for independent products so is not a big deal for our company. 

For comparison, Stackdriver is already built in the GCP so there is minimal configuration when deploying services in the GCP environment. 

We implemented the solution in-house. 

The solution is less expensive than Stackdriver and Grafana. 

Our company has a relationship with Google so we explored Stackdriver. Its monitoring and logging capabilities are interesting but observability is not that good and it is a bit costly. 

We slowly moved our logging dependencies from Stackdriver. Sometimes we used Splunk but we also used the solution and Grafana because our product is a bit dependent on Spring Boot. 

We found that the solution is more powerful than Grafana with respect to observability and it is more cost effective. 

When using the solution, it is important to understanding indexing concepts and the proper way to search logs from a visualization point of view. These two items work together internally to produce logs that can be filtered to specifications. 

I rate the solution an eight out of ten. 

Elastic Enterprise Search is the repository for time series and data from the onsite instrument that monitors variables in our mining infrastructure called tailing dams. We monitor the tailing dams' physical stability and take the information from the sales force and manual data introduced by the operators. The system captures the information in the Elastic Enterprise Searchtime series, and we make calculations and trigger events and alerts based on those calculations. We save them as well as the events and alert times.

Elastic Enterprise Search is a nonstructured database that can manage large amounts of nonstructured data. We also use a structured SQL database. I am unsure why our technical people selected Elastic Enterprise Search. The people that started the project selected open-source software and recommended the ETC component required in the system architecture. The Elastic Enterprise Search has been defined from the beginning of the project and fulfills the project's requirements. However, there is a lack of technical people to develop, implement and optimize equipment operation and web queries. This may be a problem with the provider, and they currently lack the resource to optimize the performance of the database.

Finding skilled people to work with Elastic Enterprise Search in the project team has been difficult. This may be because the development team has not considered it. It is important to improve the database performance because there is a large amount of data and the optimization of the queries and the system's performance are very important.

We also use three other databases, MinIO, PostgreSQL and PostgreSQL. We have a very skilled person on our team that knows how to use all these products. However, he's not responsible for optimization because it's the responsibility of the Indian provider that has to develop the application.

It is fairly stable.

It is a scalable solution. 70 people are working with this solution in the project, 35 on the development team and 20 backend people. We are working on the development, but it's part of the service that the Indian company has to provide. There are about 50 people on their development team who deal with all the development, infrastructure implementation, architecture definition and implementation of the software stack. We are the counterpart of that company.

Since it is open-source, we don't pay licensing fees. In the development and QA environment, we don't pay anything. We, however, have to pay for all the software, subscription, pre-protection and protection.

I rate this solution a seven out of ten. Because it is open-source, there is no technical support provided by the vendor, so we are moving to enterprise subscriptions for each of these products. We are allowed free licenses and implement enterprise or commercial licenses and the production of protections.

An original criterion selects the software stack because they have to be good tools, but they all have to be open-source. Nobody considers it because the original team that started the project worked in an investigation organization and was closer to open-source software.

They are not clear regarding the support of their solution when they go into production. That's why we are updating the licenses to interpret license subscriptions and assume their support for each software component.