It's a little unfortunate that consistency is only mentioned as a footnote. If this is being used internally at Netflix, how are they dealing with consistency issues in the face of failed or conflicting writes?
This currently looks like the Dynamo-alike sharding without the read-repair part making values eventually convergent in all the replicas. This latter feature is much needed, but they are already planning it apparently.
Netflix is a Java-heavy shop (the client talked up in the blog post is the Java client). I was pleasantly surprised to see that dynomite is implemented in C with an eye towards both BSD + Linux. I'm curious if this was because a GC'ed language like Java or Go was tried and proven not up to the task, or what.
My guess would be that the ecosystem in their (seed) target set of databases and protocols is written in C. In one case, they're using Twitters twemproxy to provide connection counts for redis/memcached.
Netflix always makes for an interesting case, but what always strikes me is how incredibly "trivial" their application really is: It's a simple application at a very large scale. This doesn't dismiss their accomplishments, of course, but often it does seem like Netflix spends an enormous engineering effort on fairly low value aspects of the service.
Well, they make it seem trivial, while dealing with every watch and every pause, every rating updating complex recommendation engine algorithms. They deal with licensing and region awareness and proxying by ISP and running their own CDNs and...
And that's the magic.
To boot, they do it at enormous scale on a multitude of platforms all while their own destructive code (Chaos Monkey) runs around destroying servers.
It's true, some things like "stream me this" are maybe not rocket science, but at Netflix scale, everything becomes a bit more difficult.
You're discounting the "very large scale" portion of your statement.
What may seem fairly low value from the outside or consumer perspective is likely of huge value internally to ensure you can always watch Netflix without even thinking about everything that has to happen to deliver as much video as they do to their customer's browsers.
What exactly is trivial about building a complicated multisource streaming video service with sophisticated recommendations (plus all the other "little" stuff like payments)?
Google is "trivial." It's just a box for doing text search on a graph database. Apple is "trivial." They just make pretty skins for commodity hardware & software. Etc.
When you consider 99% of everything in your field trivial, maybe you should consider refining your definition of trivial.
Netflix currently has 94 open engineering open reqs, plus another 22 data/analytics open reqs. Perusing through the list should give you a sense of how complicated their products are: http://jobs.netflix.com/jobs.php
When I saw this internally a few months ago, I said that I haven't been more excited about a new project in a long time. I personally think this will solve a lot of scalability problems people have while letting them keep their favorite database.
Funnily enough Dynomite was also the name of an Erlang implementation (https://github.com/moonpolysoft/dynomite) of Dynamo that seemed to get off to a very promising start before it was abandoned a few years ago.
Cool, it's something that Microsoft SQL Server (Enterprise edition) offers out of the box (Peer-2-Peer replication). The only problem with P2P replication is that, at large scale, requires massive amounts of bandwidth to keep everything synced, and it gets worse the more nodes you add.
Depends how things are replicated. In Dynamo style replication everything isn't replicated everywhere. Based on consistent hashing, and how vnodes etc are configured, a key lands itself in more than one nodes so that things are generally available. So scale-out in a dynamo-like system happens more gracefully.
I don't know if it was intentional but the name reminds me of the character JJ in the TV series Good Times. Awesome show that was. It sounds solid overall but one thing caught my eye, "A client can connect to any node to read the data. Similar to writes, a node serves the read request if it owns the data, otherwise it forwards the read request to the data owning node in the same rack.". I wonder if that could lead to an owning node arbitration storm when more than one node in a rack owns the data?
Also Riak. However, one interesting aspect of Dynomite seems to be offer default support for clustering across multiple data centers with pluggable stores.
Perhaps I missed it, but is there any discussion on how their sharding mechanism works? How do they define a shard and where is ownership of various shards managed so a "non-owning node can redirect to an owning node"?
I questioned tbat as well, could be a property of the underlying store (memcache hash). How would mysql sharding work without being application managed?
It's interesting that Netflix decided to write this rather than using Amazon's own DynamoDB. I wonder specifically if DynamoDB was too expensive (as I have found), or was there some other reason?
This is completely different than DynamoDB. Essentially this is a framework for sharding or horizontally scaling multiple datastores (MySQL, Memcache, Redis, etc).
This is the sort of project you do to get cross-region replication on your existing data stores, many of which look more like PostgreSQL than KV stores.
[+] [-] void_star|11 years ago|reply
[+] [-] antirez|11 years ago|reply
[+] [-] halayli|11 years ago|reply
[+] [-] nteon|11 years ago|reply
[+] [-] viksit|11 years ago|reply
[+] [-] mumrah|11 years ago|reply
[+] [-] padho|11 years ago|reply
[+] [-] personZ|11 years ago|reply
[+] [-] themartorana|11 years ago|reply
And that's the magic.
To boot, they do it at enormous scale on a multitude of platforms all while their own destructive code (Chaos Monkey) runs around destroying servers.
It's true, some things like "stream me this" are maybe not rocket science, but at Netflix scale, everything becomes a bit more difficult.
[+] [-] jrallison|11 years ago|reply
What may seem fairly low value from the outside or consumer perspective is likely of huge value internally to ensure you can always watch Netflix without even thinking about everything that has to happen to deliver as much video as they do to their customer's browsers.
[+] [-] morgante|11 years ago|reply
What exactly is trivial about building a complicated multisource streaming video service with sophisticated recommendations (plus all the other "little" stuff like payments)?
Google is "trivial." It's just a box for doing text search on a graph database. Apple is "trivial." They just make pretty skins for commodity hardware & software. Etc.
When you consider 99% of everything in your field trivial, maybe you should consider refining your definition of trivial.
[+] [-] chaz|11 years ago|reply
[+] [-] jeangenie|11 years ago|reply
[+] [-] brown9-2|11 years ago|reply
[+] [-] jedberg|11 years ago|reply
[+] [-] stefanwild|11 years ago|reply
[+] [-] lobster_johnson|11 years ago|reply
[+] [-] NKCSS|11 years ago|reply
[+] [-] diptanu|11 years ago|reply
[+] [-] ppearcy|11 years ago|reply
Also, I noticed comments about an architecture document here: https://github.com/Netflix/dynomite
Anyone know where the doc they are referencing is located?
[+] [-] jedberg|11 years ago|reply
However, since it is open source, contributions are welcome! :)
[+] [-] diltonm|11 years ago|reply
[+] [-] fizx|11 years ago|reply
[+] [-] anonfunction|11 years ago|reply
[+] [-] wowmsi|11 years ago|reply
[+] [-] RealCasually|11 years ago|reply
[+] [-] marktangotango|11 years ago|reply
[+] [-] jlafon|11 years ago|reply
[+] [-] jetblackio|11 years ago|reply
[+] [-] grogers|11 years ago|reply
DC := AWS region
Rack := AWS AZ
That should tell you that they need multi-region availability, something that DynamoDB will likely never provide.
[+] [-] fizx|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] halayli|11 years ago|reply
https://github.com/Netflix/dynomite/blob/master/src/dyn_dnod...
[+] [-] evantahler|11 years ago|reply
[+] [-] nrbafna|11 years ago|reply
[+] [-] raxen|11 years ago|reply