Hi, I am quite new to elasticsearch. I have been reading this article Elasticsearch as a NoSQL Database | Elastic Blog[Elasticsearch as a NoSQL Database](https://Elasticsearch as a NoSQL Database). This was posted in 2013. Do the concepts explained in this article still hold?
I think most high-level concepts still are valid, although a lot of work has gone into improving resiliency since then. Are there any particular concepts you are wondering about?
1 Like
Thank you for the response.
One concept is the Robustness section. Specifically this part: " Unfortunately, Elasticsearch (and the components it's made of) does not currently handle OutOfMemory -errors very well. We cover this in more depth in Elasticsearch in Production, OutOfMemory-Caused Crashes. It is very important to provide Elasticsearch with enough memory and be careful before running searches with unknown memory requirements on a production cluster. "
I initially tried setting up elasticsearch in a machine with 8gb ram and found that it is not possible. I had to to take 16 gb ram but I am still left with 4gb free memory. How does one determine how much memory do you need for elasticsearch?
Memory management and protection against Running out of heap space has improved a LOT since that was written. Elasticsearch now behaves a lot better and uses less heap than it used to.
1 Like
Suppose there is an api where I store against the user , a count of the total api consumption. This would be useful as we can apply restrictions on maximum api calls to be made by the user. Does it make sense to store the count in elasticsearch?
I am not sure I understand the question. How is this related to the initial topic?
If this is an unrelated question I would recommend creating a new thread and provide more details about the use case.
I asked that question as it is a use case where the operation is not a "write once read many workload". In the above article Elasticsearch as a NoSQL Database | Elastic Blog, it is mentioned that elasticsearch is useful for write once read many workload.
If you have a use case with very frequent updates to documents I am not sure Elasticsearch is a natural choice. That is not what it has been optimised for.
Is there any useful metric that quantifies this frequency? What is the numerical upper limit that says that elasticsearch is not useful in this case?
No, not that I am aware of. You will likely need to test/benchmark as it likely depends on a number of factors.
If you need to manage counters with a high update rate I would expect something like e.g. Redis to be a good option.
1 Like
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.