Slashdot Mirror
Will Facebook, Twitter, LinkedIn Stay With MySQL?
littlekorea writes "The world's largest web-scale users of MySQL have committed to one further upgrade to the Oracle-controlled database — but Facebook and Twitter are also eyeing off more open options from MariaDB and cheaper options from the NoSQL community. Who will pay for MySQL enterprise licenses into the future?"
Just sell us the damn software and nobody gets hurt.
... PostgreSQL is over in the corner, saying, "Hey guys! I'm open! I'm open!"
But no one throws the ball the Postgres. Because no one like Postgres.
So Postgres goes home and does some homework.
Who will pay for MySQL enterprise licenses into the future?"
Left MySQL years ago and never looked back. I don't care if it lives or dies - not my problem - it's Oracle's.
seriously, how is this even a question?
Anons need not reply. Questions end with a question mark.
Government for one. The US Department of Energy still uses MySQL, and I doubt they'll move off it anytime soon.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
I've never come accross any company, or individual, who actually does this.
I love this new DB drama that's going on. Please keep us updated.
You don't have to pay for a commercial license of MySQL as far as I know, unless you want support for it.
And even if there were a dollar difference, I doubt it would be enough to cover the cost of redeveloping everything to use NoSQL servers.
Hell, it's not even cost effective to switch to another SQL database like PostgreSQL.
Can you imagine the downtime required to export Facebook from MySQL and to re-import it to another database? The users would go ballistic!
I don't expect any "earth shattering" movement by any of the big users in the near future.
I do not fail; I succeed at finding out what does not work.
That's strange, for some reason I had the idea that Twitter and Facebook were already using NoSQL. If they aren't, then is any large company using NoSQL?
"First they came for the slanderers and i said nothing."
One entire Billy Graham at a time?
Enterprise gives you basically better administration tools (monitoring, backup, HA, etc), and support. If you really need them, you will still need them if you switch to MariaDB, or will be a reason to not to swich (there are more players in the support area and extra tools, anyway). But most of hose players have good internal knowledge on MySQL, and have contributed code and patches to it, probably are not the target for the enterprise version.
But if is enough for you the plain, non enterprise version of MySQL and existing available tools probably you will be better with MariaDB (or any of the other mysql compatible alternatives)
are you guys still using MySQL?
Do you even lift?
These aren't the 'roids you're looking for.
Could someone please tell me what "web-scale" means?
but Facebook and Twitter are also eyeing off more open options
Facepalm.
systemd is Roko's Basilisk.
Google's switch [to MariaDB] may have been motivated by a lawsuit filed by Oracle over alleged use of Java patents in Google's Android operating system.
You don't say.
MySQL have an real open source license, the GPL.
Postgres does not have any real open source license. Their license is not OSI-approved nor FSF-approved.
They have some custom vanity license of their own.
I don't think Oracle really ever planned on doing much more with MySQL than keeping control of it until it dies.
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
in the mid-90s though.
Its web scale!
Who logs in to gdm? Not I, said the duck.
MySQL can't defer referential integrity checks until transaction commit. That should be a deal breaker from day one.
I'd be really surprised if these companies haven't actually forked MySQL and are maintaining their own internal version.
I switched to MariaDB but my database is the size of a microbe so the few quirks were of no difficulty; but there were quirks. MariaDB was not a plug in replacement. I love it and wouldn't go back but it did take a tiny bit of work. So if I had one zillion servers with crazy databases I would be taking my time on that one. I suspect that what you will see is new development experiments depending on MariaDB and slowly increasing the pressure until they just make the switch.
The other question is how many obscure features of MySQL features are they using? (Including custom code)
contrib/dblink works fine for its intended purpose and preserves security if you know what you're doing.
Btw, what exactly does "sequences out of sync with data" mean?
What do you mean "out of sync"? You mean it generates the same number twice? Or do you mean it can generate a number that has been assigned by some other mechanism to a primary key field?
If the latter, that's true of database sequences in general, including Oracle RDBMS. Some platforms, such as SQL Server, give you both sequences and autoincrement fields. The reason to have both is that while autoincrement is simpler to use, sequences are more flexible (e.g. you can obtain the key value for a row before the transaction is committed).
In any case, it is bad practice to rely on an auto increment or identity field's magnitude for anything other than identifying a record. For example, developers sometimes use such numbers to order records by when they were created, but auto increment numbers aren't reliable for that purpose. Sequences work just fine for generating numeric primary keys, even though they can pretty much intrinsically get "out of sync" with the keys in a table. "Syncing" is not a feature offered by sequences, period.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
If Postgress had that statement, I'd switch right now
I don't really remember that well anymore, but Linux and MySQL have always been tied together...probably because mysql was relatively fast out of the box. Even today Postgres' default's suck, and the wiki says so:
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
"One reason the defaults are low is because on some platforms (like older Solaris versions and SGI), having large values requires invasive action like recompiling the kernel"
I mean, who remembers when there was a Solaris kernel that you could recompile (sunos4). Who gives a shit about IRIX? I mean, do you still have to specify cylinder and sector counts? WTF? It's 2013. Update your config for a Xeon 2ghz box with 8gb of ram already. If you want to be conservative, use a core 2 duo.
I kept expecting something in the doc to say "due to the lack of floating point coprocessors on some 386 systems so that's not assumed" or "CP/M wasn't designed for multi-user time sharing, so we implement manual time slicing."
Maybe they don't update the config because they want to get paid the consulting $$ to tune it?
I personally think that the real problem with Postgresql happened 10 years ago. At that time it was not possible to run Postgresql on Windows(it was only possible via cygwin). That helped mysql get critical mass and Postgresql stayed behind. Then the snowball effect came into play and mysql was getting much more users compared to Postgresql.
My guess is that he doesn't understand how sequences work, and expects more than just a monotonic counter.
Specifically, I think he missed this line in the documentation:
Do you realize how difficult and time consuming it is to switch a large codebase from one RDMBS to another?
It's not that bad if you started with an ANSI SQL compliant DB, didn't write unnecessary DB specific code and commented those places you did.
But once you've built significant code around something like mySQL you are permafucked.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Summary: I don't understand how sequences work (that they are not *supposed* to stay in sync and this should never be assumed), so like the typical bad workman I blame the tool and dismiss it as 'a toy'.
The tool you should be blaming is yourself.
I am a fan of Postgresql. I prefer it whenever using it is supported.
However, I often find that most LAMP stack apps were written only for mysql. For example, Wordpress was originally written for MySQL only, but now it supports Postgresql but few hosting companies set it up using Postgresql.
If I were to write a new LAMP app or any database driven app, I would probably develop with Postgresql as the primary DB. Why? Because then my installer could install the database too with no problems with licensing or distribution rights.
If you're working with an application which hasn't been engineered for database portability, yes, it can be a complete pain. Which is why a good software engineer, embarking on what may be a long-lived application, designs for database portability. You know those 'special features' your favourite RDBMS offers? They're called 'vendor lock-in', and you should avoid them.
I'm old enough to remember when discussions on Slashdot were well informed.
The problem is that database abstraction (at the level sufficient to throw a switch to change DB platforms) carries a performance price. If you've scaled your business to the point that you "need" SQL Server (as if it outperforms mysql), as the OP was suggesting, you have probably de-abstracted yourself to the point that swapping DBs will be a serious pain.
Testing pOST
The problem? Same as 32-bit "classic UNIX" has with UTC timeclock, albeit in MySQL (unless they fix it, & it's even present in the 64-bit offering as well iirc) -> http://en.wikipedia.org/wiki/Year_2038_problem
---
PERTINENT QUOTE/EXCERPT:
"MySQL database's inbuilt functions like UNIX_TIMESTAMP() will return 0 after 03:14:07 UTC on 19 January 2038"
---
* &, "there ya go"...
APK
P.S.=> THIS, needs a "fix", bad... apk
MySQL is used predominately because it's very simple. It's good for simple minds, and there are a lot of simple minds. People with bigger brains usually gravitate toward more advanced tools. They use PostgreSQL. Comparing MySQL and PostgreSQL is just dumb. They are both databases that use the SQL syntax for queries. After that the similarities end.