This is the generally accepted dogma and it has some merit. However, having
two storage systems is more than a bit annoying. If you are aware of the
limitations and caveats, elasticsearch is actually a perfectly good
document store that happens to have a deeply integrated querying engine.
This is useful since most solutions involving a secondary store involve
solutions that have a much less capable querying engine and additional
latency + architectural complexity related to pumping around data to
Elasticsearch.
Elasticsearch crud operations are atomic. I.e. you can read your own writes
across the cluster. If you use the version attribute during updates, you
can detect version conflicts and prevent overwriting updates with stale
data as well. This is a similar model that you would find in e.g. couchdb
and similar document stores. There are not that many sharded and
replicated, horizontally scalable document stores out there and even fewer
with decent querying ability.
The caveat is that elasticsearch is not as battle tested as other solutions
in this space and that various people have shown that ways exist to cause
an Elasticsearch cluster to lose data, to corrupt data, etc. So, you need
to be prepared to be able to recover from such situations. That means you
need backups (e.g. use the snapshots feature) and a plan for when things go
bad.
The flip side is that other solutions have issues as well. Postgresql
clustering is brand new and probably has issues and if you use it in non
clustered mode, the failure scenarios get even more interesting. I use
Mariadb Galera cluster and it sucks big time and it needs a lot of
handholding during upgrades. Couchdb doesn't shard and shares server
failure scenarios with elasticsearch. Mongodb and cassandra each have had
their share of issues related to data corruption and data loss in the
recent past and both have recently fixed major issues related to that. So,
there are lots of solutions out there and none of them are perfect.
Elasticsearch has several major areas where it needs improvement (and which
are indeed being worked on in recent versions):
- it has many ways it can run out of memory. If you skim through the
release notes of recent versions, you'll see a lot of fixes related to that
including the use of e.g. circuit breakers. The problem with OOM's is that
it can cause a cascading cluster failure where one node becomes slow,
eventually drops out of the cluster and then other nodes start having the
same issues. I've personally seen Kibana kill our cluster on two occasions.
In both cases the logs of all nodes were full of OOM's and the cluster died
while simply clicking through different dashboards in Kibana. This has not
happened with the current 1.3.x version (yet) but that doesn't mean it is
impossible.
- split brain situations when a quorum is lost but not detected are fairly
easy to trigger. Every time I do a rolling update, the cluster takes
several seconds to catch up with fact that I'm shutting down nodes. I have
a three node cluster. One node goes down, means my cluster should be
yellow. Two nodes down means red and it should no longer accept writes. The
problem is that during those few seconds, the cluster status may not
reflect reality and nodes may in fact be accepting writes when they
shouldn't.
- A full cluster restart needs a lot of handholding. The reason for this
is that most of the failure scenarios relate to there not being a quorum
and detecting that. For example, if you simply restart the nodes one by one
quickly you will easily get your cluster in a red state where it should no
longer be accepting writes. The problem as described above is that
detecting this relies on timeouts and there may be some nodes that continue
to write for a few seconds after they should have stopped doing that. By
the time your cluster goes red, it's too late and you are going to have to
manually decide which shards you want to loose. That's why you need to keep
an eye on cluster status during rolling updates. Imagine somebody power
cycling your Elasticsearch node cluster or worse, rebooting the switch
that connects your nodes.
- Elasticsearch under load may throw 503s occasionally. I've seen this
happen on our test infrastructure a couple of times and it worries me. This
is not something you want to see when you are writing customer data.
Mitigation for these issues typically involves using specialized nodes for
read and write traffic and cluster management. Additionally, you need to
heavily tweak things to make certain failure scenarios less likely. Out of
the box, there is a lot of stuff that can go wrong.
We're actually deprecating our mariadb architecture and switching to an
elasticsearch only architecture. I'm well aware that I'm taking a risk here
and I have a backup plan for most of those risks. This includes changing
plans and switching to couchdb or a similar document store if elasticsearch
proves to not be not up to the task. However, so far so good.
On Tuesday, August 26, 2014 6:55:10 AM UTC+2, Mo wrote:
In general use elasticsearch only as a secondary index. Have a copy of
data somewhere else which is more reliable. Elasticsearch often runs into
index corruption issues which are hard to resolve.
On Mon, Aug 25, 2014 at 9:30 PM, <xieh...@gmail.com <javascript:>> wrote:
On Tuesday, August 26, 2014 6:46:12 AM UTC+8, Raphael Waldmann wrote:
Hi,
First I would like to thanks all of you for Elastic. I am thinking in
use it in a ERP that I am building. What do you think about this? Am I
crazy?
Has someone face this? I really don't think that I am comfy enough to do
this, change the problems that I already know, for new problems that I
really don't know how to deal.
I believe that nosql will prevail over traditional sql, but I don't know
if I am ready to this task.
So how you think that I should integrate (or not) postgresql with
ELASTICSEARCH?
Will you plan t use ES to index data in postgresql?
I have similar idea, want to use ES instead datawarehouse.
Some problems I can see:
- Data in RDBMS are stored in tables, connected with relationship. You
can use very complex sql to query a complex result, how to do in ES?
- If your want to run some analyse algorithms with exist data, how to
running in ES?
- if your data are enough big, search one keyword in '_all' field, ES
will be slow?
Thanks.
-Terrs
Thanks again,
rsw1981
--
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 elasticsearc...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/f5500235-46e8-4c6c-8597-e42d7401d22a%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/f5500235-46e8-4c6c-8597-e42d7401d22a%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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 elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/390d6744-cfe9-4068-b3dd-fc8337355ee2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.