Is it a good practice to use "Memcached" with ES, or would the built-in
"Node Filter Cache" provide sufficient caching?
Just a caveat that you probably already know, but caching should only
be used when absolutely needed. If you're coming up against
performance issues, you'll probably be looking at a host of other
solutions (upping the number of nodes, or improving your queries and
index structure, for example) before considering caching.
But if you're bent on caching, then memcached is probably as good as
any other caching solution. ES would be mostly blind to any external
caching you use in which case what caching solution is easily
available to you, what you are more familiar with, and what is more in
tune with your needs is more important than any 'good practice'
considerations in that context.
- Ifty.
On Thu, Aug 9, 2012 at 9:59 PM, curious springdalian@gmail.com wrote:
Is it a good practice to use "Memcached" with ES, or would the built-in
"Node Filter Cache" provide sufficient caching?
--
The best thing is to keep your Elasticsearch index in memory, and to avoid
double-caching.
Memcached is for dynamic web sites where pages are built so slow from
backend systems that the request rate exceed it. As it is for pages and
objects in a web server, I don't see a reason for using it with
Elasticsearch.
But, if you do things wrong, you can force Elasticsearch queries to become
slow in your app, so you need tricks to satisy high query rates, as with
every other search engine or backend, too. In most cases, caching results
of badly designed queries should not be preferred because it does not solve
the real problem.
Best regards,
Jörg
On Thursday, August 9, 2012 9:59:58 PM UTC+2, curious wrote:
Is it a good practice to use "Memcached" with ES, or would the built-in
"Node Filter Cache" provide sufficient caching?
--