ElasticCloud(Elasticsearch, FedRAMP, SaaS Contract) [Private Offer Only]

Elastic Search  use cases for us involve maintaining a huge amount of data per day, around millions of transactions for each record. We are maintaining all this data with Elastic, and Elastic is doing a fantastic job by doing the indexing. The algorithm is very good, enabling us to process the data very fast.

We are conducting searches with Elastic Search  because the data volume is too high. With a couple of indexing configurations, we are able to achieve our goal.

A good feature of Elastic Search is that they have something called policies, which we can make hot and cold, all related to data retention, and that is what I appreciate the most.

From the UI point of view, we are using most probably Kibana, and I think they can do much better than that. That is something they can fine-tune a little bit, and then it will definitely be a good product.

Maintenance in terms of Elastic is that they can improve the UI and UX, and if they fine-tune it a little bit, then it will be much better.

I have used Elastic Search for the last two years in my career.

So far I haven't noticed any lagging, crashing, or downtime with Elastic Search.

The scalability of Elastic Search is good, and I am satisfied with that as of now, and the performance is good.

I don't think I have ever had to contact technical support.

I find the initial deployment of Elastic Search easy; it is quite straightforward.

Approximately, I am able to deploy Elastic Search within two to three hours for the first time.

To deploy, one or two people will be enough because you need Logstash  to be configured to bring the data to Elastic Search for indexing.

We tried to implement big data pipelines and all, and we tried to use Spark as well for analytics and data cleaning, but I think Elastic is better in that field. I didn't find anything better than that.

My use case has evolved over time with Elastic Search . Initially, we started with it as a searching solution. Before Elastic Search , our primary source of truth was SQL databases, the traditional RDBMS . We thought about taking the data from the traditional RDBMS  because they were not able to cater to the scale that we wanted to achieve, so we migrated the data from MySQL , keeping it as the primary source of truth, but for the searching mechanism and wildcard searches, we migrated to Elastic Search.

My experience with the relevancy of search results in Elastic Search includes both traditional keywords and full-text search. In the supply chain industry, with millions of orders and customers such as CMA CGM, Maersk, or Kuehne+Nagel, filtering out those orders was essential, using a shipment number, transportation order number, or an origin or destination number. In the gaming industry at FDJ United, full-text searches make more sense to understand gaming intent. For example, when a user searches for 'I really want to play action games', we break down that full-text query, use custom text analyzers, and derive the intent behind the user's query in combination with a vector database alongside Elastic Search.

My assessment of the effectiveness of hybrid search, combining vector and text searches, shows that Elastic Search is remarkable for text-based searches. I have explored other solutions, but none can beat Elastic Search in that area. When I combine hybrid searches with vector databases, they store the mathematical representation of the data. For instance, to find the top 10 closest proximity based on a query, the vector database uses cosine similarity on the available data and suggests the top 10 results while Elastic Search can keep the metadata, enabling quick access to the entire database based on derived intent.

I have utilized trusted GenAI experiences related to semantic search and text-based search in my current project using Elastic Search. My go-to solution for text-based searches will always be Elastic Search, but for semantic search, I am trying to build a solution that emphasizes system-level understanding agents. For example, if a new engineer queries the agent for a system explanation, it scans all the relevant data and provides a comprehensive analysis of the service, contextualizing inputs to reduce hallucination, controlled temperatures for the LLM model, and reducing nucleus sampling. As for knowledge preservation, I use a vector database to store significant outputs generated by the LLM, depending on user preferences regarding the gravity of the analyses performed.

The best features of Elastic Search that I appreciate include its capability for eventual consistent systems where you do not need hard consistency, and it scales very smoothly. For wildcard searches and regex patterns, it really scales massively. It offers ILM, indexation lifecycle management, which allows you to enable a search for a span of six months for the data fed into the system while moving the rest to a new cluster. The structure of the inverted index document facilitates its core features, and I find how Elastic Search understands, indexes, and creates mappings for your data to be remarkable.

While Elastic Search is a good product, I see areas for improvement, particularly regarding the misconception that any amount of data can simply be dumped into Elastic Search. When creating an index, careful consideration of data massaging is essential. Elastic Search stores mappings for various data types, which must remain below a certain threshold to maintain functionality. Users need to throttle the number of fields for searching to avoid overloading the system and ensure that the design of the document is efficient for the Elastic Search index. Additionally, I suggest utilizing ILM periodically throughout the year to manage data shuffling between clusters, preventing hotspots in the distribution of requests across nodes.

I have been using Elastic Search for more than six years.

In terms of stability, I would rate it eight out of ten regarding downtime, bugs, and glitches.

For scalability, I assign it a ten out of ten.

I would rate Elastic Search's technical support as nine out of ten.

Before Elastic Search, our primary source of truth was SQL databases, the traditional RDBMS.

Estimating the return on investment from Elastic Search is nuanced; however, I can share that initially, search times from traditional RDBMS were around two to three seconds, and with Elastic Search, we reduced that to 50 milliseconds, indicating a significant improvement.

Assessing the complexity of deploying Elastic Search, I have a gray area because a separate DevOps team handles that aspect, but from my experience writing code and utilizing its features, I find it not complex at all.

Estimating the return on investment from Elastic Search is nuanced; however, I can share that initially, search times from traditional RDBMS were around two to three seconds, and with Elastic Search, we reduced that to 50 milliseconds, indicating a significant improvement.

On the subject of pricing, Elastic Search is very cost-efficient. You can host it on-premises, which would incur zero cost, or take it as a SaaS-based service, where the expenses remain minimal.

When comparing Elastic Search to other vendors and products, I have recently explored Algolia , which is also a fully managed service. Elastic Search offers a choice between hosting on-premises or as a fully managed service, which has been beneficial compared to other solutions.

In my company's relationship with the vendor, I have always worked in product-based companies using Elastic Search, often as part of solutions from companies such as Manhattan Associates and in the gaming sector. For B2B industries, they sold to large clients such as Maersk and CMA CGM while my current company, Agoda, operates in the B2C space.

Elastic Search does require some maintenance, especially when considering features such as ILM if you want to enjoy its capabilities. Maintenance tasks depend on the established data pipeline and may introduce some friction.

Currently, we are not using Elastic streams for log ingestion; previously, we utilized the ELK and EFK stacks with Logstash  for log ingestion and Kibana for visualization. I also observe a trend where companies migrate to Grafana Loki  instead of ELK.

Regarding integration aspects, Elastic Search has exposed REST APIs for all its services, making it easy to integrate with third-party models or endpoints regardless of the underlying infrastructure, as any modern development language can interact with these REST services.

I have not used the attack discovery feature.

My deployment of Elastic Search is on-premises.

At Agoda, we handle over 1.2 billion searches daily, facilitated by Elastic Search.

While I have been at my current company for four months, I am still getting to know my colleagues; however, I know there is a dedicated team focused on Elastic Search. This team exposes a service that acts as an intermediary for communication between Elastic Search and other services.

In my department, there are more than 100 people, whereas the overall organization consists of thousands, exceeding 10,000.

I would rate this review overall as a nine out of ten.

I have completed two different Elastic Search  implementations, and in both cases, the goal was to speed up very slow Postgres databases. As a platform PM, I am typically responsible for user management and company management. These areas are quite heavy depending on how many users, customers, or companies exist. Before Elastic Search, when we relied solely on Postgres, there were significant delays to user list pages and company list pages. In the other company, there was a lot of data displayed for particular list pages for admins. We combined Postgres with Elastic Search to speed this up, and it certainly does speed it up. We have used it throughout my current job and previous job.

From the customer side, Elastic Search is super fast and very efficient, delivering results quickly. We recently tuned a series of compliance results in the CMS where we would specify that certain results should come up higher by adding keywords and other factors. However, the results were not as good as when we restarted and used Elastic Search out-of-the-box search results. We actually got better results that were more logical.

The most significant issue I find with Elastic Search is that it gets out of sync, and this has happened in both cases where I have implemented it. When Elastic Search gets out of sync, for instance, if I create a company or user, it gets created in Postgres and then sometimes there is a delay for it to appear in Elastic Search. This could be a 15-minute delay depending on how it was implemented. If other significant processes are running on the platform where you are touching a lot of records, such as a million records, that will take a hit on Elastic Search. We have seen differences of 800 records between Postgres and Elastic Search. Proactive tools that would find and adjust any mismatches would be beneficial.

Occasionally, Elastic Search has failed, and when that happens, search results do not come up at all. This has been a rare occurrence, and I am not certain Elastic Search is entirely to blame, as it could have been platform storage or other factors. For the most part, the most common problem is the out-of-sync issue.

I have used Elastic Search  since 2019 at the last two companies where I have worked.

I would say Elastic Search is pretty scalable. We have had good results.

Earlier, in the 2019 and 2020 range, we were having a lot of trouble with syncing, and we tried to see if consulting was available. At the time, we could not find what we needed from the knowledge bases, and we could not really get support. There was not a technical support option at that time. That may have changed. Currently, I do not think we have gone to Elastic Search to ask for any significant help.

Google Appliance was a search engine that Google had for a while, and we used that and were pretty happy with it, but then they deprecated it and it is no longer available. After that, I do not remember what we used, something else.

Although I am not an engineer, it seemed easy to medium to set up. It was not complicated.

For the initial rollout, I would say it was maybe two or three people for the initial implementation, and then I have a team of 40 or 50 engineers with somebody always working on updates and other tasks.

We have not yet used anything in combination with Elastic Search, but that is on the roadmap.

I would say Elastic Search's relevancy is okay, and if I were to give it a score, I would give it a B. Elastic Search works best out of the box as much as possible. When you start to overtune or put in other factors that will increase the priority of specific results you want to come up, it gets really complicated and then you do not necessarily get the best results.

Elastic Search works best when used out of the box without excessive tuning. My overall review rating for Elastic Search is seven out of ten.