What version of Elasticsearch is this guide targeting? I believe there are some fundamental differences between e.g. 0.9 and 1.0 releases if I'm not mistaken.
I'm looking at the guide and I see a lot of explanation but little to nothing in the way of clear, simple instructions that will cover the most typical basic use cases.
Of course Elasticsearch has many features and many different types of interfaces, but most people don't need to use most of those features, and having some example code available for a few common languages/platforms would be very useful.
Elasticsearch has done a great job of streamlining the use of Lucene and of course generally making many improvements, but based on the documentation I have seen including this new book, Elasticsearch must derive most of its income through consulting or support, and providing simple instructions obviously is a direct conflict of interest.
I believe that the average user is like me: they want to index some documents and then search the full text. They want a straightforward way to connect one or two search boxes on their web application to Elasticsearch and then retrieve some useful results. They do not want to learn the nuances of different engines or search interfaces. They do not want to read a book.
Well, you could use Solr. As with ES, the basic examples run out of the box. But frankly, whichever search engine you use, at some point you will have to read a book or dig hard to understand underlying issues such as tokenization. But starting is easy.
And the Solr community gets its income from all sorts of direction. So, the user mailing list is quite helpful.
What i'd really love to see is an administrating Elasticsearch guide and a common recipes guide, both would be super helpful for getting started and more advanced tasks. Having run into issues with Elasticsearch data scaling, trying to pull answers out of the current guides or the IRC channel is like pulling teeth... from an alligator... with a laser attached to its head.
Easiest way for me to learn Elasticsearch was through queries generated by Kibana [1] and playing with them inside Sense [2]. Kibana relies on Facets, version elasticsearch 1.0 introduces Aggregations, I would suggest using aggregations for your projects.
I recently started with elasticsearch for a hobby project, and my biggest issue with it is really finding things in the documentation.
For example, the documentation brings up relationships, like parent/child, but it isn't clear how to do the simplest case : return a parent's child documents.
Or the fact that the all the parameters to a request isn't listed in one clear place. Its all hidden by a dozen separate examples, but if I want to know options I can set for a _mapping, I can't find it.
Solr Cloud is more mature and more customizable. ES is perhaps easier to start with, but you could get a lot more customization and power with Solr Cloud. The Apache community will ensure Solr always remains at a bleeding edge and stable for large scale deployments.
I have used and spent time with both products and I couldn't disagree with this more. In my opinion, Elasticsearch is the more mature product and has been around longer than Solr Cloud (ES 2/2010, Solr Cloud 10/2012)[0][1], if you count Compass developement (ES' precursor) than even longer. Where ES was built from the ground up with clustering in mind, this is a feature that is certainly a primary focus for Solr Cloud but not a key feature for much of Solr's development. I would also contend that, in my opinion, there is no basis for the assessment that Solr Cloud provides "more power" than ES.
Elasticsearch has been an open project for some time, and they have recently formed a for-profit company in order to push the project forward even more. Certainly the Apache Project has an investment in Solr and, I certainly hope, that the project will continue even if Lucid Works (who employs 25% of the Solr developers)[2] were to close up shop.
If you need people to navigate through the information you provide and it is more than a couple of pages of links, you need search engine.
If your stuff is generic text then Google will find it for you. However, if you have categories, unusual languages, business logic, geographic locations and other non-pure-text content, custom search engines like ElasticSearch, Solr, etc will give your customers much better results than generic Google search.
As an example, do a search at LinkedIn and see all those categories and limits popping up on the left. That's what you can get from the search engines, but not from Google.
[+] [-] rcfox|12 years ago|reply
So far, the best resource I've found is "Exploring Elasticsearch". http://exploringelasticsearch.com/
[+] [-] pan69|12 years ago|reply
[+] [-] ilaksh|12 years ago|reply
Of course Elasticsearch has many features and many different types of interfaces, but most people don't need to use most of those features, and having some example code available for a few common languages/platforms would be very useful.
Elasticsearch has done a great job of streamlining the use of Lucene and of course generally making many improvements, but based on the documentation I have seen including this new book, Elasticsearch must derive most of its income through consulting or support, and providing simple instructions obviously is a direct conflict of interest.
I believe that the average user is like me: they want to index some documents and then search the full text. They want a straightforward way to connect one or two search boxes on their web application to Elasticsearch and then retrieve some useful results. They do not want to learn the nuances of different engines or search interfaces. They do not want to read a book.
[+] [-] arafalov|12 years ago|reply
And the Solr community gets its income from all sorts of direction. So, the user mailing list is quite helpful.
[+] [-] mikecx|12 years ago|reply
[+] [-] baghali|12 years ago|reply
[1] https://github.com/elasticsearch/kibana
[2] https://chrome.google.com/webstore/detail/sense/doinijnbnggo...
[+] [-] nemothekid|12 years ago|reply
For example, the documentation brings up relationships, like parent/child, but it isn't clear how to do the simplest case : return a parent's child documents.
Or the fact that the all the parameters to a request isn't listed in one clear place. Its all hidden by a dozen separate examples, but if I want to know options I can set for a _mapping, I can't find it.
[+] [-] jackhoy|12 years ago|reply
http://red-badger.com/blog/2013/11/08/getting-started-with-e...
Looking forward to reading this book! Elasticsearch has been a great tool for us.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] brickcap|12 years ago|reply
http://exploringelasticsearch.com/
[+] [-] trustfundbaby|12 years ago|reply
"Elasticsearch Server" is another really good book for anyone who's interested. http://www.packtpub.com/elasticsearch-server-for-fast-scalab...
[+] [-] chatman|12 years ago|reply
[+] [-] cmiles74|12 years ago|reply
Elasticsearch has been an open project for some time, and they have recently formed a for-profit company in order to push the project forward even more. Certainly the Apache Project has an investment in Solr and, I certainly hope, that the project will continue even if Lucid Works (who employs 25% of the Solr developers)[2] were to close up shop.
[0]: http://en.wikipedia.org/wiki/Elasticsearch
[1]: http://en.wikipedia.org/wiki/Apache_Solr
[2]: http://www.lucidworks.com/about-us/
[+] [-] phirschybar|12 years ago|reply
[+] [-] PaulHoule|12 years ago|reply
[+] [-] djKianoosh|12 years ago|reply
[+] [-] hughes|12 years ago|reply
[+] [-] AznHisoka|12 years ago|reply
[+] [-] shanmoorthy|12 years ago|reply
[+] [-] hernan604|12 years ago|reply
[+] [-] notastartup|12 years ago|reply
[+] [-] arafalov|12 years ago|reply
If your stuff is generic text then Google will find it for you. However, if you have categories, unusual languages, business logic, geographic locations and other non-pure-text content, custom search engines like ElasticSearch, Solr, etc will give your customers much better results than generic Google search.
As an example, do a search at LinkedIn and see all those categories and limits popping up on the left. That's what you can get from the search engines, but not from Google.
[+] [-] vacri|12 years ago|reply
[+] [-] antocv|12 years ago|reply
Thanks dudes and dudettes.