On Sun, 2011-10-23 at 14:26 -0700, Karussell wrote:
Yeah - the only thing in the way for me now is the 1 second delay on
searching after indexing a doc, ie that is something I have to code
around, rather than having it "just work".
Couldn't you use the realtime get feature instead of search for DB-
You can't use get when you don't know what you're getting. A simple
example is: the user adds a new comment, you return the page, showing
all comments (which should include the new comment left by the user).
A simple query won't include your newly added comment (or might,
depending on whether the index was refreshed automatically or not).
Instead you need to include the newly added comment in the list
I haven't yet thought through all the consequences of this 1 second
delay - they may all be as simple as the example I give above, but maybe
In my current framework, I use memcached in front of the database, so
there is an added complication of cache expiry of collections when
adding new objects.
Some queries are frequently used, and faster to return from memcached
than from the DB. As fast as ES is, the same may be true when using just
ES as your datastore.
Perhaps not. I very much doubt that doing a query in ES can be as fast
as getting cached results from memcached. But maybe it is fast enough
(and scalable enough) to allow me to remove memcached from the
If so, that would really simplify the architecture: no RDBM, no
memcached, no cache expiry.
But my gut instinct says that there is always likely to be a role for
I'm definitely going down the route of using ES as my only data store
for my next application, so I'll report back my experiences when I've