Earlier quoted context omitted.
Complexity. Having two copies of the data means more dev time, more resources required to shift the data around, etc. Having just 1 data store that can also handle all your searching is like the holy grail. As you say, not sure if Solr/ES/Lucene are there yet - but they're definitely very very close. There is no theoretical barrier either - it just comes down to closing bugs, and the ES/Lucene team are very good at c…
Sometimes, I actually find it easier to have more systems that do their job really well and sync things between them, rather than trying to get a single system to do everything. For example, Postgres lets you reason about integrity, atomicity and transactional boundaries, and whether things are really safely stored with synchronous replication. If Postgres returns after a commit, I trust it. However, that requires me…
Elasticsearch 1.0.0 released
51–60 of 139 posts
Re: Elasticsearch 1.0.0 released
#52Earlier quoted context omitted.
On ElasticSearch you have to update the whole document, no commands to manipulate them. You don't have commands like: $set, $addToSet, $pop, etc.. You need to have a good understanding of how tokenizers and analyzers work to be able to create good results for your data. I have difficulties matching documents with the exact title being searched for. On MongoDB that just works, on ElasticSearch you need to configure it…
Regarding updates, you can use the Update API for partial updates, and include a script to do things like "counter += 1" or "add value to existing array" . Internally it is still reindexing the entire document, but from your application's perspective, the Update API is a lot friendlier. http://www.elasticsearch.org/guide/en/elasticsearch/referenc...
Re: Elasticsearch 1.0.0 released
#53Elasticsearch is really awesome for searching, but what most people don't realize is that it makes a better MongoDB than MongoDB while giving you that searching too.
That said, it's definitely worth looking into both, depending on what your needs are.
Re: Elasticsearch 1.0.0 released
#54Re: Elasticsearch 1.0.0 released
#55Earlier quoted context omitted.
I'm surprised so many people miss this. Out of the box, Elasticsearch is a distributed NoSQL store with better write consistency (and arguably performance) than MongoDB offers in its default configuration. The major missing feature was backup snapshots and restores, which 1.0 delivers—along with aggregations that more than rival MongoDBs. The team has intentionally avoided marketing themselves as a NoSQL store (was t…
did not know all that stuff, could Elasticsearch be the holy grail of document stores ?
For example, Elasticsearch has poor availability characteristics - both because it is master-slave and because it focuses on ensuring consistency - relative to, for example, something like Riak.
Re: Elasticsearch 1.0.0 released
#56Earlier quoted context omitted.
What limitations should one be aware of that would make ElasticSearch not a viable candidate where something like MongoDB would be a better fit?
I can't comment much on MongoDB, but I've written a bit things to keep in mind when considering Elasticsearch as a NoSQL store here: https://www.found.no/foundation/elasticsearch-as-nosql/
Side note: Happy Found customer here...you guys have made it much easier to run our ES index!
Re: Elasticsearch 1.0.0 released
#57Earlier quoted context omitted.
I'm surprised so many people miss this. Out of the box, Elasticsearch is a distributed NoSQL store with better write consistency (and arguably performance) than MongoDB offers in its default configuration. The major missing feature was backup snapshots and restores, which 1.0 delivers—along with aggregations that more than rival MongoDBs. The team has intentionally avoided marketing themselves as a NoSQL store (was t…
did not know all that stuff, could Elasticsearch be the holy grail of document stores ?
There's no holy grail of data storage... ElasticSearch is really nice, and if it fits your needs, more power to you.
Re: Elasticsearch 1.0.0 released
#58Earlier quoted context omitted.
What limitations should one be aware of that would make ElasticSearch not a viable candidate where something like MongoDB would be a better fit?
presharding You create a number of shards for each index(database) that you can't later expand.
The benefit of this is the as your app scales, you'll search only the shards needed. So if you have just 1 shard w/ data, u can tell ElasticSearch to just search in that 1 shard.
Re: Elasticsearch 1.0.0 released
#59I also took a few days a few weeks ago to setup elastic search after my mysql full text search fell apart. What I'm doing is slamming the full text output of OCRed PDFs into a MyISAM table, the entire document in a text field. What I'm afraid I'm not doing right is creating the web interface to search elasticsearch. What I'm using filters with the query string syntax[1] in the search box, pointing directly at that fu…
Do you mean that you use ES to do indexing on the backend of your documents and make it available on the web? Or do you mean that you use ES to index documents available on the web and let people to search for them?
Re: Elasticsearch 1.0.0 released
#60Earlier quoted context omitted.
Sometimes, I actually find it easier to have more systems that do their job really well and sync things between them, rather than trying to get a single system to do everything. For example, Postgres lets you reason about integrity, atomicity and transactional boundaries, and whether things are really safely stored with synchronous replication. If Postgres returns after a commit, I trust it. However, that requires me…
I'd like to point out that two competing founders of hosted Elasticsearch as a service agree: ES is great, but not a general-purpose data store :-)
Indeed!
That said, it's great that more people are picking up Elasticsearch for new exciting things.
Elasticsearch has really pushed what constitutes a "search problem", and deserves lots of kudos for that! :)