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.
April 1st isn't for another month silly.
April 1st isn't for another month.
That explosion and mushroom cloud was Steve Ballmer's head exploding.
Just what Linux needed!
...as temperatures reportedly fall all over hell.
Loading...
It looks like Microsoft is well on their way towards embracing Linux. Of course, what worries me is what comes AFTER embracing and extending. You old-time Slashdotters know what I'm talking about, right?
Finding God in a Dog
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.
Perfect. Maybe systemd can use it for logging, like a modern operating system.
an ill wind that blows no good
How long before we see a version of "Microsoft Linux"?
You laugh now, but I can see them glomming onto Linux, especially as more businesses and desktop move over to Linux.
And yes, of course it will have subtle incompatibilities that grow more and more pronounced over time. That's what it's all about with Microsoft.
"MS Linux- Because We Care" or maybe, MS Linux- The Most Stable OS We've Ever Produced!*
-
* and by "produced", we mean "stolen"
Just cruising through this digital world at 33 1/3 rpm...
I don't see how SqlServer can compete against Postgresql. The only thing SqlServer had going for it was integration with .Net framework.
.. and real stored procedures.
I don't see how SqlServer can compete against Postgresql. The only thing SqlServer had going for it was integration with .Net framework.
.. and real stored procedures.
What features do stored procedures provide that can't be handled with postgresql functions?
Outside of starting and ending transactions within the function I can't think of anything. Parameters can be input or output and you can modify tables. These are normally things that people with an SQL Server background believe can't be done within functions but in postgres they can.
Postgres isn't a perfect database but it's extremely powerful with new features being added all the time. It has a lot to offer for free.
If Microsoft wanted to extinguish Linux, they wouldn't even have to do a damn thing these days.
The Linux community is doing a superb job of extinguishing Linux all on its own.
Regardless of what you think about it, systemd has caused massive disruption within the Linux ecosystem.
The Debian project, which for a long time was the premiere Linux distribution, has been torn apart by its decision to use systemd.
Lots of other Linux users have had systemd cause them serious problems, including computers that would no longer boot properly.
Many of these Linux users have chosen to move to FreeBSD, OpenBSD, OS X, and even Windows in some cases.
And that's all on top of the problems that GNOME 3, NetworkManager, and PulseAudio have caused.
Then there's the failure of the Wayland project to create a modern replacement for X.
Each one of these failures has hurt Linux's viability, and there's no end in sight!
Existing users are being driven away, and there are no new users replacing them.
DBA's gotta manage it, and many prefer using a GUI.
Granted, it's often considered better to manage it via scripts (command line text) so that it can be re-created, but in practice, some want "quick and easy". This is MS shops we are talking about.
Table-ized A.I.
And performance, and scalability, and encryption, and replication, and backup / restoration, and reporting / analysis, and tuning / optimization, and...
MS wears some big ol' clown shoes (see my recent submission about the botched Win 10 update), but SQL Server, with all its various components, is an industry-leading product for good reason. The only other solution I've seen serious people use is Oracle, and they only admit to it sheepishly, like a shamed victim.
Sounds like a joke? No I'm serious.
I don't need yet another database in Linux. PostgreSQL is fine, thank you. Even MySQL/MariaDB are OK.
What I miss is a GUI interface to these databases, which would allow me to quickly build GUI applications for users. MS Access can show PostgreSQL data to users in quickly designed forms and reports. And these can have some (horrible) VBA code to make a few things faster and easier for the users. Without Access, I have to make HTML interfaces, which works fine for simple reports, but gets really clumsy and slow for complex interactive forms.
(Yes, I know about PGadmin. It's great for me, and I use it regularly. But it's not for designing custom user interfaces to databases)
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.
We'll port systemd to Windows!
Have gnu, will travel.
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).
Yes, to some degree, but usually your options are Oracle, or if you are slumming it, they'll let you run on SQL Server.
Oracle is horrendously expensive, so SQL Server often wins because developers want a big name DB that they support in case the customer doesn't want to pay 2 million dollars for a rather small cluster of Oracle hosts, or the customer already has a big Windows Server presence for some reason.
Usually your Postgres or MySQL is an option, but only under the Other SQL... category. They won't code their stuff to make use of the advantages of those platforms, so you're basically getting a free SQL engine that is completely un-optimized and barely supported.
I think M$FT realized that they couldn't scale their cloud architecture on windows so they started porting Azure services to run on Linux. May as well release their linux versions..
No, I'm not under than impression that businesses only care about a free price tag but not having deal with licensing issues is really, really nice. Besides few organizations really need a postgres DBA (or an SQL Server DBA).
If you're concerned about installation and support, you can get it through Enterprise DB and other sources. The postgres community is also an excellent source of support. I've been using postgres for close to 15 years and I've never ran into a problem that made me wish I had some sort of phone support, but that's available for people that want it. There are also several cloud based postgres solutions where there is little to no configuration for you to worry about.
Integration is another story. If you're already heavily invested in MS development tools, then yeah SQL server is an easy fit. If you're not, then it doesn't seem to offer much on its own to warrant going that route.
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."
Your UID is a prime number.
I know, I know... This is off-topic but, damn it, it's important to me!
I even went and found you a link to show it:
http://www.numberempire.com/pr...
"So long and thanks for all the fish."
Comment removed based on user account deletion
We have multiple servers with ~1-2 TB data each and more RAM/CPU/SSDs that I imagined possible. Unfortunately sometimes data is concentrated in too few tables and MSSQL has a tendency to lock up the entire table when it feels like you are on to something. I am forced to split all transactions in very many very little pieces and feel like an idiot for why doesn't the database handle the damn transactions for me, something it was supposedly designed to do. Our design/set-up may not be ideal, but few online reviews that I found show that this is known flaw of MSSQL, not just our setup that has issues with it.
Awesome story. I'd wondered about Postgres and heavy-duty jobs; turns out it's as impressive as touted.
I worked 25 years in an Oracle shop, from Oracle 6.1 to Oracle 12c; assumed everything else, certainly FLOSS stuff, had to be toy products by comparison.
Then I tried PostGIS because I was working with the new free GIS program, QGIS, and PostGIS isn't just a free RDBMS, it's a geodatabase. Soon, I found it was handling gigabytes of map data in an eyeblink - on a laptop. The more reading I did on it, the more of those "enterprise level" features for handling massive data sizes and user numbers I saw. I've wondered why I don't hear more about it.
We had some interaction with EnterpriseDB, who not only sell service, but have their own add-on software that makes shifting to Postgres from Oracle pretty easy for most. I just don't see how we aren't going to hear about more conversions soon.
TL;DR version:
Q: What does Stored Procedures provide that you don't get with PostgreSQL functions?
A: A pricetag.
I'm not really sure if you are arguing for or against MS SQL Server.
It strikes me as unusual as well. Almost every developer I've met has used PostgreSQL or MySQL at some point, and many of them knew it well. SQL server, maybe the odd one or two who worked on MS stuff. May be biased by working mainly with open source developers of course, but my experience is that there are plenty of people with PostgreSQL expertise around.
So it's an SQL Injection attack, on Linux?