Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NoSQL Meets Bitcoin and Brings Down Two Exchanges

hackingdistributed.com

Post reply on HN
Print view View original

41–50 of 69 posts

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#41

Post by thom_nic »

dhendo wrote: post #20

Mongo does have document-level atomic update operators, such as $inc: http://docs.mongodb.org/manual/reference/operator/update/inc...

Yes this was completely ignored by the article. This along with a 'where' clause can guarantee the operation will only succeed iff there is sufficient funds. I don't know if other NoSQL DBs offer these sort of atomic operators.

Which makes this statement seem particularly unfair: "The problem here stemmed from the broken-by-design interface and semantics offered by MongoDB." He seems to call out Mongo by name a couple times but doesn't say that the exchange was actually using Mongo.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#42

Post by grizzles »

threeseed wrote: post #31
nemothekid wrote: post #4

While I do recognize this is a marketing piece for HyperDex, I'm disappointed HyperDex only chooses to compare itself with MongoDB and Cassandra. 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…

Cassandra's transaction support has been improving pretty rapidly. http://www.datastax.com/dev/blog/lightweight-transactions-in...

For what I can only guess are strategic reasons, Datastax is moving away from the schema-less design that made Cassandra popular with early adopters. There are workarounds to this deprecation such as using the old Thrift API, but it doesn't really inspire confidence in the product unless the new schema oriented way of doing things appeals to you. PS those aren't transactions.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#43

Post by dnmmnd »

jasomill wrote: post #39
edwintorok wrote: post #19

Earlier quoted context omitted.

ATMs aren't as smart as the article says either: "the real code will check to see if there are sufficient funds". I noticed that (some?) ATMs around here tend to implement this flawed algorithm, paraphrasing the article: 0. database.begin() 1. mybalance = database.read("account-number") 2. newbalance = mybalance - amount 3. database.write("account-number", newbalance) 4. database.commit() 5. dispense_cash(amount) At…

Interesting. In one particularly ADHD-inspired case, I've also seen 5. Dispense cash 6. Wait a minute or so 7. Retract cash where 7 did not lead to a credit on my account until several days after I reported the problem to my bank. That's probably by design, however, since otherwise the machine would require automated defenses against surreptitious replacement of dispensed bills with counterfeits. Your example could b…

Quite so. If cash is presented to the customer and then retracted there isn't (or at least wasn't) a way for the ATM to know exactly what had been retracted, i.e. you requested amount X that required the ATM to dispense Y number of notes, but the ATM wouldn't know if the number of retracted notes Z was the same as Y. The ATM would have reported this event to the bank's host and would have been present in the daily transaction log.

As you suggest, a customer initiated account credit is necessary to prevent fraud, and the failure to dispense claim can be verified against the host transaction log.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#44

Post by teacup50 »

grizzles wrote: post #42
threeseed wrote: post #31

Earlier quoted context omitted.

Cassandra's transaction support has been improving pretty rapidly. http://www.datastax.com/dev/blog/lightweight-transactions-in...

For what I can only guess are strategic reasons, Datastax is moving away from the schema-less design that made Cassandra popular with early adopters. There are workarounds to this deprecation such as using the old Thrift API, but it doesn't really inspire confidence in the product unless the new schema oriented way of doing things appeals to you. PS those aren't transactions.

"Schema-less" is a hack that appeals to people that don't realize that there is always schema. It's just a question of whether you want your data model to be ambiguous and poorly defined, or explicit.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#45

Post by nikatwork »

jokoon wrote: post #23

What are the advantages of nosql btw ?

NoSQL is fantastic for backing item-orientated webapps, it removes the transactional and relational overheads. Conversely I would not use NoSQL for anything concerning FIRE or complex inter-related data - those safeguards become important.

Scalability is something of a red herring with NoSQL. Yes it's easier to scale, but my primary criteria for choosing it would be the nature of the data, not the intended scale.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#46

Post by nevi-me »

Alex3917 wrote: post #35
pron wrote: post #17

Earlier quoted context omitted.

If I'm not mistaken, an eventually consistent database must also guarantee, well, eventual consistency.

The problem is that eventual consistency doesn't mean eventual correctness. The basic issue is that math usually only works if you do it in the correct order, e.g. (X+2) 5 != (X 5)+2. And if you're using a document store to do mathematical transactions then you're not guaranteed that they execute in the correct order, all that you're guaranteed is that all the nodes will eventually be the same in your database.

But debits and credits do not use multiplication nor division, so for those transactions the order doesn't matter.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#47

Post by DigitalSea »

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

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.

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.

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.

If you want a database that you can rely on, especially when dealing with transactions: use something like Postgresql, not MongoDB and or insert over-hyped NoSQL database here

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#48

Post by nevi-me »

teacup50 wrote: post #44
grizzles wrote: post #42

Earlier quoted context omitted.

For what I can only guess are strategic reasons, Datastax is moving away from the schema-less design that made Cassandra popular with early adopters. There are workarounds to this deprecation such as using the old Thrift API, but it doesn't really inspire confidence in the product unless the new schema oriented way of doing things appeals to you. PS those aren't transactions.

"Schema-less" is a hack that appeals to people that don't realize that there is always schema. It's just a question of whether you want your data model to be ambiguous and poorly defined, or explicit.

Schema-less also means that you can afford to have deviations in your schemas not hinder your development needs. I agree with you, but I'd venture to say that a schema-less database means what it does, but that a collection of data always has schemas.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#49

Post by Consultant32452 »

jokoon wrote: post #23

What are the advantages of nosql btw ?

A more "use-case" example than your other responses.. I believe Amazon uses a NoSQL database for their product data. It's tons of reads and relatively few writes. They don't give a crap about transaction quality for product descriptions, comments, etc. However, when you get to the checkout page and they start doing things like taking your money and updating their inventory... that's and ACID compliant database. When you're dealing with money you want transactions, rollbacks, etc.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#50

Post by iamaleksey »

grizzles wrote: post #42
threeseed wrote: post #31

Earlier quoted context omitted.

Cassandra's transaction support has been improving pretty rapidly. http://www.datastax.com/dev/blog/lightweight-transactions-in...

For what I can only guess are strategic reasons, Datastax is moving away from the schema-less design that made Cassandra popular with early adopters. There are workarounds to this deprecation such as using the old Thrift API, but it doesn't really inspire confidence in the product unless the new schema oriented way of doing things appeals to you. PS those aren't transactions.

This is not true. See this for example: http://www.datastax.com/dev/blog/thrift-to-cql3

You can do CREATE TABLE schemaless (id blob, name blob, value blob, PRIMARY KEY (id, name)) WITH COMPACT STORAGE; and have a 'schemaless' table, essenitally, just as with Thrift.

This is not a workaround either - this is first-class supported, just as you can read/write from/to 'schemaless' thrift columnfamilies using CQL.

Post reply on HN