ES as a database?


(ajsie) #1

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?


(Karussell) #2

On 9 Jul., 20:12, ajsie johnny.weng....@gmail.com wrote:

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:

  1. 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 :wink:

  1. 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)

  2. 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...

  3. mutli tenancy is very very easy with ES (not so with Solr)


(Chris Berkhout) #3

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.)

Cheers,
Chris

On Sun, Jul 10, 2011 at 3:16 AM, Karussell tableyourtime@googlemail.com wrote:

On 9 Jul., 20:12, ajsie johnny.weng....@gmail.com wrote:

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:

  1. 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 :wink:

  1. 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)

  2. 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...

  3. mutli tenancy is very very easy with ES (not so with Solr)


(system) #4