As someone who is currently building out a distributed storage cluster system, this series has been amazing. Not only are the results informative, but I have learnt so much about clustering, consistency, testing methodology and what to look for when evaluating reliability on these systems. Very nicely done.
Indeed. ElasticSearch is super useful, but its docs used to be of the frustrating variety:
"Explain minute API details, as if a passing note from the lead dev to himself, assuming all context and concepts are understood and obvious. Don't bother with why's & what's & high-level nonsense."<p>It's been improving lately though, "going big" helped ES here.<p>My personal favourite: an issue from 3 years ago, where ElasticSearch returns incorrect facet counts (as in, fundamentally BROKEN faceting). Still unresolved: <a href="https://github.com/elasticsearch/elasticsearch/issues/1305" rel="nofollow">https://github.com/elasticsearch/elasticsearch/issues/1305</a>
TL;DR:<p>"Some people actually advocate using Elasticsearch as a primary data store; I think this is somewhat less than advisable at present."<p>"The good news is that Elasticsearch is a search engine, and you can often afford the loss of search results for a while."<p>My personal favorite solution would reliably channel data from a Riak cluster to an ES cluster. Anyone knows if there is something like that out there?
Aphyr is truly amazing. This series of blog posts has introduced me to a rigorous, careful way of thinking about distributing systems. I'm a much, much better developer for having read his blog. How many people can you really say that about?
I am currently writing a Golang client for Elasticsearch which uses the native binary protocol and I have to say the lack of documentation about it is making the process really painful!<p>I tried to use the Elasticsearch thrift plugin but unfortunately it does not work for the version 1.1 and 1.2<p>So basically I have to inspect each and every byte of each and every request and response in order to be able to send or parse data.<p>While developing the client a managed several time to crash the Elasticsearch server by sending malformed packets. In addition, this, brought me to review the networking part of Elasticsearch code and I think it needs a refactoring and a better, deeper and cleaner usage of Netty.<p>I hope they will soon sort out this and the problems mentioned in the article, since I think that Elasticsearch is really an amazing product!
From the article comments:<p>> seems like the ES team is moving in the right direction with testing this stuff <a href="https://github.com/elasticsearch/elasticsearch/commit/ef759322231b21aa3c8b160f86b895483cff1ebf" rel="nofollow">https://github.com/elasticsearch/elasticsearch/commit/ef7593...</a>
I'm not much of a programmer, but it's great to know about this guy. The diversity link someone posted here [0] is inspiring.<p>Off topic question about Aphyr's website: the stylesheet is linked to only as
`<link rel="stylesheet" type="text/css" href="/css" />`
How and why does this work?<p>[0]<a href="http://aphyr.com/diversity" rel="nofollow">http://aphyr.com/diversity</a>
Can someone explain the "Call me maybe" theme/meme? I know it is a song, but what's the relevance here?<p>Edit: I looked at the archive and found the original post where it is ... erm... explained?
The 'Nic' he quotes in the article is me :) This is seriously the highlight in my career folks!<p>Although to be fair, he quotes me generously. Later on in that discussion I give up my wisdom and get confused again.
Shay says they've already "fixed this" [1] and the aim is to get the fix in 1.3. I'm interested in what the fix actually is.<p>To quote Shay:
"FYI, the improved_zen branch already contains a fix for this issue, we are letting it bake as this is a delicate change, and we are working on adding more test scenarios (aside from the one detailed in this issue) to make sure. The plan is to aim at getting this into 1.3. We have not yet ran Jespen (which simulates the same scenario we already simulate in our test), but we will do it as well."<p>[1]: <a href="https://github.com/elasticsearch/elasticsearch/issues/2488#issuecomment-46135721" rel="nofollow">https://github.com/elasticsearch/elasticsearch/issues/2488#i...</a>
Elasticsearch is great for um... search. Like, you use it as an index to point to the real system of record and it is not expected to be perfect (or shouldn't' be).<p>I though it worked out real well when used to alleviate pressure on the database which was being used for search results (which were sometimes ajax live search style). The big benefit was our database usage went down and search was better/more reliable.<p>The other big benefit is if elastic search goes down search stops working. That is FAR better than if elastic search goes down the whole database and site stops working.<p>At a big enough scale, with thousands of dollars in transactions every day, the database can't go down. Search can break gracefully, but the spice must flow (so to speak).
These problems are a major reason why I decided to not go with the typical 1 cluster-multiple replica infrastructure.<p>Instead I have multiple clusters, 0 replicas, and load balance against those clusters. No split brain problem, but the same data availability benefits as having replicas. Granted, the logic is all in my app now. Now when a cluster is down, I have retry logic to keep reindexing that data to that cluster until it succeeds.
Informative , started looking into ES since past week for indexing , really like the ease of use in ES , but definitely there are few points to be kept in mind.