Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««123

No Handwaving Away the DBA Expand / Collapse
Author
Message
Posted Monday, May 12, 2014 10:58 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 4:15 PM
Points: 31,210, Visits: 15,654
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.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1569986
Posted Tuesday, May 13, 2014 1:40 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 12:35 PM
Points: 5,636, Visits: 3,516
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.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1570165
Posted Tuesday, May 13, 2014 6:38 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Today @ 8:16 AM
Points: 363, Visits: 2,541
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.
Post #1570262
Posted Tuesday, May 13, 2014 7:19 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 12:35 PM
Points: 5,636, Visits: 3,516
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.


Agghhhh. Grey sources!!! I must find the article that blamed NoSQL. Either it is wrong and needs highlighting or it is right and I should let you know. I am now assuming that it is wrong.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1570284
Posted Tuesday, May 13, 2014 7:46 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 2:34 PM
Points: 1,716, Visits: 4,872
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.
Post #1570316
Posted Tuesday, May 13, 2014 8:11 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Today @ 8:16 AM
Points: 363, Visits: 2,541

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.

You do at least know that there is no centralized database for bitcoins right? (Reading your comment, it seems this might not be the case, I keep reading folks who think that bitcoin has some sort of "bank" or federal reserve or something issuing them.)

Post #1570345
Posted Tuesday, May 13, 2014 8:21 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 2:34 PM
Points: 1,716, Visits: 4,872
patrickmcginnis59 10839 (5/13/2014)

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.

You do at least know that there is no centralized database for bitcoins right? (Reading your comment, it seems this might not be the case, I keep reading folks who think that bitcoin has some sort of "bank" or federal reserve or something issuing them.)

Yes, I know at least that much about bitcoin, but the distributed nature of the architecture doesn't necessarily excuse the same coin from being cashed out twice. There is latency when it comes to distributed transactions, but did both cash out transactions occur within MtGox's own node?
Post #1570356
Posted Tuesday, May 13, 2014 8:35 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 12:35 PM
Points: 5,636, Visits: 3,516
Eric M Russell (5/13/2014)
patrickmcginnis59 10839 (5/13/2014)

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.

You do at least know that there is no centralized database for bitcoins right? (Reading your comment, it seems this might not be the case, I keep reading folks who think that bitcoin has some sort of "bank" or federal reserve or something issuing them.)

Yes, I know at least that much about bitcoin, but the distributed nature of the architecture doesn't necessarily excuse the same coin from being cashed out twice. There is latency when it comes to distributed transactions, but did both cash out transactions occur within MtGox's own node?


Yes. Same node. It was supposedly repeats of the same transaction. A quick search online provides plenty of evidence that suggests that in the public domain no one can be certain what occurred.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1570367
Posted Tuesday, May 13, 2014 9:26 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Today @ 8:16 AM
Points: 363, Visits: 2,541
Gary Varga (5/13/2014)
Eric M Russell (5/13/2014)
patrickmcginnis59 10839 (5/13/2014)

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.

You do at least know that there is no centralized database for bitcoins right? (Reading your comment, it seems this might not be the case, I keep reading folks who think that bitcoin has some sort of "bank" or federal reserve or something issuing them.)

Yes, I know at least that much about bitcoin, but the distributed nature of the architecture doesn't necessarily excuse the same coin from being cashed out twice. There is latency when it comes to distributed transactions, but did both cash out transactions occur within MtGox's own node?


Yes. Same node. It was supposedly repeats of the same transaction. A quick search online provides plenty of evidence that suggests that in the public domain no one can be certain what occurred.


The reason they were able to be repeated is because of the transaction id getting changed by a third party, and it subsequently looks like a different transaction because MtGox based their system on interpreting it like such, despite it being advised not to do so. This was on the same node, and nosql doesn't seem to have much to do with it, because only one database node is required for this bug to take place, and furthermore, MtGox is (was) an exchange, not an issuer of bitcoin, the actual issuing of bitcoin is through the distributed block chain. Obviously we don't even know this for sure, but other than the mutable transaction id, bitcoin as such doesn't seem to be broken.
Post #1570419
Posted Tuesday, May 13, 2014 9:47 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Today @ 6:09 PM
Points: 221, Visits: 631
patrickmcginnis59 wrote:

... other than the mutable transaction id, bitcoin as such doesn't seem to be broken.

Perhaps not in the technical sense, but it is still is subject to the restrictions placed upon it by national governments, which may decide bitcoins are not convertible into the national currency, or (in the case of Silk Road) may shut down entire marketplaces which use bitcoins as an exchange mechanism.

Something tells me technical issues will be the least problem standing in the way of bitcoin's general acceptance as a 'currency'.
Post #1570430
« Prev Topic | Next Topic »

Add to briefcase «««123

Permissions Expand / Collapse