I have stumbled upon Elastic search which seems to be a very nice full
text search engine. It is schema less, distributed, using JSON and
RESTful API just like CouchDB.
You can add records and retrieve them, also do powerful search in the
texts.
Here are my questions:
Could Elastic search be used as a database?
Why would I want to put documents in CouchDB then put the same
documents in Elastic search then only query from Elastic search?
I have stumbled upon Elastic search which seems to be a very nice full
text search engine. It is schema less, distributed, using JSON and
RESTful API just like CouchDB.
You can add records and retrieve them, also do powerful search in the
texts.
Here are my questions:
Could Elastic search be used as a database?
yes
Why would I want to put documents in CouchDB then put the same
documents in Elastic search then only query from Elastic search?
There are normally limitations with search servers like e.g. Solr but
many of them are avoided or can be neglected for Elasticsearch.
Examples:
indexing requires time and the document are searchable only after a
'commit' in Solr => Elasticsearch supports near real time but still
the document is searchable only after some latency time!
BUT Elasticsearch now (0.17) supports real time get requests which
means you can put the doc into ES and check immediately if it is there
or get the associated raw data. This is a big nice and cool feature
normally setting up a replica or a shard requires a lot of planning
and thinking (e.g. with Solr although ... it is ok to other commercial
solutions :)) BUT with Elasticsearch this is really easy (especially
to set up replicas)
ES has versioning support which makes it possible to avoid a
refresh which reduces a lot load and e.g. Solr has no such versioning
feature...
mutli tenancy is very very easy with ES (not so with Solr)
If you're using Ruby take a look at Karel Minarik's "tire" gem.
For info on using ES as your DB, look for "Tire implements not only
searchable features, but also persistence features." near the end of
the README at:
If you are only going to lookup your data from ES, that is a sign
that you should seriously consider getting rid of CouchDB.
In my case, I'm using MongoDB via Mongoid as well, because Mongoid has
more robust persistance for Rails than Tire currently does, and
because MongoDB offers us ways to work with the data beyond store,
search and retrieve (e.g. updating individual fields rather than the
whole document, doing map-reduce, etc.)
I have stumbled upon Elastic search which seems to be a very nice full
text search engine. It is schema less, distributed, using JSON and
RESTful API just like CouchDB.
You can add records and retrieve them, also do powerful search in the
texts.
Here are my questions:
Could Elastic search be used as a database?
yes
Why would I want to put documents in CouchDB then put the same
documents in Elastic search then only query from Elastic search?
There are normally limitations with search servers like e.g. Solr but
many of them are avoided or can be neglected for Elasticsearch.
Examples:
indexing requires time and the document are searchable only after a
'commit' in Solr => Elasticsearch supports near real time but still
the document is searchable only after some latency time!
BUT Elasticsearch now (0.17) supports real time get requests which
means you can put the doc into ES and check immediately if it is there
or get the associated raw data. This is a big nice and cool feature
normally setting up a replica or a shard requires a lot of planning
and thinking (e.g. with Solr although ... it is ok to other commercial
solutions :)) BUT with Elasticsearch this is really easy (especially
to set up replicas)
ES has versioning support which makes it possible to avoid a
refresh which reduces a lot load and e.g. Solr has no such versioning
feature...
mutli tenancy is very very easy with ES (not so with Solr)
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.