Re: ElasticSearch vs NoSQL

I just started playing with ES and had to comment this subject. 

imo, this question in subject (discussion is great!) is plain wrong. What I
would like to see somewhere is rather search and "nosql db". Keeping these
two topics apart is like saying, OK let us separate DBMS from indexing and
SQL. Search is great, nosqldb-s are great, but not enough. 

"traditional search" is just one application, useful, but just one
application. More traditional, and much more general computation model is
to
have some way to locate data (old way "SQL", new way "search"), retrieve
data (old way "SQL", new way nosql KV stores), do something with data (SQL
vs map-reduce today on mega-data) and put it back to storage/deliver
outside. 

What I am trying to say, the "new way" has one missing link, keeps data in
two completely separate worlds, technologically and logically apart (think
e.g. hbase and ES or cassandra and solr). This is expensive, hard to setup,
hard to keep in sync, duplicates demand on resources ... 

In ideal world, imagine hbase where each node keeps embedded lucene to
expose search part with all this magic Shay is doing with ES. This would
become one infrastructure to keep all players in sync , one set of APIs to
talk to clients... It Seams riak goes this way.     

I think I see this way of thinking behind ES, so imagine ES doing
map-reduce, keeping your data safe like hbase... :) 


Dreaming in public is, I guess,  OK   

Cheers, 
Eks