September 20, 2010 at 9:01 pm
Comments posted to this topic are about the item NoSQL Is Not Everywhere
September 20, 2010 at 10:37 pm
I believe "NoSQL" can be used for "Service-only" offerings (Examples can be application/widgets that simply gather data by crawling across the web and display the same - the WeatherBug and Exchange Rate reference boards for example) that process data, but do not store it.
If they store data it may not be SQLServer or RDBMS (may be just a flat-file), but they will then have some Query language involved in data extraction and loading.
I would say that where data is involved, some query language is also involved.
Thanks & Regards,
Nakul Vachhrajani.
http://nakulvachhrajani.com
Follow me on
Twitter: @sqltwins
September 21, 2010 at 2:09 am
I've done a lot of reading around NoSQL. First of all it stands for Not Only SQL and not NO SQL!
There are a number of NoSQL solutions who claim to be web scalable but when you dig under the covers not so many are. It's worth looking at Simon Munro's blog on the subject. Simon spoke well at the SQL Bits conference in London earlier this year.
The premise of NoSQL is that for applications where data loss is not the end of the world then the overhead of an RDBMS is overkill. They work on the principle of BASE rather than ACID (Basically Available, Soft state, Eventually Consistent).
Quest software are even releasing a version of TOAD that can talk to cloud DBs and some NoSQL contenders.
Where NoSQL is particularly useful is for complex web forms processing where a customer can ping back and forth through the user journey to suit themselves. You really wouldn't want to be trying that with a relational schema as it would require loads of nullable fields and a lot of update statements.
Until the form is completed there is no need to commit the data to an RDBMS. Service interruptions are rare enough that a missed form is not the end of the world. If we committed data into an RDBMS then such service interruptions would result in orphaned data and other data quality issues.
At present the NoSQL solutions I have seen are very much programmers databases rather than everymans databases though TOAD should at least be a step on the right path.
September 21, 2010 at 5:40 am
Steve, if you worked with some of the people I have in my job history you would be disappointed a lot.
The truth is any "great next best think" is only as good as the people who construct it. Classic garbage in garbage out. There are times when the product is poor, but there are many more times when the people are poor.
<><
Livin' down on the cube farm. Left, left, then a right.
September 21, 2010 at 7:57 am
Steve:
As an ex-COBOL analyst and IBM360 JCL writer, I appreciate your final comments in the article. It has been said many, many times that COBOL is old hat and will die....Long live COBOL....even tho I've cut the cord and gone with SQL, VB.Net and many other client server applications and tools in my current labors.
While it is great to be able to use or try new products, there are times when the "cost" of learning a new technology is many times more expensive than doing the same task with aged processes or languages. When was the last time anyone wrote a DOS batch file? For me, about two months ago to handle a remote process on another server. Some technologies will never die.
September 21, 2010 at 8:10 am
When was the last time anyone wrote a DOS batch file?
About 10 minutes ago. I use them quite a bit for tweaking continuous integration and deployment scripts.
September 21, 2010 at 8:40 am
Hi Steve,
On the comment you made about hoping an architect doesn't disclude something because it is new ... we do this all of the time due to risk. You analyze the new-ness of a technology and make the determination (hopefully using a standardized methodology). If it is too far outside your comfort level or provides complexities that timing will not allow, you use a "more trusted" technology.
The Digg video points out that some of their go live issues were with the Cassandra code. It doesn't point out that they came up due to the newness of the technology, but if the system had been implemented in a larger instance or had been stress tested to a higher capacity, it would probably have shown some of the inconsistencies with data corruption. They made a choice in their implementation to be on the bleeding edge and they paid for it with 1000 cuts.
Regards,
Joe
September 21, 2010 at 9:10 am
David.Poole (9/21/2010)
The premise of NoSQL is that for applications where data loss is not the end of the world then the overhead of an RDBMS is overkill. They work on the principle of BASE rather than ACID (Basically Available, Soft state, Eventually Consistent).
I guess it's not the end of the world if a teenage girl's latest facebook post gets lost in the nightly data defrag shuffle (although she'd certainly disagree), but this BASE concept doesn't sound like something the financial, healthcare, or eCommerce industries would find beneficial to their core operations.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 21, 2010 at 9:27 am
To what extent were relational DBMS created because drive space wasn't cheap and processing power was weak? Big, flat tables weren't helpful in either case years ago.
Now I've staked my career on SQL Server, so don't just jump all over me. But I've seen this point brought up elsewhere and wondered how bad it would be to just use flat tables. All the other software may not be dead, but it is bloated! Why not databases too? Summary tables could be created on the side too, which of course helps performance.
Video graphics cards work in a brute force, but kind of a dumb way. But they do work - right?
Someone respectfully prove me wrong. Please. (Because frankly, I'm a little worried.) :w00t:
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
September 21, 2010 at 9:43 am
mtillman-921105 (9/21/2010)
To what extent were relational DBMS created because drive space wasn't cheap and processing power was weak? Big, flat tables weren't helpful in either case years ago.
Perhaps that was some of the driving force, though I think that the ACID properties weren't available in flat files either.
These days we're going back to XML sometimes and that's almost like scanning a flat file in many instances.
Not sure about graphic cards. I know there have been some improvements over time, moving to new algorithms, but not sure about the brute force storing all pixels inside them.
September 21, 2010 at 9:45 am
Joe Johnson-482549 (9/21/2010)
Hi Steve,On the comment you made about hoping an architect doesn't disclude something because it is new ... we do this all of the time due to risk. You analyze the new-ness of a technology and make the determination (hopefully using a standardized methodology). If it is too far outside your comfort level or provides complexities that timing will not allow, you use a "more trusted" technology.
Fair points, Joe, and I would disagree that someone isn't discarding it because it's "new", but because they aren't familiar with it. We discarded MySQL and PostgreSQL for this site early on, even when funds were tight, because we weren't familiar with them and they were still young in 2001. I think that's a valid choice.
September 21, 2010 at 9:52 am
Steve Jones - Editor (9/21/2010)
mtillman-921105 (9/21/2010)
To what extent were relational DBMS created because drive space wasn't cheap and processing power was weak? Big, flat tables weren't helpful in either case years ago.Perhaps that was some of the driving force, though I think that the ACID properties weren't available in flat files either.
These days we're going back to XML sometimes and that's almost like scanning a flat file in many instances.
Not sure about graphic cards. I know there have been some improvements over time, moving to new algorithms, but not sure about the brute force storing all pixels inside them.
At least as far as I know, there is no earth-shaking new technology in video cards. There is parallel processing and running multiple cards at once, but that's really just more processing power. I think the emphasis in that area lately has been more cards, more memory and faster processors.
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
September 21, 2010 at 10:07 am
Actually there is a lot of value in using NoSQL in ecommerce sites.
One of the biggest headaches facing DBAs today is IO. Processing power is cheap, memory is cheap, disk space is cheap but until large, cheap, reliable SSD or better technology becomes available IO is the bottleneck.
NoSQL offers a potential solution so as DBAs we should be embracing the possibilities it offers while scrutinising its use in our role as data professionals.
Lets consider the eCommerce site. We are adding things to a shopping basket, as are many tens of thousands of people, but until we commit to pay for it the world won't stop if there is a hiccup in the shopping basket service. Provided at the point of commit we have full resilience and robustness a NoSQL solution could save a lot of IO.
The reality is that hardware is very reliable and very high uptime achievable so the glitches that a proper RDBMS will handle via 2 phase commit are few and far between. Obviously I wouldn't trust sensitive financial transactions to any existing NoSQL solution but as a tool to act as a transient store NoSQL offers a lot of advantages.
I almost feel that SQL Server should have a NoSQL provision in its storage engine. Being able to define a database in zero recovery mode so the overhead of the 2phase commit is eliminated. SQL Server already uses file based error logging for the SQL Server Agent and MSSQLSERVER service.
Imagine a reindex process where the overhead of TempDB was halved! Obviously the reindex process would have to be sensitive to glitches even if all the reindex process did was abort in the event of a problem.
September 21, 2010 at 10:23 am
David.Poole (9/21/2010)
I've done a lot of reading around NoSQL. First of all it stands for Not Only SQL and not NO SQL!There are a number of NoSQL solutions who claim to be web scalable but when you dig under the covers not so many are. It's worth looking at Simon Munro's blog on the subject. Simon spoke well at the SQL Bits conference in London earlier this year.
The premise of NoSQL is that for applications where data loss is not the end of the world then the overhead of an RDBMS is overkill. They work on the principle of BASE rather than ACID (Basically Available, Soft state, Eventually Consistent).
Quest software are even releasing a version of TOAD that can talk to cloud DBs and some NoSQL contenders.
Where NoSQL is particularly useful is for complex web forms processing where a customer can ping back and forth through the user journey to suit themselves. You really wouldn't want to be trying that with a relational schema as it would require loads of nullable fields and a lot of update statements.
Until the form is completed there is no need to commit the data to an RDBMS. Service interruptions are rare enough that a missed form is not the end of the world. If we committed data into an RDBMS then such service interruptions would result in orphaned data and other data quality issues.
At present the NoSQL solutions I have seen are very much programmers databases rather than everymans databases though TOAD should at least be a step on the right path.
Thanks - that is highly informative.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
September 21, 2010 at 10:47 am
David.Poole (9/21/2010)
I almost feel that SQL Server should have a NoSQL provision in its storage engine. Being able to define a database in zero recovery mode so the overhead of the 2phase commit is eliminated. SQL Server already uses file based error logging for the SQL Server Agent and MSSQLSERVER service.
I agree here. There are lots of places where we don't need 2 phase commit.
Viewing 15 posts - 1 through 15 (of 29 total)
You must be logged in to reply to this topic. Login to reply