Has MySQL Forked Beyond Repair? 334
snydeq writes "Fatal Exception's Neil McAllister questions the effect recent developments in the MySQL community will have on MySQL's future in the wake of Oracle's acquisition of Sun. Even before Oracle announced its buyout, there were signs of strain within the MySQL community, with key MySQL employees exiting and forks of the MySQL codebase arising, including Widenius' MariaDB. Now Widenius' Oracle-less Open Database Alliance adds further doubt as to which branch of MySQL will be considered 'official' going forward. 'Forks are a fact of life in the open source community, and arguably an entirely healthy one,' McAllister writes. 'Oracle just better hope it doesn't end up on the wrong side of the fork.' To do so, he suggests Oracle will have to regain the the trust and support of the MySQL community — in other words, 'stop acting like Oracle.'"
Re:PostgreSQL: Why don't people use it that much? (Score:5, Informative)
Postgresql has a terrible marketing and image, mysql doesn't.
Re:Already Planning my project for MariaDB (Score:4, Informative)
If they make improvements and Oracle refuses to be part of the community, then guess who is going to have the better version in the long run? I'm putting my money on that community of developers rather than the company with the overblown ego. We all know how companies with overblown ego react to the open source community after all.
Re:PostgreSQL: Why don't people use it that much? (Score:3, Informative)
Re:Cue postgres fan bois (Score:5, Informative)
Clearly this is a troll but regardless of all other features that MSSQL may have that MySQL doesn't there is one thing that is missing: LIMIT.
Perhaps it's because LIMIT isn't ANSI SQL [arvin.dk]? Before SQL-2008, you were supposed to use ROW_NUMBER() for that, which MSSQL does support. And no-one supports SQL-2008 yet.
Re:Oracle needs to cater to business not the commu (Score:1, Informative)
I'm pretty confident that most of those companies are running MS SQL, Oracle, and MySQL... among other things.
MySQL has it's place. It's place is most certainly not in mission critical, highly available, highly scalable solutions.
How many Enterprise Data Warehouses out there run on MySQL?
Also realize that many of the web-centric companies you listed there probably started out using MySQL because they couldn't afford anything else. Their architectures often have a high degree of redundancy and load distribution among commodotized hardware. This is certainly a niche where MySQL reins supreme.
Unfortunately, no matter how hard you wish upon a star (schema - DBA humor ha-ha!) MySQL is just not on the same level as MSSQL, Oracle, or even DB2. Sorry.
Don't believe me? /min.
Go ahead and create a multi-TB database (on one server) with a few tables that are >100GB each. Do some performance benchmarking after scaling as best you can with each DB System and let me know how that works out for you.
Oh, did I mention that this has to be on one server that you replicate to the other side of the world with less than 30s of change difference between the two and that you also need local HA and global DR OUTSIDE of the replication you just setup?
Oh yeah; your data change rate is ~500MB
Good luck!
Maybe copy & pasting things you read on the internet and calling other people names wasn't the best idea, huh?
Re:Oracle needs to cater to business not the commu (Score:5, Informative)
I've heard the arguments that postgres is as easy as MySQL, and they're bullshit.
Lets see:
Postgres has no good GUI applications that can compare with MySQL's
Why you need more than one is beyond me. Isn't Pgadmin [pgadmin.org] enough?
their command line application is just as good in its own way
Well, ok. Whatever 'in its own way' means.
and the market share that ensures you need to google multiple times to find the info you're looking for.
Postgres has some of the best documentation of any open source project I've seen [postgresql.org]. Sure, MySQL is good as well, but lets not spread bullshit here.
Installing postgres is also a nightmare compared to MySQL.
You mean in a download-the-msi-and-double-click-on-it way, or the apt-get-install-it way?
To sum up: free > $millions, easy > full-featured (in many circumstances).
Well, it's fully-featured, but not necessarily all of those features at the same time. Try doing full-text indexing on a database with foreign-keys on it in MySQL sometime.
Re:How healthy are forks? (Score:2, Informative)
I guess it depends how you define a fork. If you consider a patch set a fork, then most distributions fork a large majority of the software they ship. And for the kernel, there are actually many many forks--it's the development model they actively encourage with git.
Re:Cue postgres fan bois (Score:2, Informative)
Assuming you have a unique key on the table called ID,
SELECT * FROM Table LIMIT 20, 10
becomes
SELECT TOP (10) * FROM Table WHERE ID > 20 ORDER BY ID
?
No, this is not the same. Your example relies on the fact that you have a monotonically increasing numeric attribute called ID without gaps in the numbering.
It may be the case, or it may be not. To the point that, afaik, you can LIMIT just relying on physical ordering (sic).
The correct implementation would be something like
SELECT * FROM (SELECT ROW_NUMBER() OVER (ORDER BY id) as rn, * FROM dbo.test_deadlock ) AS T WHERE T.rn BETWEEN 20 and 20+10
Of course you always have to provide and attribute for the ORDER BY otherwise it doesn't really make any sense to "limit" the result set in the first place (unless someone is so dumb to rely on physical ordering defeating completely the idea of having a DBMS with an optimizer etc. etc.)
Re:MySql (Score:3, Informative)
PostgreSQL scales well, but is fairly slow on average.
I spent months making my queries ugly and hacky and optimised for mysql, and my website would still grind at about 500 concurrent users. Out of curiosity I switched to postgres, code unchanged other than the minimum to be compatible and it ran fine up to around 1000. Then I rewrote the queries in order to make them simple and elegant, and postgres ran them /even faster/ :P
Re:Cue postgres fan bois (Score:3, Informative)
MSSQL supports the (cumbersome) ISO rownumber operator doesn't it? The syntax to apply a limit is a bit bodgy, but it does work neh?
This gets rows 100 through 200.
SELECT * FROM (
SELECT
ROW_NUMBER() OVER (ORDER BY key ASC) AS rownumber,
columns
FROM tablename
) AS foo
WHERE rownumber > 100 and rownumber = 200;
Re:Oracle needs to cater to business not the commu (Score:4, Informative)
Wikipedia
Is 99% cached content, served as effectively static files
Google
Has some developers who have it installed; none of their major services are based on it
Facebook
According to the video of how it works, is basically a graph database, on top of a giant key:value table, on top of memcache, on top of mysql -- ie, they do their best to avoid actually hitting the database, and when they do, they only make use of the most basic functions (and it isn't even good enough for that, so they're working on a replacement)
Twitter
While large, it's hardly complicated in terms of database schema, and it /still/ falls over all the time :P
The other sites, I've never seen any behind the scenes reports on.
While "we have at least one copy of mysql installed somewhere in our organisation" is common, "we are using mysql as the central database for our heavily stressed mission critical systems, and it works great" is much rarer :-P
Re:Fork it (Score:5, Informative)
Most
Re:MySql (Score:5, Informative)
In comparison? Yes. When you're doing simultaneous writes from multiple threads, SQLite's lack of fine-grained locking kills performance.
A couple of months back I did some benchmarking of MySQL and SQLite3 as possible storage backends for a website. The test load was a task consisting of two SELECTs, an UPDATE, and an INSERT. With only one or two simultaneous clients, SQLite3 was faster. With three clients, they were tied. At 50 clients, SQLite3 was taking over 100 times longer than MySQL.
Re:MySql (Score:5, Informative)
PostgreSQL scales well, but is fairly slow on average.
Really? Because any recent review of Postgres shows that it stomps the pants off MySQL in all cases except very simple queries against very small tables. (And really, who gives a !@#% about that scenario?)
Also....
1) It's data validation is excellent.
2) It's extremely stable. In YEARS of working with it, I've had ZERO integrity issues despite managing rather large data sets.
3) Particularly important: it maintains good performance as the query complexity soars. While it can take a bit of tuning, I've done 12 table joins with combined inner, outer, and subqueries and millions of records, with an average return time of around 0.2 seconds. The statement alone was two pages, printed form, on a single-core Athlon 64 with ATAPI drives and 1 GB of RAM.
4) It's FREE FREE FREE!
5) It includes excellent near-realtime replication. (functionally analogous to MySQL replication, which is nice when it works, but since it usually doesn't, well...)
1994 called. It wants its stale information back.
Re:MySql (Score:1, Informative)
PostgreSQL scales well, but is fairly slow on average.
PostgreSQL had/has a reputation of being slow compared to MySQL mostly because the 7.x series default postgresql.conf file limited the it to using 16MB of memory. This advantage became negligible once you adjusted the config to something more reasonable.
The thing with MySQL is that you were supposed to have both.
MySQL was actually known not to scale initially.
At the time MySQL only had the MyISAM backend, and it's still the default one. The ISAM algorithm/data structures were known (for decades) to be fast, efficient, and easy to implement. However, they have severe read/write concurrency issues inherent in the design (same reason why the backend only supports table level locking). Also it lacks the ability to have major features (like transactions) that people had come to expect from a db. Thats why others didn't use them as a primary backend.
InnoDB was really what made MySQL a viable general purpose DB
SQLite is fast all right, but it doesn't scale at all.
MyISAM has concurrency issues at the table level since the table data was stored essentially in one flat file.
SQLite, while totally awesome for its purpose as an embedded database, stores the entire database (not just each table) in a flat file. Its concurrency issues are therefore understandably worse.
Re:Cue postgres fan bois (Score:2, Informative)
I've used it plenty. I've scaled MySQL better, and more importantly - without any question as to how much I need to pay for licensing.
Enterprise Manager has changed remarkably little since it was taken over by Microsoft.
DTS portability and authoring is poor within EM to say the least. SQL Agent scheduling of DTS scripts is lacking as well. Querying, user management, etc. are all more intuitive than Oracle, but still the interface is quite poor.
MS SQL has it's place. But it certainly doesn't separate itself as significantly better than OSS solutions for 90% of database usage scenarios (at least 90% of the ones that I've been involved with).
Re:Cue postgres fan bois (Score:3, Informative)
Re:PostgreSQL: Why don't people use it that much? (Score:4, Informative)
And then there's the increment functions. MySQL is a bit lacking, with only AUTO_INCREMENT and LAST_INSERT_ID. SQL Server has a similar setup to MySQL using IDENTITY(start, step) and SCOPE_IDENTITY(). But PostgreSQL uses that atrocious monstrosity of SERIAL data types and a damned Sequence object.
PostgreSQL seem to have copied that bit from Oracle, which also uses sequences. But sequences are actually superior, and here's why.
With sequences, you can emulate auto-increment behavior easily (you use the NEXTVAL or whatever the syntax in a specific implementation is, right in your INSERT). On the other hand, with sequences, you can generate the IDs first, and then generate a bunch of INSERTs with those IDs, with only two roundtrips: one for SELECT NEXTVAL - for as many records as you want - and another for multi-record INSERT. Why would you want a bunch of IDs? When you are batch-inserting records into a bunch of tables that reference each other (e.g. 10 records into table A, each of which has 10 new child rows in table B, each of which has 10 more new rows in table C). In MSSQL with auto-generated keys, you have to go about it that way:
1. INSERT records into A and retrieve the generated keys.
2. Use retrieved keys to generate INSERTs for new records in B; retrieve generated keys.
3. Use retrieved keys to generate INSERTs for new records in C.
For more tables in the hierarchy, you do more roundtrips. Now the same with sequences:
1. Request generation of keys for all records you'll be inserting, and retrieve generated keys.
2. Generate INSERTs for all new records using retrieved keys.
And it doesn't matter how deep the tree is, it's only 2 batches.
Of course, for MSSQL you can do away with generated keys completely, and use GUIDs, which can be generated on the client in the first place. But that makes indexes that much bigger, and queries that much slower...
nd heaven help you if the Sequence gets out of sync
This bit I don't understand at all. What do you mean by "sequence gets out of sync"? It's not really in sync with anything, it's just a simple counter that's guaranteed to safely produce unique incrementing values even for concurrent requests.
Re:How healthy are forks? (Score:5, Informative)
And one more fork in the making that looks like it is going to have the same impact as XFree/X.org eventually, if not bigger: EGLIBC [eglibc.org]
Re: Ingres (Score:3, Informative)
Oracle and Ingres were serious competitors about 25 years ago. However, Oracle quickly adopted a significantly better design that put Ingres-like databases (Ingres, Informix, Illustra, the original Postgres, etc.) virtually out of business.
Not only that, the internal MVCC architecture of PostgreSQL is *much* closer to Oracle than any of the other Ingres derivatives - including Postgres itself. The original Ingres hit the wall in large part due to the lack of multiversion concurrency control and row level locking (among many other things). In other words, it was practically useless for running large transactions concurrent with other activity, an area where Oracle shines.
Page level locking and no MVCC means that writers block readers (and other writers) until the first transaction to lock the page commits. Page level locking means that which rows will be incidentally locked up by a transaction is essentially random.
Such databases worked well if you were read mostly, and ran small quick transactions during the day, and large long running transactions in appropriately scheduled batch jobs at night. Unfortunately, technologically speaking, MySQL is about to catch up to where Ingres was just prior to entering its terminal decline twenty years ago. The InnoDB engine is the only major exception. Of course people typically use MySQL for rather different applications than they use Oracle for, and MySQL is radically less expensive.
Comment removed (Score:3, Informative)
Re:PostgreSQL: Why don't people use it that much? (Score:3, Informative)
Actually not really true. Postgres in the early days always was way more stable than MySQL, the speed however was less, because it always supported transactions, while MySQL started as an ISAM system with some sqlish language on top of that. But I never ever recall having the problem of corrupted data on postgres not even in version 6. The main issue was simply, that there was no decent windows port and postgres had to rely on Cygwin which made the db slow und unstable while it was not!
Add to that that early PHP versions were hardcoded against MySQL, and PHP as well got loads of momentum!
Things have changed by now. While the MySQL quality still is questionable, PostgresSQL has accellerated tremendously and also has a native windows port and good installation and UI maintenance tools but the problem persists while being leagues better, and believe me I have seen big installations where postgres chugs along happily never failing their users, MySQL still has the mindshare.
If you are looking for a real enterprise ready db in the OSS area PostgreSQL is the way to go!