Elastic Cloud (Elasticsearch Service)

I can describe a few use cases for Elastic Search  because in my previous company, we had a message database and needed to implement a search system. We first used Postgres full text search, but it did not work well, so we had to migrate everything into Elastic Search . Elastic Search could better index the data and we could search every document in instant time.

The key differences between Elastic Search and Postgres search, including both pros and cons, are primarily related to indexing speed. In Postgres, the full text search speed is quite noticeable if you have a message document. In Elastic Search, I am not quite certain about when comparing to normal data, but for our use case of searching through message documents, the speed difference is noticeable in Postgres because our documents are very large. Since Elastic Search is primarily built for search, I think it can better search through the document. Our documents were sometimes really large, ranging from 100 megabytes to 200 megabytes per document, so I think Elastic Search handles this much better than Postgres.

What I appreciate about Elastic Search is that the best features include the ability to search through very big documents and index and search through them really fast. This is the one thing I value most about Elastic Search.

Regarding stability, I have not had any crashes, downtimes, or performance issues with it. We did have one incident, but it was not from Elastic Search. I think it was an AWS  service outage. The downtime was an AWS  error, not from Elastic Search.

Concerning scalability, I find it scalable because it is quite scalable right now. We currently have a terabyte of compliance data, and the client can search through that very effectively. We have not experienced any scalability errors so far. I think our compliance data amounts to approximately five or six terabytes of data, which is very large. We can search through that document quite easily, sometimes in 7 milliseconds, sometimes one or two milliseconds. It was quite fast.

Apart from the good things, what I would like to see improved or enhanced in Elastic Search is the storage cost. I think the main problem with Elastic Search is that sometimes the storage was quite expensive. We also have a file system in addition to compliance. We have an FDS  on our server, and we sometimes want to attach something on top of the FDS  and search through every file without having to create a search index dedicatedly.

The missing features or functionalities in Elastic Search that I would like to see included in the future or some functionality that requires enhancement would be the ability to attach to our file system, such as network file system or NFS, or maybe our on-premise NAS  server, and then search through everything, whether it is a document, text, or some information from those documents. That may be our primary use case right now, but we do not have that capability. Additionally, I would like to see a better search system so we can locally embed and find through everything.

I have been working with Elastic Search for approximately one or two years.

Regarding stability, I have not had any crashes, downtimes, or performance issues with it. We did have one incident, but it was not from Elastic Search. I think it was an AWS service outage, not from Elastic Search. The error was an AWS error.

Concerning scalability, I find it scalable because it is quite scalable right now. We currently have a terabyte of compliance data, and the client can search through that very effectively. We do not have any scalability errors so far. I think our compliance data amounts to approximately five or six terabytes of data, which is very large. We can search through that document quite easily, sometimes in 7 milliseconds, sometimes one or two milliseconds. It was quite fast.

I do not know anything about the tech support because I have not escalated any questions to the technical support or customer service teams. We have not talked to anyone.

I previously used a different solution for search. The solution I used for the search previously was Postgres full text search.

The initial setup process of Elastic Search was straightforward. I did not face many challenges or complexities except for the fact that we had to extract every document and build a search index. Aside from that, we did not experience much complexity during that time.

When it comes to pricing, I think we had to pay AWS approximately 1,000 to 1,200 per month for the overall stack. I am not quite certain about how much Elastic Search costs specifically because I was not in charge of pricing. The overall system cost was approximately 1,200 to 1,500 per month.

I do not find it cost-effective. I am not quite certain. Maybe the client might complain, but I am not certain. We just built out the system.

Before choosing Elastic Search, I evaluated other options. At first, we tried to go with Redis  search because we really needed fast retrieval, but Redis  search was closed source at that time, so we could not go with Redis search. We had to try Elastic Search and it performed quite surprisingly well.

Given my experience with Elastic Search, a piece of advice or recommendation I may share with other organizations considering it is that if you are looking for a simple search, I am not certain whether I would recommend Elastic Search. However, if you are handling message data with a massive amount of data and you need sub-millisecond search time, I think in that scenario Elastic Search outperforms everything. I would give this product a rating of eight out of ten. Especially if you are using SQL to search through the data, Elastic Search really outperforms SQL when you have to search through massive data.