While I do recognize this is a marketing piece for HyperDex, I'm disappointed HyperDex only chooses to compare itself with MongoDB and Cassandra.<p>It would be different if HyperDex was fully open source and free, but its not. The "transaction" feature is only available with a license, which in most cases will price you out of any developer who is looking to start a bitcoin exchange. So unfortunately it comes across as "If only you had spent $x/mo, buying our product, then you wouldn't have had this problem!"<p>Now that isn't bad, and its the definition of marketing, but then it goes on to compare itself against Cassandra (which has a widely different use case in the wild) and Mongo (which is already the whipping boy of the database community). However it doesn't help the use cases are also extremely well served by something like Postgres, which doesn't need a Warp addon, and has a huge developer community.<p>What I would be more interested in, is how does HyperDex compare with the new "NoSQL" databases (FoundationDB, OrientDB, Spanner-like Databases) or even the traditional commercial SQL like Oracle.<p>In short, it doesn't help to test and compare unsuccessful and unpopular use cases with these technologies. Most competent people, the same people who might pay for HyperDex, already know Cassandra is bad at transactions. What I would like to see is tell me why someone like Netflix, or Ooyala (tried, tested and popular use cases) would move from Cassandra to HyperDex.
<i>That's because banks employ systems that guard against this kind of elementary error. It's called transactions with ACID guarantees.</i><p>Bank systems are often not, in fact, ACID. Think of how many billions of transactions are processed in end-of-the-day batch runs, for example. Overdrafting is not only not impossible, it is a <i>ludicrously profitable feature</i> of the system.<p>How is this secure? Velocity limits, sophisticated anti-fraud systems, acceptable losses, and, as a bit of a by-the-way, the fact that people who make a habit of defrauding banks generally have a few weeks prior to being woken up by very serious men with guns.
The first problem to be had when considering distributed systems is the fact that there is no such thing as a general purpose distributed system.<p>Some problems require doing 50x more reads than writes. Others have more writes than reads. Sometimes losing a few inserts is not a big deal, but a small delay is terrible. Other systems just can't tolerate data loss, and would pay any price to keep it that way. You might have a lot of small pieces of data, searchable in very simple ways, or you might have multi GB documents that require so much indexing than Solr and Elastic seem inadequate.<p>In the old days, you just bought a bigger box for the RDBMS, and you just were covered by knowing one tech. Now we need to go through a wide variety of tools that will rarely do everything you want, and have to write a bunch of code to compensate for the limitations of the tools. And then your DB of choice decides that they will only support their self hosted product, then they get bought by IBM, and you wonder if you'll be forced to retool your entire backend (Hello Cloudant!)<p>Until there is some clarity in the market, and we get to see distributed stacks that are general purpose, we'll see issues like this popping up all the time, as there is a lack of people that both have good knowledge of all the available options and the skill to put them together into something that will solve your specific problem.
Please don't be MongoDB, please don't be MongoDB<p>...<p>Sigh<p>> a failure of distributed systems academics to educate developers and to equip them with clear-thinking frameworks.<p>Here is the thing, distributed systems are not standard academic courses. Just like networking they are often optional. That is really sad and it needs to change.<p>The CAP theorem is not something fringe and exotic anymore it should be standard taught to everyone.<p>MongoDB has really messed up. They promoted and marketed a shitty product wrapped in nice marketing. It created 2 things -- low barrier to entry and a trap. Both wrapped in one nice shiny package. "You should have read the docs to enable actually writing data disk when the user asks them to" doesn't jive with me. A really shitty default setup for something calling itself a database.<p>Oh well, they reaped the benefits of their strategy, both the short term (success) and long term (failure) - it became the butt of jokes and ridicule.
"Historically, Bitcoin exchanges that suffered significant losses turned into fractional reserve banks, only to fold later."<p>That is not what fractional reserve banking is and I wish bitcoin articles would stop misusing the term.
It's the same story over and over again. The young wild guys arrive, full of energy and ambition to make the world a better place. They throw all the ancient stuff overboard because it seems ugly and useless. Then they painfully rediscover why the ugly stuff is there and not useless at all. And after a lot of pain they finally arrive at a slightly improved version of what they threw overboard long ago, at least if they did not surrender before.
TLDR: Exactly what you might have guessed: the exchanges backed their financial operations with a datastore without transactions, tragedy ensues.<p>This can't be viewed as an indictment of "NoSQL" though; there are plenty of databases featuring ACID transactions that qualify as "NoSQL" (FoundationDB and OrientDB come to mind). That said, none of the popular NoSQL contenders have them, and the new guys with transactions tend to be commercial, so if you need transactions in an free and open-source datastore, just use PostgreSQL.
A bit irritated at how the author complains about other databases astroturfing on Hacker News, then writes a glowing post about HyperDex without mentioning that he's one of the authors.<p>That said, I agree with the thesis that current-generation distributed systems provide a terrible API for users who actually want to get concurrency right. I'm optimistic about projects like Summingbird[0] and Bloom[1], which run very high-level declarative programs with simple consistency guarantees.<p>[0] <a href="https://github.com/twitter/summingbird" rel="nofollow">https://github.com/twitter/summingbird</a>
[1] <a href="http://www.bloom-lang.net/" rel="nofollow">http://www.bloom-lang.net/</a>
Its unfortunate to use the ATM example because just such an exploit was used by carders [1] to get more money out of accounts than the accounts actually had.<p>[1] <a href="http://time.com/48344/hackers-target-atms-for-unlimited-withdrawals/" rel="nofollow">http://time.com/48344/hackers-target-atms-for-unlimited-with...</a>
Mongo does have document-level atomic update operators, such as $inc: <a href="http://docs.mongodb.org/manual/reference/operator/update/inc/#up._S_inc" rel="nofollow">http://docs.mongodb.org/manual/reference/operator/update/inc...</a>
Sounds like the author of this 'article' just wanted to make a thinly veiled plug for the "HyperDex" product.<p>Blaming all of this on MongoDB is silly. You can do the kind of idiocy displayed by these exchanges even on generic DBs by doing things like not using transactions and/or not waiting for write confirmation.<p>The root problem is in the (lack of) design and programming of these systems not their data store.
As soon as I saw the term NoSQL and "Brings Down" in the title of the submission, I knew it was going to be MongoDB. Firstly, I don't understand the hatred towards MongoDB. Like most NoSQL datastores, it doesn't offer things like transactions and ACID compliance: this is well-known thing. There are some things that MongoDB does very well, currently I am using it to store clicks for an internal application which then displays those clicks on a page overlay, it handles the task very well. I would never use it for<p>MongoDB is not to blame for bringing down the exchanges that decided to use it, the stupidity of the developers behind said exchanges are the sole reason. You can open up a can of tinned pineapples with an axe, but that doesn't make it the right tool for the job.<p>This post was one big marketing piece for HyperDex and while it is touted as open source, but that isn't entirely true. If you want support for transactions, you have to by a licence. So basically what this post was saying is, "If you spent X amount of money on a HyperDex licence, you wouldn't have had these issues" most people that start these exchanges start them from nothing and probably can't afford or wouldn't warrant spending money on a licence.<p>If you replaced MongoDB with pretty much every other NoSQL database out there, the result would have been the same. Mongo just has a better marketing team behind them in the form of 10Gen getting people to buy into the hype. However, as far as I am aware of, 10Gen aren't telling people to use MongoDB for exchange platforms and anything involving transactions (I could be wrong though). This is a classic case of seeing people talking about how NoSQL is the future and others getting caught up in the hype.<p>If you want a database that you can rely on, especially when dealing with transactions: use something like Postgresql, not MongoDB and or <i>insert over-hyped NoSQL database here</i>
This article lacks a fact base on what actually happened and seems to totally rely on conjecture in order to compare Hyperdex against leading NoSQL solutions.
<i>"They did what anyone would do after reading one too many astroturf articles on Hacker News. Sure, their system failed, but in a sense, the overall system failed them."</i><p>The technology didn't fail them. On the contrary, the technology did exactly what it was supposed to do.
The devs could have (should have) considered these race condition scenarios.
you can put ACID like transactions on top of NoSQL databases, I did it here, but it took a static analyser to help get the logic right:<p><a href="https://github.com/tomlarkworthy/firesafe/wiki/Send-Item" rel="nofollow">https://github.com/tomlarkworthy/firesafe/wiki/Send-Item</a>
Marklogic supports ACID transactions. being that it is also a horizontally scalable system, it allows those transactions not just to spawn multiple objects, but also across multiple hosts.
<a href="http://www.marklogic.com/blog/can-you-pass-the-acid-test/" rel="nofollow">http://www.marklogic.com/blog/can-you-pass-the-acid-test/</a><p>They also support data tiering into HDFS, and now most recently RDF with SPARQL<p>They have been doing ACID for a number of years, not sure for how long.<p>They are not free (unless your data set is small)
Not quite understanding the focus on NoSQL for this use case set. I love MongoDB in the right place and Redis in others. But when you have a bunch of requirements that lend themselves to traditional DBs, choosing MongoDB or HyperDex feels like choosing a tech because it's cool rather than because it is the proper engineering choice.
Cornell CS professor, superb work.<p>See also -- <a href="http://hackingdistributed.com/2014/03/01/what-did-not-happen-at-mtgox/" rel="nofollow">http://hackingdistributed.com/2014/03/01/what-did-not-happen...</a><p>"What may or may not have happened at Mt. Gox"
> It points to a social failure: a failure of distributed systems academics to educate developers and to equip them with clear-thinking frameworks.<p>So, will the OP do an exchange and show us how it's done using his database of and approach of choice. Because writing articles on other's failures is kinda of... Easy.<p>I'm a little sick of this attitude. Nothing personal with - <i>what I thought was Sinan Eren at first, confusing the names after so many years</i> - the OP here, but given the fact that he is deliberately calling out amateurs and <i>poor designers</i> people who (apparently) deserved it, he might very well create a secure bitcoin exchange in the real world, using his technologies.. There is a huge market for that, today more than ever.