Guys,.. thank you for your input.
I can agree about terminology, and "near real time" feature. But those are
more like minor inconvenience to me.
From my experience, I worked around those inconveniences, same way as we
work around inconveniences with SQL DBs.
I guess NRT allows ES to run crazy fast, and in Ajax based web applications
I always was able to make impression to users that they are getting Real
Time data. Only NRT Delete was kind of tricky, but still not a problem.
From responses, I see that only data loss is the major issue. I didn't have
such problem. I had to restored from daily back-ups, but purely of human
factor issues, not failure of the system.
I had nodes screwed up few times, but plain ES restart resolved that.
I remamber some conversations about MySQL long time ago, that it also could
lost some data at some point. Usually those conversations was started by
Oracle guys before Oracle bought Sun. But I don't know any actual case of
production data loss reported by MySQL users nor by ES users.
Another good point is that MongoDB could update a field and ES could update
only whole document. In some cases this is very critical, but again, in my
cases, if document structure is right, this is acceptable to reindex whole
document, even if only one field is really updated.
So, I'd really like to hear from someone who had problem with data loss. If
someone had such experience, could one share the information about how it
happened, what kind of data it was, how big, how much load it was, etc...
Because if only the reason of Data Loss was the mentioned bug related to
opened files limit issue, then once it is fixed, we have nothing to worry
about. Even this bug, if the system is configured right, and opened file
limit number set correctly, then it is very unlikely to occur.
On Monday, April 1, 2013 1:52:57 AM UTC-4, Andy Wick wrote:
We switched our "big data" application from Mongo to ElasticSearch with
great success, in fact most of what it does wasn't even possible with
previous versions of Mongo. Mongo 2.4 is looking interesting, but I still
don't think it can do what we needed. The biggest thing to remember is
that currently Mongo is at heart a nosql database with text search "added"
and elasticsearch is search with nosql database "added".
The biggest thing I miss from mongo is actually terminology related.
Mongo uses "DB terminology" and ES uses "search terminology" for APIs and
documentation. I've had many "who's on first" moments, you understand the
words but the meaning is different, "index" being probably the biggest
offender. I guess it never hurts to learn something new, although at times
I wish there was a "normal" DB looking interface.
Mongo has much better data durability, load balancing and HA from a
database point of view. 0.90 is fixing some of the issues. If you can't
afford to loose data then don't use ES as the single source. You will most
likely loose part of a database at least once.
Mongo allows you to natively re-index (re-analyze) your data. ES
currently requires aliases and that you re-insert (re-index) the data using
an external program or script. Can be difficult to get right and not loose
data if you have constant writes.
Mongo has better software version upgrades. Most of the time you need
to restart the entire ES cluster with the new version. Makes it harder to
test out new software. I'm hoping this will change as ES matures.
Mongo has typical DB security if desired, ES does not
Don't want to seem overly negative here. ES has tons of cool features,
but in the nosql db world it is still an toddler, if you have time to grow
with it, then go for it. The data durability issue is really the biggest
thing you need to live with, the rest you can work around.
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
For more options, visit https://groups.google.com/groups/opt_out.