"This is it; I'm going to get those plus-twos this time; I can feel it. Patch set 9 is the lucky one!"
"Last week you told me patch set 8 is the lucky one."
"I forgot they're not indexed from zero."
"This is it; I'm going to get those plus-twos this time; I can feel it. Patch set 9 is the lucky one!"
"Last week you told me patch set 8 is the lucky one."
"I forgot they're not indexed from zero."
(cross-posted from the SwiftStack Blog)
In enabling mechanism to combine together general symbols, in successions of unlimited variety and extent, a uniting link is established between the operations of matter and the abstract mental processes of the most abstract branch of mathematical science. A new, a vast, and a powerful language is developed for the future use of analysis, in which to wield its truths so that these may become of more speedy and accurate practical application for the purposes of mankind [sic] than the means hitherto in our possession have rendered possible.
Dear reader, if you're reading [the SwiftStack Blog], you may have already heard that erasure codes have been added to OpenStack Swift (in beta for the 2.3.0 Kilo release, with continuing improvements thereafter) and that this is a really great thing that will make the world a better place.
All of this is entirely true. But what is perhaps less widely heard is exactly what erasure codes are and exactly why their arrival in Swift is a really great thing that will make the world a better place. That is what I aim to show you in this post—and I do mean show, not merely tell, for while integrating erasure codes into a production-grade storage system is (was!) an immense effort requiring months of work by some of the finest programmers the human race has to offer, the core idea is actually simple enough to fit in a (longish) blog post. Indeed, by the end of this post, we will have written a complete working implementation of a simple variant of Reed–Solomon coding, not entirely unlike what is used in Swift itself. No prior knowledge will be assumed except a working knowledge of high-school algebra and the Python programming language.
Our users have a need although
Our budget's rather ...
Thrifty—
Not just, "I want my data," but
"I want my data
Swiftly."
But should their need our budget meet
I'd think it not an oddity,
In an age of open source in which
The hardware's a commodity.
The right solution's quick to get,
No need to hunt or forage;
We'll see our users' needs are met
With open object storage.
Dear reader, suppose you're a distibuted data storage system. Your soul (although some pedants would insist on the word program) is dispersed across a cluster of several networked computers. From time to time, your human patrons give you files, and your job—more than that, the very purpose of your existence—is to store these files for safekeeping and later retrieval.
The humans who originally crafted your soul chose a simple algorithm as the means by which you decide which file goes on which of the many storage devices that live in the computers you inhabit: you find the MD5 hash of the filename, take its residue modulo n where n is the number of devices you have—let's call the result i—and you put the file on the (zero-indexed) ith device. So when you had sixteen devices and the humans wanted you to store twilight.pdf
, you computed md5("twilight.pdf") = 429eb07bb8a3871c431fe03694105883
, saw that the lowest nibble was 3
, and put the file on your 3rd device (most humans would say the fourth device, counting from one).
It's not a bad system, you tell yourself (some sort of pride or loyalty preventing you from disparaging your creators' efforts, even to yourself). At least it keeps the data spread out evenly. (A shudder goes down your internal buses as you contemplate what disasters might have happened if your creators had been even more naive and, say, had you put files with names starting with A through D on the first device, &c. What would have happened that time when your patrons decided they wanted to store beat00001.mp3
through beat18691.mp3
?)