[jasonkolb]

I'm sitting in Elasticsearch training right now (during a caffeine break). These are some really great guys that know their stuff, and they're committed to contributing back to the OSS version everything that makes sense. They contribute a ton of code back to Lucene and employ a lot of the brightest minds in this space.

On the product side, I'm sitting here being amazed at some of the problems they've solved very elegantly. Elasticsearch has a bright future.

[mewwts]

I'm starting a new job in August where I will focus on building search-based applications with Elasticsearch. I honestly can't wait. This news makes me happy as I know I'll be learning relevant technology.

[cbeach]

I'm also in Elasticsearch training (Victoria, London). Impressed with the trainers, both core developers with a passion for the product. Bodes well.

[latj]

How is it better than Solr?

I havent looked at Elastic Search in a long time, so I really do want to know. Not trying to pick a fight. ;)

[diminish]

I m using it since earlier versions for almost 3 yers, i guess. It makes config easier, offers a well designed, easy API. Especially for Rails, PHP, Django crowd, an easy choice to create a sensible text search. The main benefit was an easier Lucene with JSON/http API. Yes a lot more advanced features are there too.

[didip]

* Kibana on ElasticSearch. This is huge. You get a polished Search & Graphing UI with very little effort.

* Much more approachable config.

* Its clustering is easier to setup.

* Eventhough logstash is a bit heavy for my taste, the whole ELK stack is really nice for aggregating server logs.

[bbq]

Agreed about logstash being too heavy for your app servers. It would be nice to have the functionality in a trim, native binary.

As things are, one can always direct an app sever's syslog to a logging fleet running logstash (or elasticsearch running embedded logstash): http://cookbook.logstash.net/recipes/rsyslog-agent/

[tveita]

I think that's what Heka is supposed to be.

It looks pretty promising, but I have yet to meet anyone who uses it.

https://blog.mozilla.org/services/2013/04/30/introducing-hek...

[bbq]

Oh, that looks very nice. Neat to embed Lua as a sandboxed plugin environment.

[btgeekboy]

Re: logstash too heavy

That's what logstash-forwarder[1] (formerly lumberjack) is for. It's in Go, not Java.

[1] https://github.com/elasticsearch/logstash-forwarder

[caw]

I use beaver, which is a python variant of the logstash agent

[arafalov]

Solr has an ELK equivalent, called SILK. Actually uses most of the same components (Banana=Kibana for Solr, etc): http://www.lucidworks.com/lucidworks-silk/

[mhitza]

Advantageous may be the fact that you can extend ElasticSearch with JavaScript, whereas I think as easy for someone who understands the Solr codebase, I've wanted to try that once, but I had to resort to doing the necessary computation in the language calling the Solr service.

[arafalov]

An overview presentation video was just released: http://www.berlinbuzzwords.de/session/side-side-elasticsearc...

If you want to know more details, vote for my talk in November, I'll be digging into much more technical comparison: http://lucenerevolution.uservoice.com/forums/254257-open-sou...

[jasonkolb]

Honestly I'm not sure, I haven't used Solr. I was just comparing it to the relational databases I've used, key-value stores like Cassandra, and other documents stores like Mongo. It definitely doesn't replace relational stores, but IMO blows all of the other NoSQL data stores out of the water. The Lucene indexing behind the scenes just really delivers some impressive functionality.

[nl]

I've used both, although not Solr 4.

Elasticsearch has easier config, especially for clustering. It is designed to be schemaless so you can push almost any JSON data into it.

Performance is adequate in both.

It's not a big advantage either way, unless you need clustering.

[ejain]

Elasticsearch isn't really schemaless, but you can have it guess and extend the schema as fields are encountered (or you can have it treat specific field as blobs of unindexed json).