My feedback will be strictly anecdotal. In fact, the majority of the
problems you may see people experience on the list are either user error or
a small bug which is quickly patched. There isn't a roadmap to say when 1.0
will be done, or what is the final feature set. This hasn't stopped many
organizations from using ES in production. We had started using it in
development since 0.5 in early 2010, and went into production with two
different applications; one with 0.11 and the other with 0.16. We havent run
into any trouble with resources, data loss/corruption, or performance.
In fact, during the summer of 2010 we were still running MongoDB and ES
until it became clear that it didn't make sense storing the same data in two
different data stores. ES had a much better story at that time regarding
sharding, replicas, and disk space issues. It was a no-brainer to pull the
plug on MongoDB. (I'm sure things are better for MongoDB by now.)
At the moment, I wouldn't run ES as my only data store without some way to
re-index data. For us, we run on Amazon EC2 and use the S3 gateway for long
term persistence. This is because our EC2 instances do not use EBS
(persistant hard disks), therefore when an instance goes away, so does the
local copy of the data. Of course, if we lose a primary shard and the nodes
carrying its replicas, the data is gone. This is why we use the S3 gateway.
ES keeps all of the data and cluster configuration there. If we lose every
node in the cluster, we can start the cluster back up and all the nodes will
initialize from the S3 gateway.
While Shay has done a good job of maintaining compatibility between release
versions, we haven't run into too many issues. I think I remember one
release where the data in the gateway was no longer compatible with an
upgrade version.
So, this brings us to the dirty word in Lucene-based storage, re-indexing.
Whether or not you ever experience data corruption, you will most likely run
into a situation where you have to re-index all of your data. It may be
caused by a incompatible release, a change in your mapping files, or a data
corruption problem. When this happens, you will most often have to re-index
all of your data.
The other threads discuss the high level abstractions that exist in some
databases but not in ES (NRT, transactions, WAN replication, snapshotting,
etc).
Right now, we write a copy of our ES data to S3 every 30 minutes in a simple
format of /// = byte. I would love to have a
feature where we can do this against a snapshot of the data instead of the
moving target we currently use. I don't have any experience with snapshotted
filesystems, but I am reading up on that now after you mentioned it.
-- jim
On Sat, Aug 13, 2011 at 8:16 PM, David Richardson <
david.richardson@enquora.com> wrote:
We're looking at ES from (I suspect) exactly the same perspective as
Vineeth. Our objective is to reduce the number of moving parts needed.
Have Googled and found a number of commentaries on this approach, including
the ones James linked to.
The one thing I haven't found a good answer to is the data integrity issue.
Haven't heard of recent Lucene index corruptions (assuming one isn't using
Java 7), but what are the real risks here?
We've been using couchdb-lucene for nearly two years without a hitch, but
with far too few documents (< 100k) and updates (half a dozen per doc, on
average) to have a good handle on this.
Is a lucene index recoverable in any way shape or form if it does go south?
using luke?
Would a snapshotting filesystem be an answer?
If an index goes south, are the problems replicated (is this a bit-level
replication) or will something in the replication process recognize
corruption at the index protocol level and prevent it from spreading?
I don't see how an external notification system can work unless all
activity is under control of a message broker, which adds a middleware layer
we'd like to avoid.
Shay has just written his thoughts on notifications in another thread.
Mostly it's about the implementation issues rather than an argument they
have no value. Nothing there surprises me, although I suspect he slightly
understated, if anything, the issues around maintaing wal integrity etc,
especially if one is depending on write quorums - a prime attraction for us.
Increasingly, we're finding that couchdb has become a queuing system for
us, actually, and that the external lucene indices are the primary source of
truth. If we can store the original document in the indices using ES, we may
not need couchdb and the moving parts count becomes smaller. I'm a little
concerned about the absence of a good reliability story in the java
ecosystem (ie erlang's supervisory trees) but at the highest level, I
suppose one uses Monit or something like that. Maybe even upstart or launchd
does it. And I see clues that Shay has included something like this inside
ES.
We use a master external evented listener that dispatches to a significant
number of command line invocations to perform all manner of actions
including temporal-based schema validations. It's attached to both couchdb
and Postgresql. This allows us to write individual tasks in a variety of
languages from bash to Python to Haskell - selection depending on the need
for external libraries usually. Call it sideware. This works extremely well
and allows exceptionally loose coupling.
One couchdb difficulty is the lack of chained map-reduce operations. I
wonder if ES can easily support the sort of recursive queries that would
ease the pain? dunno yet.
As ES has no concept (apparently) of access control, we'll be forced to use
some sort of access proxy - it could easily handle https too. Really want to
keep this lightweight.
We already live in a distributed world - our 'client' code is primarily web
apps running online and off. Most application logic is on the client.
These are really another species of distributed application and we've
learned to live happily without the crutch of referential integrity.
Given that a single http request is the basic unit of atomicity in this
world and that most business workflows are still modelled on paper documents
(hmmm, looks like a web page), an RDBMS creates a considerable impedance
mismatch. A document store works just fine here, and so far, ES seems to
make the querying a manageable beast.
I imagine, though, that for someone who thinks in terms of RDBMS the shift
can be just as difficult as, say, from imperative to functional programming.
Aside from index integrity, I suspect this is the real issue.
d.r.
