• patrickmcginnis59 10839 (5/13/2014)


    Gary Varga (5/13/2014)


    Steve Jones - SSC Editor (5/12/2014)


    Gary Varga (5/12/2014)


    There are but have been deemed too expensive and unnecessary for what NOSQL was originally intended for. Basically, it is a big misunderstanding with the people applying NOSQL paying too much attention to marketing and not enough to technical documentation.

    It's not that they are too expensive or unnecessary, though that may be the decision at times.

    It's that there is no way to do it at scale. If you get the volume of data that a Facebook or Twitter, or Google get, there is no way to get those machines in sync, physically. The laws of physics would be challenged, even if you were writing that data to memory.

    When NoSQL says eventually consistent, it's not that they mean the data won't be the same until tomorrow, or an hour from now. They mean that not this ms. In practice, the consistency often is there sub-second, though it can be minutes when loads are high. It's the same with Service Broker. It doesn't make transactions instantaneous, but often it's so close that it might as well be instantaneous, in a practical sense, for most applications.

    I agree but with regards to "for most applications" is where the professionals should know the difference. Clearly they did not at the BitCoin exchange that got ripped off.

    MtGox's failures didn't involve what database technology they used. There was a documented shortcoming in the bitcoin protocol that the company ignored. When they cashed out bitcoins, their erroneous use of the protocol meant that in certain cases, they cashed them out more than once. Essentially the txid (transaction id) is able to be modified by third parties, but MtGox didn't allow for this despite being a known issue since 2011, they instead relied on it to actually be immutable and trustyworthy. Developers were told not to rely on this but MtGox did and they got caught out by it.

    This mistake could have been made using sql server for all that matters.

    ...When they cashed out bitcoins, their erroneous use of the protocol meant that in certain cases, they cashed them out more than once...

    I know next to nothing about the technical implementation or bitcoin or even how it work conceptually, but relational databases typically use unique key constraints to prevent events like "cashing out the same bitcoin twice". Each bitcoin should have a unique id, and a table inserted with one row when it is debited for cash.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho