Elasticsearch – the definitive guide
elasticsearch.org
elasticsearch.org
So far, the best resource I've found is "Exploring Elasticsearch". http://exploringelasticsearch.com/
That said, the basic concepts should be more-or-less unchanged.
[0] http://www.elasticsearch.org/guide/
[1] http://www.elasticsearch.org/guide/en/elasticsearch/referenc...
[2] http://www.elasticsearch.org/guide/en/elasticsearch/referenc...
Aside from not mentioning aggregations it should be fairly accurate, and is still a useful guide for a beginner.
I' hoping to revamp it to discuss aggregations over the next couple weeks.
I lost most of my disqus comments, unfortunately, when I relaunched the site last week as the URL structure changed. I revamped the book to have more content per page. It's probably a little less SEO friendly, but makes for a nicer reading experience.
I would really appreciate if you could put it back, it's really a good listen.
If you are talking about "The Definitive Guide", it is targeted to Elasticsearch 1.0. Most of the APIs and concepts are backwards compatible, but we wanted to target 1.0 because it brings a lot of great new features.
The main issue with it at the moment is that it doesn't take into account the new aggregations stuff.
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.
And the Solr community gets its income from all sorts of direction. So, the user mailing list is quite helpful.
So what you are suggesting, that I should use Solr since the Elasticsearch documentation is difficult to navigate or perhaps incomplete, is almost like saying "I think it should be difficult to figure out how to use ElasticSearch, since its so powerful, its not for kids. Therefore, the documentation is deliberately opaque. If you want something easy, use Solr."
Hope you find that useful. Any feedback is appreciated!
When you begin incorporating ES into your application, roughly you’d be thinking about: 1. Figuring out the structure of your data and translating that into ES’s mapping 2. Learning the query syntax (the ES docs assume you already know Lucene, not usually the case.) 3. Setup an ingest workflow and keeping your indexed data in sync 4. Securing your cluster if you want to hit ES directly from the browser/API client 5. Maintaining your cluster
Silota attempts to solve 3, 4, 5. Improving documentation helps with 2.
There’s an e-commerce search example here: http://www.silota.com/docs/api/ecommerce-product-search-exam...
Still, if you have trouble, then yes, try Solr. They have a tutorial that walks you through the full example. Perhaps that will get you going faster.
If you are not picking ES because of a particular feature set, pick on whatever criteria you feel makes it more user-friendly. Whether ElasticSearch or Solr, you are benefiting from Lucene library underneath. I would think twice about any other non-Lucene based search engine at this stage of the search game.
[1] https://github.com/elasticsearch/kibana
[2] https://chrome.google.com/webstore/detail/sense/doinijnbnggo...
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.
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.
"Elasticsearch Server" is another really good book for anyone who's interested. http://www.packtpub.com/elasticsearch-server-for-fast-scalab...
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
Chance some ES stuff might be a touch out of date as Elasticsearch has evolved a lot since this was written.
The momentum/community behind elasticsearch seems to be building rapidly(to get an idea, just follow the "This week in Elasticsearch" posts on http://www.elasticsearch.org/blog).
Having said that, solr have been rock solid for us so we have no real pressing need to switch. Also we dont really have the problem(massive scaling) that elasticsearch seems to be built to handle, we just have 15 mio pageviews or so pr month. Our setup is 1 solr master, and 5 solr slaves(one on each of our 5 webservers). And do nightly dataimports from our SQL server database. That last part is indeed where I think solr currently have a nice advantage over elasticsearch. The solr dataimporthandler is really nice if your primary datastore is a SQL server, and allows you to do all sorts of nifty javascript and other transforms on the data in-flight as you stream it from your SQL server. For elastichsearch there is a jdbc-river thingy that sorta lets you do the same, but it isnt as polished or usable as the solr dataimporthandler(IMO). And if you want to install it you have to do it via a plugin link that points to a bit.ly address.. which makes me feel uneasy.
I also like that solr comes with an admin GUI out of the box. There exist some ES equivalent plugins(mobz/elasticsearch-head), but like with the jdbc river its a thirdparty plugin and I guess you have to trust that it doesnt screw with your server. With solr all you need comes with the distribution, so you dont need to spend mental energy on wether or not you can trust this or that plugin to run on your server.
Also the .NET client for ES seems very polished and more sexy than the solr equivalent.
Anyway my non-scientific gut feeling is that with the current momentum behind ES, it will over time be a better choice than solr. But unless you really need to scale massively, plain old solr is available and works just fine. And seems to me to be somewhat easier to get running than ES(but then again I'm probably biased after having run solr a long time).
I quite like the snake though, think it looks nice
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.
Now if someone could come up with a site with explanations like this (including when it is overkill compared to a basic alternative), that would be really useful. The problem is when you go to the sites homepages, they will tell you how you can do almost everything with the given technology.
Thanks dudes and dudettes.