4 comments

[ 2.6 ms ] story [ 25.0 ms ] thread
Interesting. How does this compare with SOLR and it's built-in sharding mechanisms?
ElasticSearch sharding is implemented in a manner that is on par with current, state of the art, data grids, and probably much better than most nosql solutions out there, but I am biased, since I wrote it... .

For example, elasticsearch is fully API driven, and you can dynamically created indices on it using an API. When you create an index, you can control its sharding and number of replicas, and elasticsearch will take care of the rest. Just start more nodes, and shards will be reallocated. Execute a request to a node, and it will automatically either route the request to the correct node, or do a map / reduce on the relevant shards to perform a search.

With its auto discovery, its a snap to start it. No need to preconfigure anything, especially with multicast hostile cloud environments, since its smart enough to use the cloud API to discover other nodes (see here: http://www.elasticsearch.com/blog/2010/05/11/here-comes-the-...).

Of course, there are much more features to elasticsearch then just being distributed. For example, it can "speak" the application domain model: http://www.elasticsearch.com/blog/2010/02/12/yourdatayoursea..., and has smart long term persistance support (ala data grid write behind support) which includes cloud blob stores (S3, CloudFiles) and hadoop (http://www.elasticsearch.com/blog/2010/02/16/searchengine_ti...). There is a nice high level breakdown of the features here: http://www.elasticsearch.com/products/elasticsearch/.

Elasticsearch is definitely the hotness. I use it with riak to index json. Riak search is coming but elasticsearch is here now. The http interface to elasticsearch (and riak) makes it dead simple to get data into and out of the index.

Keep up the good work kimchy!