March 12, 2008 at 4:34 pm
Comments posted to this topic are about the item Scaling Out
March 13, 2008 at 12:13 am
Steve -- love the site. So, it was very clear that MS is working on scale-out for the release after Katmai at minimum; they announced this at PASS. I'm curious as to their architecture.
The problem with Oracle RAC is beyond it's cost, it barely works cause it relies on synchronizing the locks for the shared disk. SQL Server is shared-nothing so they are off to a better start. So Oracle RAC is a scale-out solution for HA if you ask me, not scalability. Oracle experts will tell you that you have to change the application and avoid the load balancer if you want it to scale. I could go on, but just look at some of their benchmarks on the same machines that were clustered and then unclustered and you can see. One of the TPC-H ones come to mind, their TPC-H 10 TBs from a bit ago. Good example since it is the same machine. From 1 64-way to 2 64-ways with RAC they go with 76% scalability (not nice when $10,000 of every $40,000 gets you nothing) and costs were 36% more -- pay more go slower. Nice! OK, so you get I'm anti-Oracle. I'm not anti-Oracle, I'm anti-BS! RAC is an HA solution and quite frankly I think MS MIRROR gives you all the same availability and less complexity (#1 reason for downtime).
Furthermore, note that Oracle RAC only protects you against S/W error; what happens if the disk goes, that high speed switch, and more. You're done. No disaster recovery unless you mix it with Data Guard -- now you're talking mega!
So to me -- scale out is great if you use it for BI. For OLTP, someone show me what SMP can't handle your workload vs all those hundreds of gyrating parts in the blades for HA. Don Burelson (world's leading Oracle expert) agrees! He notes:
"Unless you are one of those shops that have a need in excess of half a million transactions per minute you are probably going to find yourself in a scale up environment."
So I'm going on too long.
One thing about ParAccel. I could be wrong here, but it's column oriented and the one thing wrong with those databases is the insert and updated performance. So when you think about real time BI and such -- the story falls apart. Compare it's disclosure in TPC-H for the queries that have such activity with relational and you'll see what I mean.
Wow, that's a lot of text to say the MS is working on it.
March 13, 2008 at 7:36 am
I don't know anything about Oracle RAC, but I can bet that there are tens of thousands of DBAs who are looking for some kind of technology that would allow straightforward scaling out in SQL Server. In other words, a real "server farm" or some way of adding extra servers to distribute processing load without a lot of complications or risk. Or is there already a way to do this that I should learn?
I guess scaling out is much more difficult for database servers than it is for web servers - is that because of the difficulty in balancing data synchronizations and locking versus performance with regard to databases (whereas web server code doesn't change nearly as often as database data)?
I'm just wondering if someone could explain the current technical obstacles to enabling SQL Server to allow load balancing similar to what is done with web servers (shown in the scaling out GIF in the editorial).
Thanks!
webrunner
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
March 13, 2008 at 7:48 am
Thanks for the notes and I agree with webrunner. Lots of us want to just add a server to distribute load.
Thanks for the RAC notes. I don't know a lot about it other than what I've read in white papers, descriptions, etc. It does seem more like an HA solution to me as well.
ParAccell has changed their focus. They were building a relational architecture a few years ago and then it seemed that they switched to column oriented. When I looked at them a few years ago, it was "add a box" and they had a TDS and TSQL abstract on top of PostgreSQL (I think) to make it look like a SQL Server. They distributed queries among the boxes and any box could query any other. But at the $10-20k per box, it's a niche solution.
April 4, 2008 at 2:52 pm
First full disclosure - I work for xkoto Inc. as Chief Strategy Officer. Regarding scale-out, if you visit http://www.xkoto.com, you can get the low down on how our GRIDSCALE software can scale-out workloads - of course mileage varies with the workload - but with 80/20 read/write splits we have shown over 85% scale across multiple shared-nothing active-active databases. GRIDSCALE also provides continuous availability, keeping data consistent across databases. We are in limited beta now on SQL Server and are targeting mid 2008 for shipping.
April 4, 2008 at 3:31 pm
The issue of scaling out was solved years ago by DEC with VMS clusters and the RDB database (RDB is now owned by Oracle and VMS is owned by HP). RDB can have the same database active on all nodes in a VMS cluster, and this has been the case from when it was first released by DEC in 1984. VMS currently supports 90+ nodes in a cluster, and nodes can be separated by up to 800 kilometers.
If you ask anyone who has ever worked with RDB\VMS, you will hear that they are about as bullet-proof and dependable as software gets. Microsoft has a long way to go to reach that level.
April 4, 2008 at 8:13 pm
Michael Valentine Jones (4/4/2008)
The issue of scaling out was solved years ago by DEC with VMS clusters and the RDB database (RDB is now owned by Oracle and VMS is owned by HP). RDB can have the same database active on all nodes in a VMS cluster, and this has been the case from when it was first released by DEC in 1984. VMS currently supports 90+ nodes in a cluster, and nodes can be separated by up to 800 kilometers.If you ask anyone who has ever worked with RDB\VMS, you will hear that they are about as bullet-proof and dependable as software gets. Microsoft has a long way to go to reach that level.
Heh. As it turns out, I worked for DEC for over 10 years, mostly as a VAX Cluster Performance and Capacity Planning consultant. Small world.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
March 4, 2009 at 8:18 am
Just a small addition for:
"I've heard various answers, but the answer given by one of the panelists, that there hasn't been a widespread adoption of RAC, so why should Microsoft invest in it, is one that I wasn't expecting. It does make sense as SQL Server exists to make money, not necessarily be the best product. If there isn't a large demand, then why do it? "
----------------
Gartner just published an article about that here:
http://mediaproducts.gartner.com/reprints/oracle/article61/article61.html
And BTW 3 out of 3 our recently developed apps (I'm working in a development company mostly developing custom Oracle apps) all were deployed on RAC, one with Enterprise Edition, 2 with Standard Edition. However for SE there is limit 4 CPUs for all cluster so usually it means 2 boxes with 2 CPUs. But the advantage is RAC with SE if for free 🙂
Gints Plivna
http://www.gplivna.eu
March 4, 2009 at 10:02 pm
Thanks for the update. I think scale out is an important thing to do.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply