Anyone able to refute these points? As someone who's used Sphinx quite a lot, and was hoping to dive I to ES, some of these points are disappointing to hear (particularly prefix/infix support)
Some of these points aren't too important, like having to use composer (you don't ever have to use composer, by the way). The library file size I'm also not too concerned about.
Result speed and the terrible docs are interesting, however.
I can't comment on this as it's a php installation but the rails integration on elasticsearch was pretty easy and fast. It gave us so much speed that we decided to use it as a full cms read data store for our website.
While elastic search queries ARE verbose (we've clocked up a query 23 levels deep in our app), the first example stated here is unnecessarily verbose. He's using a `bool should` query, with only one value in it. A `bool should` is basically an `or` statement, so he could replace the whole thing with the single query he has inside it.
This definitely feels like a rant that picks up on a few issues with ES, and then smothers it with a variety of things which are different, but not really "issues". I've found the ES documentation to be a bit fragmented, but good once you know where things are. It's not the most newbie friendly system, but once you're up and running it's incredibly powerful.
To be fair, the documentation does seem to have improved quite a bit with the 1.1 and 1.2 releases. My biggest problem with it has been snippets of examples in the query DSL sections with no clue as to where you put those snippets. Some examples now show full curl commands which is a huge improvement.
That's because there's no one place to put the snippets. They work in multiple places, and can be embedded within one another. It's very powerful, and very confusing to get started with.
Some of these points are valid, such as the verbose query language, horrible diagnostics, as well as the ease of making serious, irreversible mistakes. If you're starting ElasticSearch, I highly recommend:
- Making daily backups with S3.
- Having a replica physical cluster (note, not a replica node). Because replica nodes can corrupt each other.
- Forget about rivers. Implement your own. What I did was push row ids into a Redis list, and when the list becomes filled with 100 IDs, I query all 100 items from my database, and index them into ElasticSearch. Nothing complicated.
11 comments
[ 5.2 ms ] story [ 40.8 ms ] threadSome of these points aren't too important, like having to use composer (you don't ever have to use composer, by the way). The library file size I'm also not too concerned about.
Result speed and the terrible docs are interesting, however.
This definitely feels like a rant that picks up on a few issues with ES, and then smothers it with a variety of things which are different, but not really "issues". I've found the ES documentation to be a bit fragmented, but good once you know where things are. It's not the most newbie friendly system, but once you're up and running it's incredibly powerful.
They acknowledge this themselves as well, that's why they released a book that should help first time users to navigate through ES: http://www.elasticsearch.org/blog/elasticsearch-definitive-g...
Well, get with the times ffs.
Amuzingly, I recently integrated ES with a Yii app and it ran wonderfully. Sped up our search considerably.
- Making daily backups with S3.
- Having a replica physical cluster (note, not a replica node). Because replica nodes can corrupt each other.
- Forget about rivers. Implement your own. What I did was push row ids into a Redis list, and when the list becomes filled with 100 IDs, I query all 100 items from my database, and index them into ElasticSearch. Nothing complicated.