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»»

NoSQL Is Not Everywhere Expand / Collapse
Author
Message
Posted Tuesday, September 21, 2010 9:45 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 4:13 PM
Points: 31,214, Visits: 15,660
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.








Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #990466
Posted Tuesday, September 21, 2010 9:52 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Monday, July 14, 2014 10:08 AM
Points: 598, Visits: 3,816
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
Post #990471
Posted Tuesday, September 21, 2010 10:07 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Wednesday, October 29, 2014 2:31 AM
Points: 2,909, Visits: 1,837
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.



LinkedIn Profile
Newbie on www.simple-talk.com
Post #990494
Posted Tuesday, September 21, 2010 10:23 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Yesterday @ 1:58 PM
Points: 17,854, Visits: 15,803
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
Post #990518
Posted Tuesday, September 21, 2010 10:47 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 4:13 PM
Points: 31,214, Visits: 15,660
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.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #990545
Posted Tuesday, September 21, 2010 10:54 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 10:18 AM
Points: 1,720, Visits: 4,879
Steve Jones - Editor (9/21/2010)

... 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.

For this site? Had word got out that SQLServerCentral.com was powered by MySQL, then Sun Micro would have had a field day.
Post #990553
Posted Tuesday, September 21, 2010 11:00 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 10:18 AM
Points: 1,720, Visits: 4,879
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.
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.)

I've still got a shrink wrapped copy of FoxPro 2.6 for DOS, if you're willing to trade for a SQL Server 2008 Enterprise license.
Post #990561
Posted Tuesday, September 21, 2010 11:33 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Monday, July 14, 2014 10:08 AM
Points: 598, Visits: 3,816
Eric Russell 13013 (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.
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.)

I've still got a shrink wrapped copy of FoxPro 2.6 for DOS, if you're willing to trade for a SQL Server 2008 Enterprise license.


That is funny, but FoxPro was relational believe it or not. (I was a FoxPro programmer and have actually worked with that version.) In fact, I think that even dBase III+ was relational, for that matter.



______________________________________________________________________
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
Post #990596
Posted Tuesday, September 21, 2010 11:36 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 4:13 PM
Points: 31,214, Visits: 15,660
We did worry about the rep of this site using MySQL, and used that to negotiate a better license from MS at one point.






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #990600
Posted Tuesday, September 21, 2010 11:58 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, June 3, 2014 8:16 AM
Points: 295, Visits: 1,011
NOSql is an interesting platform.

I personally hope that one day, somehow, nosql would be usable in the common rdbms platforms. That could be interesting.
Post #990628
« Prev Topic | Next Topic »

Add to briefcase ««123»»

Permissions Expand / Collapse