ES as a database?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

ES as a database?

ajsie
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: ES as a database?

Karussell


On 9 Jul., 20:12, ajsie <[hidden email]> 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 ;)

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

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

4. mutli tenancy is very very easy with ES (not so with Solr)
Reply | Threaded
Open this post in threaded view
|

Re: ES as a database?

Chris Berkhout
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:
https://github.com/karmi/tire/

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 <[hidden email]> wrote:

>
>
> On 9 Jul., 20:12, ajsie <[hidden email]> 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 ;)
>
> 2. 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)
>
> 3. 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...
>
> 4. mutli tenancy is very very easy with ES (not so with Solr)
>