Microsoft SQL Server 2012 and enterprise database choices in general
Microsoft is launching SQL Server 2012 on March 7. An IM chat with a reporter resulted, and went something like this.
Reporter: [Care to comment]?
CAM: SQL Server is an adequate product if you don’t mind being locked into the Microsoft stack. For example, the ColumnStore feature is very partial, given that it can’t be updated; but Oracle doesn’t have columnar storage at all.
Reporter: Is the lock-in overall worse than IBM DB2, Oracle?
CAM: Microsoft locks you into an operating system, so yes.
Reporter: Is this release something larger Oracle or IBM shops could consider as a lower-cost alternative a co-habitation scenario, in the event they’re mulling whether to buy more Oracle or IBM licenses?
CAM: If they have a strong Microsoft-stack investment already, sure. Otherwise, why?
Reporter: [How about] just cost?
CAM: DB2 works just as well to keep Oracle honest as SQL Server does, and without a major operating system commitment. For analytic databases you want an analytic DBMS or appliance anyway.
Best is to have one major vendor of OTLP/general-purpose DBMS, a web DBMS, a DBMS for disposable projects (that may be the same as one of the first two), plus however many different analytic data stores you need to get the job done.
By “web DBMS” I mean MySQL, NewSQL, or NoSQL. Actually, you might need more than one product in that area.
Comments
9 Responses to “Microsoft SQL Server 2012 and enterprise database choices in general”
Leave a Reply
Do you know why Oracle doesn’t support columnar storage?
Presumably they’ve tried and to date failed.
Is it a feature of Exadata, or is that more of a compression technique?
As per http://www.dbms2.com/2011/02/06/columnar-compression-database-storage/, the latter.
I imagine that Microsoft’s decision to implement columnar indexes as a read-only structure derive from how they envisage the loading process to work for large loads:
Creation of a partition for the load in question, followed by a high-speed load using the underlying bulk-insert API into a heap table (permitting concurrent bulk-inserts) followed by the creation of the columnar indexes.
Using such a strategy, it is possible to get over one million rows/second into the database. The big question is how quickly can the columnar indexes be created?
From the day I first heard about Vertica, the story included “Of course, updating a columnar DBMS is a challenge; here’s our approach to dealing with it.”
If a DBMS can’t handle at least:
* Low volume random updates
* High volume micro-batch updates
it doesn’t deserve to be taken seriously.
The industry-standard lag time for micro-batches used to be in the “a few minutes” range, but I suspect it’s coming down.
This article neglects the cost common reason people in an Oracle shop purchase MS SQL Server. BI.
Microsoft bundles a large quantity of “good enough” BI software with SQL Server, as well as a great integration stack (and I say stack – Service Broker for real time queues, SSIS for batch integration, Sync Framework for mobile integration)
PowerView visualisation in SQL 2012 expands this dramatically, albeit with a dependency on Sharepoint.
The two most common reasons I have implemented SQL Server in an Oracle shop (disclaimer: I run a SQL server implementation shop):
OLTP runs in Oracle, data warehouse runs in SQL Server. This was often due to licencing SQL with a Server/CAL licence rather than per core. Given that in 2012 the Server/CAL model is limited to 20 cores, this may change
Running Analysis Services on top of either the SQL warehouse above, or directly on top of the Oracle datawarehouse.
Big reach for both of these in financial services.
The third one, a little less common, is to run the Integration stack only, doing eg Oracle to Oracle or Oracle to DB2 (or XML etc) – a much cheaper solution than Informatica, and with a bit of work as capable (admittedly, slower in some areas such as XML, but also faster in others)
Hi Curt, the ColumnStore feature looks like a bitmap index, nothing new. I’m missing something?
Hi Emiliano,
I’d rather reserve comment until I learn more. But the general idea is clearly: