SQLServerCentral.com / Editorials / SQLServerCentral.com / No Handwaving Away the DBA / Latest PostsInstantForum.NET v2.9.0SQLServerCentral.comhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comTue, 03 Mar 2015 13:33:32 GMT20RE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspxpatrickmcginnis59 wrote:[i]... other than the mutable transaction id, bitcoin as such doesn't seem to be broken.[/i]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'.Tue, 13 May 2014 09:47:41 GMTGoofyGuyRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote][b]Gary Varga (5/13/2014)[/b][hr][quote][b]Eric M Russell (5/13/2014)[/b][hr][quote][b]patrickmcginnis59 10839 (5/13/2014)[/b][hr][quote]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.[/quote]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.)[/quote]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?[/quote]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.[/quote]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.Tue, 13 May 2014 09:26:20 GMTpatrickmcginnis59 10839RE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote][b]Eric M Russell (5/13/2014)[/b][hr][quote][b]patrickmcginnis59 10839 (5/13/2014)[/b][hr][quote]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.[/quote]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.)[/quote]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?[/quote]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.Tue, 13 May 2014 08:35:03 GMTGary VargaRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote][b]patrickmcginnis59 10839 (5/13/2014)[/b][hr][quote]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.[/quote]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.)[/quote]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?Tue, 13 May 2014 08:21:13 GMTEric M RussellRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote]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.[/quote]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.)Tue, 13 May 2014 08:11:57 GMTpatrickmcginnis59 10839RE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote][b]patrickmcginnis59 10839 (5/13/2014)[/b][hr][quote][b]Gary Varga (5/13/2014)[/b][hr][quote][b]Steve Jones - SSC Editor (5/12/2014)[/b][hr][quote][b]Gary Varga (5/12/2014)[/b][hr]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.[/quote]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.[/quote]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.[/quote]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. [/quote][quote]...When they cashed out bitcoins, their erroneous use of the protocol meant that in certain cases, they cashed them out more than once...[/quote] 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.Tue, 13 May 2014 07:46:46 GMTEric M RussellRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote][b]patrickmcginnis59 10839 (5/13/2014)[/b][hr][quote][b]Gary Varga (5/13/2014)[/b][hr][quote][b]Steve Jones - SSC Editor (5/12/2014)[/b][hr][quote][b]Gary Varga (5/12/2014)[/b][hr]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.[/quote]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.[/quote]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.[/quote]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. [/quote]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.Tue, 13 May 2014 07:19:05 GMTGary VargaRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote][b]Gary Varga (5/13/2014)[/b][hr][quote][b]Steve Jones - SSC Editor (5/12/2014)[/b][hr][quote][b]Gary Varga (5/12/2014)[/b][hr]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.[/quote]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.[/quote]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.[/quote]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. Tue, 13 May 2014 06:38:36 GMTpatrickmcginnis59 10839RE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote][b]Steve Jones - SSC Editor (5/12/2014)[/b][hr][quote][b]Gary Varga (5/12/2014)[/b][hr]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.[/quote]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.[/quote]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.Tue, 13 May 2014 01:40:07 GMTGary VargaRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote][b]Gary Varga (5/12/2014)[/b][hr]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.[/quote]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.Mon, 12 May 2014 10:58:09 GMTSteve Jones - SSC EditorRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote][b]patrickmcginnis59 10839 (5/12/2014)[/b][hr][quote][b]David.Poole (5/9/2014)[/b][hr][quote]Whats wrong with eventual consistency? Its not designed to be a drop in replacement for the 'C' in ACID right? Its more like the 'C' in CAP from what I remember.[/quote]It seems that the "eventual" thing is a bit unreliable. It isn't guaranteed and people have started to notice.[/quote]Are you trying to say that there is no algorithm available today to get the differences in any given list of data shared between two computers connected by a wire?[/quote]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.Mon, 12 May 2014 07:04:02 GMTGary VargaRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote][b]David.Poole (5/9/2014)[/b][hr][quote]Whats wrong with eventual consistency? Its not designed to be a drop in replacement for the 'C' in ACID right? Its more like the 'C' in CAP from what I remember.[/quote]It seems that the "eventual" thing is a bit unreliable. It isn't guaranteed and people have started to notice.[/quote]Are you trying to say that there is no algorithm available today to get the differences in any given list of data shared between two computers connected by a wire?Mon, 12 May 2014 06:52:37 GMTpatrickmcginnis59 10839RE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote][b]Gary Varga (5/9/2014)[/b][hr][quote][b]David.Poole (5/9/2014)[/b][hr][quote]Whats wrong with eventual consistency? Its not designed to be a drop in replacement for the 'C' in ACID right? Its more like the 'C' in CAP from what I remember.[/quote]It seems that the "eventual" thing is a bit unreliable. It isn't guaranteed and people have started to notice.[/quote]I am sure it is not what you meant but it sounds like how most people think. It isn't unreliable in the sense of being defective but it is non-transactional and doesn't have the same levels of repeatability.[/quote]Except that's an impression. It often is as fast and reliable as most other RDBMSes. Most of us don't work in high transaction environments, and the ability to scale out cheaply, even at relatively low workloads, is interesting.It's similar to what Azure is doing with the PaaS stuff. Trying to get people to think smaller databases, that are ACID compliant internally, but rollups, reports, aggregates across your shards are not necessarily consistent. Fascinating stuff.Sat, 10 May 2014 10:20:07 GMTSteve Jones - SSC EditorRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote][b]David.Poole (5/9/2014)[/b][hr][quote]Whats wrong with eventual consistency? Its not designed to be a drop in replacement for the 'C' in ACID right? Its more like the 'C' in CAP from what I remember.[/quote]It seems that the "eventual" thing is a bit unreliable. It isn't guaranteed and people have started to notice.[/quote]I am sure it is not what you meant but it sounds like how most people think. It isn't unreliable in the sense of being defective but it is non-transactional and doesn't have the same levels of repeatability.Fri, 09 May 2014 14:35:44 GMTGary VargaRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote][b]patrickmcginnis59 10839 (5/9/2014)[/b][hr][quote][b]David.Poole (5/8/2014)[/b][hr]Google the "Hype Cycle".NOSQL is such a broad term that it is next to meaningless.Not all NOSQL solutions deliver "No single point of failure".BASE has made people realise how much they miss ACID. Eventually consistent doesn't really work.[/quote]Whats wrong with eventual consistency? Its not designed to be a drop in replacement for the 'C' in ACID right? Its more like the 'C' in CAP from what I remember.[/quote]As usual, the problem is not in the designed functionality but the assumed characteristics. A perfect example being the BitCoin theft from the exchange that got ripped off recently. The balance was not consistent after each withdrawal which allowed multiple withdrawals of the balance which eventually became consistent to a debt e.g. with a balance of $100 you can withdraw $100 and with eventual consistency you might be able to repeat this 10,001 times before it becomes consistent thereby creating a balance of -$1,000,000 so with an outlay of $100 you have made one million dollars clear.Nice.The problem was not with the database but with the assumed characteristics. The coder, whether they knew it or not, were relying on nonexistent ACID properties.Fri, 09 May 2014 14:29:51 GMTGary VargaRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote]Whats wrong with eventual consistency? Its not designed to be a drop in replacement for the 'C' in ACID right? Its more like the 'C' in CAP from what I remember.[/quote]It seems that the "eventual" thing is a bit unreliable. It isn't guaranteed and people have started to notice.Fri, 09 May 2014 14:23:40 GMTDavid.PooleRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote][b]David.Poole (5/8/2014)[/b][hr]Google the "Hype Cycle".NOSQL is such a broad term that it is next to meaningless.Not all NOSQL solutions deliver "No single point of failure".BASE has made people realise how much they miss ACID. Eventually consistent doesn't really work.[/quote]Whats wrong with eventual consistency? Its not designed to be a drop in replacement for the 'C' in ACID right? Its more like the 'C' in CAP from what I remember.Fri, 09 May 2014 13:54:14 GMTpatrickmcginnis59 10839RE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspxAs for the article, the reference to the Oracle DBA was interesting. Every Oracle person I have met seems to suffer from an inferiority complex. When I mention I focus on the Microsoft BI stack, it is always how Oracle is so much better. Ok, if it was common knowledge that it was so much better, why do all of them feel like they need to defend it? Sorry, just ranting. Or are they still lost in the cursor world?Fri, 09 May 2014 10:13:47 GMTAndrew..PetersonRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspxI look at all of these as tools. And as a mechanic, a new tools may work in specialized ways, but I do not get rid of all my old tools. Hadoop/NOSQL/Cassandra, etc have specialized uses. Hadoop is great for loading all that unorganized data, unstructured data first, and then adding organization. But SQL is simple, efficient and great.Fri, 09 May 2014 10:06:30 GMTAndrew..PetersonRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspxGoogle the "Hype Cycle".NOSQL is such a broad term that it is next to meaningless.Not all NOSQL solutions deliver "No single point of failure".BASE has made people realise how much they miss ACID. Eventually consistent doesn't really work.These systems emerged to satisfy a niche for companies operating at the bleeding edge. The inventors of the solutions were pretty clear on the use cases for what they had invented. They understood that NOSQL meant Not Only SQL and for the most part it seems that the systems were produced by craftsmen who needed a craftsmans tools.What appears to have happened is that journeymen think they need craftsmans tools and are building wobbly systems with them.Of all the NOSQL solutions I see graph databases as making the most sustained inroads into the space of the traditional RDBMS. I had a lot of fun with Neo4J. I genuinely do mean fun, no irony or sarcasm involved. Microsoft have a number of articles on their graph database code named [url=http://research.microsoft.com/en-us/projects/trinity/documents.aspx]Trinity[/url].REDIS is a great key-value pair in-memory solution for web session management and anything transient.I can see from a developer perspective why document stores are currently popular. From an operational perspective I'm sceptical. For MongoDB I'd be looking at [url=http://www.tokutek.com/products/tokumx-for-mongodb/]TokuMX [/url]as a replacement engine. As Mongo doesn't have a shared nothing architecture I'd probably look at Couchbase instead.RIAK is interesting, especially as it follows the Amazon Dynamo white paper. It's really worth reading the Amazon paper. It'll take you a few attempts to digest it but is worth it in the end. In a lot of cases front-end web development simply wants to retrieve an object by a key value and if that is all you want to do then virtually all the NOSQL solutions fulfill that brilliantly.Cassandra is one I keep looking at but am not sure I've fully grasped its potential.Hadoop has a large ecosystem and there is a huge amount of investment in it. I liked the idea of HIVE which effectively lets you use the MySQL dialect of SQL to query structured data in Hadoop.I believe that Stinger has the same design goals as Impala in terms of adding real-time SQL querying of the Hadoop core.The big challenge faced by data professionals is to identify the stuff that is merely a fad and the stuff that really will continue to engage after the fruit-fly attention span of early adopters has got bored with it.Thu, 08 May 2014 15:17:18 GMTDavid.PooleRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspxIt seems to me that Microsoft's increasingly aggressive licensing costs for SQL Server 2012 and, worse, 2014, are hastening the impetus to look at alternatives even among relational db vendors. It seems that the price was too good, the performance too predictable, and the operational support far too mature for too long. Now company executives are balking with sticker shock and looking for a place to hide while mourning their budgets. As a data architect, I feel Microsoft is nudging the bayonet in the backs of companies who walk the plank towards Open Source relational and non-relational stores. Good, bad, or indifferent, they will turn this migration into a stampede.Thu, 08 May 2014 11:05:25 GMTlsmith1437RE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[i]"...if you think that switching to NoSQL will just let you hand-wave away all of the challenges of running a database, you are terribly misguided." [/i]But it seems increasingly there is the [i]effect [/i](if not necessarily the conscious [i]effort[/i]) to 'hand-wave away the DBA' -- by moving to cloud-based SaaS, and by consuming web services (rather than making direct database calls) within Ajax-type applications.Without a doubt, competent DBAs will always be needed -- but the direct exposure developers have to them will likely decrease because of the evolution of application design and infrastructure.Thu, 08 May 2014 09:38:06 GMTGoofyGuyRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspxI remember when fellow grad students (in 1993) looked down at me because I was focusing on RDBMS's, while they were all gaga for Object-Oriented DBMS's. Relational systems were so old school. The future was all OO, and I was wasting my time, they said.Still waiting for something that is truly better. Meanwhile, I'm very happy to work in a relational, SQL world.Thu, 08 May 2014 09:11:56 GMTThomas AbrahamRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote][b]Eric M Russell (5/8/2014)[/b][hr][quote]In some sense the DevOps movement is built around merging these two frames of reference into the minds of all those involved. I hope that movement continues to grow and mature, and we learn that developers and operational staff are both necessary, and both need to function in a symbiotic, harmonious fashion.[/quote] Oh, I'm sure that for many of us, development and operations are of the same mind and have a very symbiotic relationship to each other. The developer side of my mind has a conversation with operations while driving into work, and then operations has plenty to say back and the end of the day. Now if only I keep both sides in harmony. :-)[/quote]I found that list to be a load of hot air e.g. Easier maintainability, administration and operations.Try maintaining a NoSQL database for a bitcoins exchange :-PThu, 08 May 2014 08:14:58 GMTGary VargaRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspxObviously running ad-hoc queries against unstructured data is a use case for a NoSQL database, and MongoDB is good for that. This would include things like ecommerce shopping carts and other memcache type data. However, once the user clicks the final purchase button, then you want your order entry and fullfillment system running SQL Server. There are also cases where very large raw files are injested from external sources, but only some columns and a much smaller subset of records are operationally useful and worthy for ETL into a normalized relational database. However, there may still be a need to retain a complete history of all these files in some online queryable fashion for archival or exploratory purposes. The DBA would prefer not to use SQL Server as a dumping ground for that type of thing. So, Hadoop to the rescue. So, yes, are occasions where it's very useful to dump things on NoSQL. Find space for it on the rack and put it to work.Thu, 08 May 2014 08:12:40 GMTEric M RussellRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote]I do think NoSQL has a place in the world. There are domains of problems that I'm sure Riak, MongoDB, and others, solve in a more efficient way than SQL Server, Oracle, MySQL, and other relational systems. I'm not sure what they are, and to some extent, I haven't seen good guidance on where particular platforms excel.[/quote]This might be a nice start:[url=http://readwrite.com/2011/02/03/the-big-list-of-nosql-use-case/]http://readwrite.com/2011/02/03/the-big-list-of-nosql-use-case[/url]One case I personally like that calls for a non-sql solution is a need for fast RBAR. With SQL Server, you either get pokey single row selects, inserts and updates, or nice and fast set oriented operations. What about fast RBAR?I do hold out hope that SQL Server 2014 might address this.Thu, 08 May 2014 07:55:08 GMTpatrickmcginnis59 10839RE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote]In some sense the DevOps movement is built around merging these two frames of reference into the minds of all those involved. I hope that movement continues to grow and mature, and we learn that developers and operational staff are both necessary, and both need to function in a symbiotic, harmonious fashion.[/quote] Oh, I'm sure that for many of us, development and operations are of the same mind and have a very symbiotic relationship to each other. The developer side of my mind has a conversation with operations while driving into work, and then operations has plenty to say back and the end of the day. Now if only I keep both sides in harmony. :-)Thu, 08 May 2014 07:37:37 GMTEric M RussellRE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspx[quote][b]Gary Varga (5/8/2014)[/b][hr]....but that many of the implementers on the ground have conveniently forgotten or avoided reading the small print. .....[/quote]Remember when companies were downsizing because a guru said so. Apparently, that guru said "[b]Some[/b] companies need to downsize". Cant see the industry based on logic falling for the same style of mistake....There are also a number of people who will jump onto a NOSql bandwagon thinking that it means NoSQL ( Not Only SQL vs No SQL ). There will be enough companies out there that will go through the pain, until the next greatest thing is suggested.Thu, 08 May 2014 05:31:36 GMTYet Another DBARE: No Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspxAt the moment there appears to be a number of schools of thought that are being misappropriated and misapplied in ways which are suggesting that important roles and duties are not going to be performed properly. Along with NoSQL, agile is one of these.Steve, you highlighted the NoSQL movement encouraging a "no DBA" duties/roles and agile can be misapplied to remove architecting, documentation, all testing but unit testing etc as well as attempting to circumvent DBAs.I know that the leaders of these movements believe that this not the right way to go but that many of the implementers on the ground have conveniently forgotten or avoided reading the small print. It is up to all of us to remain strong and speak up.Thu, 08 May 2014 02:10:45 GMTGary VargaNo Handwaving Away the DBAhttp://www.sqlservercentral.com/Forums/Topic1568748-263-1.aspxComments posted to this topic are about the item [B]<A HREF="/articles/Editorial/110274/">No Handwaving Away the DBA</A>[/B]Wed, 07 May 2014 20:30:42 GMTSteve Jones - SSC Editor