Some of the drawbacks of using ES as a datastore are:
- Lack of transactional support (as you mention). We use Hazelcast as a
memcached layer between our application and ES. Hazelcast supports
distributed transactions. While not supporting commit and rollback upon a
write failure, it does give us the ability to commit multiple writes as a
single unit of work.
- No snapshotting of data. I miss this greatly for peace of mind. You
have to code your own solutions to be able to recover from corruption of the
Lucene indexes, as well as when ES introduces a change that requires a
reindexing of all the data. A shared gateway can help, but you will have to
pause indexing/flushing while making a backup of the repository.
- Near real time behavior is hard for most who come from DB background.
You can't insert a record then query for that record without issuing a
refresh call or delaying long enough to ensure the record has been indexed.
- No SQL support. It goes without saying, but this has an impact in such
there are no tools which allow you to manipulate data once it is in the
repository. Perhaps these will come in time.
Those are the big ones that I have noticed.
tracermedia interactive http://www.tracermedia.com/
780 King Ave. #106
Columbus, OH 43212
phone: (614) 298-0774
fax: (614) 298-0776
cell: (234) 738-2492
On Thu, Jun 23, 2011 at 11:55 AM, Spring Ninja email@example.com:
I have read through some threads where people mention that their only
datastore is ES. From what I have read it can be an option.
However, can you point out some drawbacks in doing so? My main no-go
is transaction support. I have another project using Google App Engine
and have an app that does not use transactions. It can be done but
requires more thinking.
I am currently syncing ES with MySQL, including transaction support.
However, I would love to let go of MySQL and not have to worry about