Slashdot Mirror
Microsoft Brings SQL Server To Linux (betanews.com)
Mark Wilson writes: The new Microsoft has place an increased importance on the cloud, and with other companies following suit, reliance on server solutions has increased. Today the company announces that it is bringing SQL Server to Linux. Both cloud and on-premises versions will be available, and the news has been welcomed by the likes of Red Hat and Canonical. Although the Linux port of SQL Server is not due to make an appearance until the middle of next year, a private preview version is being available to testers starting today. While the full launch of SQL Server for Linux is not due until the middle of 2017, SQL Server 2016 is expected to launch later this year.
On mobile Microsoft has pretty much given up and support Android and iOS as well or better than Windows Mobile now now on the Server side we've already seen .Net moving fast to Linux and now the third biggest lock in application on Windows Server(AD and Exchange being bigger) is coming to Linux. With AD and Exchange being pushed more towards hosted services in the cloud, Windows' future doesn't look too bright there.
They have been doping for quite a while.
Linux is actually pretty important for Microsoft's Azure cloud platform.
Did you know that Microsoft even has a Linux certification? They do
Any insufficiently advanced magic is indistinguishable from technology.
You're under the impression that businesses only care about a free pricetag.
Businesses care about the lowest price that gets you the best support. I spent months trying to find a DBA who knew anything about Postgres, but if you have an opening for SQL server, you need a frontloader to get through the crowd of them.
Yeah, few, if any of them are what you'd call geniuses, but I really only need one or two geniuses at a time to tell the data monkeys what to do. And if I have to pay genius rates for a data monkey, then perhaps I'm willing to pay for a database something that has higher adoption and high integration.
SQL Server is no slouch for features and while it is not free, you have a better pool for support and integration.
Note, aside from being unable to find a Postgres data monkey, that isn't my story. I don't use SQL Server, but I have the luxury of knowing how to operate a SQL database myself, so I just sucked it up. For businesses where that isn't really an option, I can see why they might want SQL Server. And indeed, many, many businesses do use it.
Here's one data point - based on from experience migrating a pretty big system from [a major proprietary database mentioned in the article] to Postgres, I think the two biggest advantages Postgres has are:
GIST and GIN indexes (and soon BRIN indexes), and
Writeable CTEs.
We migrated a very busy, pretty large (24 CPU core, 256GB RAM, 20TB disk space) system from [a major proprietary database mentioned in the article] to Postgres about a year ago. These graphs measuring CPU and disk activity provide a nice visualization of the improvement:
http://imgur.com/a/bp2ky
Note that with [a major proprietary database mentioned in the article], all 24 CPU cores in the system were over 40% utilized (and growing) 24x7 most days a year. After a pretty naive port (November to May in the graph) the CPU load fell to an average of about 10%, and the disk array's queue length fell from painful to near zero. After adding some Postgres-specific code, we got it down to an average of near 5% (shown in the most recent month in the graph).
CPU differences seem to have been mostly related to the availability of GIN indexes in Postgres, which can be much more efficient on certain types of data (like the OpenStreetMap road network).
Disk I/O improvements seems to be mostly related to Postgres's far more compact storage of XML data. Seems SQL Server stores XML data using 2-bytes-per-character for the data itself; and on top of that adds extremely large indexes. In contrast, the "toast" feature in Postgres means the XML data takes an average of less than one byte per character for the data and its "functional index" feature allowed for far more compact indexes. One of our XML-heavy databases went from over 600GB in SQL Server down to 140GB in Postgres, with more efficient indexes.
For a few months we tried to stay database-agnostic so it'd be easy to port back if we needed to -- but after a while we started adding Postgres specific changes. The benefits of those Postgres specific changes can be seen near the end of those graphs. An enormous improvement occurred when we changed the inserts and updates to use the Writable CTE features following recommendations someone outlined here
.
In the end, Postgres looks to me like it's saving us like 5X in hardware costs as we continue to grow.
Edit: I'm told this proprietary database vendor dislikes users publishing benchmark results comparing their software to F/OSS databases. I'd argue that this is more of an anecdote than a benchmark; but just in case I edited the comment to remove the vendor and product name from the parts that talk about performance.
Disclaimer: As mentioned in a comment below, we tried to tune each the systems to the best of our team's abilities, but aren't really experts in tuning either database system. No doubt each system's results could be improved by people who were deeply available with each databases internals (which I argue is much easier to find for Postgres, since its mailing lists have thousands of people familiar with the internal code).
You know, there's a bit of history that I've never shared on Slashdot and it concerns Oracle. As tempting as it is to type that out, I'm really not in the mood for a novella this evening - and you probably aren't in the mood for one either.
The short of it is that I had a salesman in, back in the late 1990s, who wanted to help my company out. By this time, I was already weary (and leery) of such but they had a good idea and a product name that I recognized as being industry-leading. (You can see where this is going, right?) I don't want to mention any names but there's One Raging Asshole Called Larry Ellison - and I guess he kind of owns the joint.
Now, I don't know what kind of ship (see what I did there?) he runs over there but they have some smooth-talking guys who are actually very well researched. Or, at the time they did. Consider, at the time, this was cutting edge stuff that we were doing and not exactly popular. But these guys knew things about relational databases, joins, parts, searching, indexing, and all these things - and they were happy to give me an education so that I knew all about those things to. And I listened.
It should be noted that I didn't just listen, I asked questions. I didn't just ask them questions - I asked my peers questions. I didn't just ask my peers questions, I asked the people who worked with me questions. I do that, I ask a lot of questions because, contrary to popular opinion, I do not know everything.
So, the short story is that we invited them in. Now, I have shared that part of the story before. It took some time for our DB wizard to return to normal and get over his angry phase but the ship (see what I did there) was righted anew.
Anyhow, they fought, fiddled, exported, and joined, and attached, and merged. They networked and peeked and poked. They were not working with live data, of course. They attempted to get it to communicate with the network and function and do database type things. They spent the better part of six months, as I recall, visiting and testing and poking. They brought in hardware, and boxes, and people. They stomped through and gave promises. Contracts were even signed. More on that in a moment.
And it never worked. Ever. It never came close to working.
Now I don't know if our Wizard sabotaged this. I kind of doubt he did. He wasn't that... Well, no... He was that kind of guy but I don't think he did. I'd have no way of knowing if he did but I suspect he'd have let it slip if he had. It might have been maniacal laughter when they left but that's not what he did. The important part of this is that it never, ever worked.
So, we gave 'em the boot. We had important things to do and they were in the way and slowing us down. We're also working with data that doesn't really belong to us and having to vet an extra ten people stomping in and out of the server room is not acceptable. They leave...
A little while later, in comes a lawsuit. They want an almost 7 figure some of money. Now, I don't know what they were expecting but - if you go back to the earlier part of this message, you'll notice that I ask a lot of questions. The contract that I'd signed, I'd signed it personally, was quite specific in that the job needed to be completed to my satisfaction and that the installation was at their cost. It would appear that they were billing someone (whom I do not know) thousands of dollars a day for that work.
And someone, whom I still do not know, was buying hardware - all that hardware they'd brought in was someone else's expense. I do believe the contract stated we were to pay for hardware, by the way. We didn't keep any of that hardware, use any of that hardware, ask for any of that hardware, sign for any of that hardware, or even really have any room for it - this was pre-expansion.
So, they wanted us to pay for people we did not hire, who did work we could not use. They wanted us to pay for software - and maintenance for some years, that was not installed. They wanted us to pay for hardware we did
"So long and thanks for all the fish."
Oh god... please end it now. As someone that has had to deal with end user generated 'applications' spreading Access is both a crime against humanity and nature.
love is just extroverted narcissism