Please create an account to participate in the Slashdot moderation system


Forgot your password?
Databases Programming Software Businesses Oracle Sun Microsystems IT

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.'"
This discussion has been archived. No new comments can be posted.

Has MySQL Forked Beyond Repair?

Comments Filter:
  • by ( 653730 ) on Thursday May 21, 2009 @05:35PM (#28046115)

    Postgresql has a terrible marketing and image, mysql doesn't.

  • by Foofoobar ( 318279 ) on Thursday May 21, 2009 @05:50PM (#28046317)
    Well they want to be compatible with existing MySQL versions as Monty has stated and not be a fork but they also want to fix broken functionality on the backend that SUN has been unwilling to do thus far. MariaDB from my understanding is just a community version but they would like to see their commits go up to Oracles version as well.

    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.
  • by K. S. Kyosuke ( 729550 ) on Thursday May 21, 2009 @06:06PM (#28046541)
    I am not certain whether any form of "feature complete" counts when "final releases" are filled with bugs. MySQL might have been stable when its feature set was next to nil, but I will sooner return to FoxBase than to prefer MySQL 5. over Firebird (or PostgreSQL). PostgreSQL is has been actually *designed*. And it shows. Without good design, sustained performance improvements such as these [] and feature improvements such as these are unthinkable. []
  • by shutdown -p now ( 807394 ) on Thursday May 21, 2009 @06:11PM (#28046599) Journal

    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 []? Before SQL-2008, you were supposed to use ROW_NUMBER() for that, which MSSQL does support. And no-one supports SQL-2008 yet.

  • by Anonymous Coward on Thursday May 21, 2009 @06:47PM (#28047039)

    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?
    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 /min.
    Good luck!

    Maybe copy & pasting things you read on the internet and calling other people names wasn't the best idea, huh?

  • by growse ( 928427 ) on Thursday May 21, 2009 @06:56PM (#28047137) Homepage

    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 [] 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 []. 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.

  • by RevDiaBLo ( 4291 ) on Thursday May 21, 2009 @07:00PM (#28047183)

    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.

  • by Anonymous Coward on Thursday May 21, 2009 @07:14PM (#28047331)

    Assuming you have a unique key on the table called ID,

    SELECT * FROM Table LIMIT 20, 10




    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)

    by shish ( 588640 ) on Thursday May 21, 2009 @07:37PM (#28047563) Homepage

    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

  • by Anonymous Coward on Thursday May 21, 2009 @07:47PM (#28047665)

    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.

                                              ROW_NUMBER() OVER (ORDER BY key ASC) AS rownumber,
                                        FROM tablename
                              ) AS foo
              WHERE rownumber > 100 and rownumber = 200;

  • by shish ( 588640 ) on Thursday May 21, 2009 @07:54PM (#28047741) Homepage


    Is 99% cached content, served as effectively static files


    Has some developers who have it installed; none of their major services are based on it


    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)


    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)

    by derGoldstein ( 1494129 ) on Thursday May 21, 2009 @08:00PM (#28047787) Homepage
    Just once? I usually get modded "funny" when I'm serious, and "informative" when I'm joking.

    Most /. mods are very bored individuals. It gives them something to do. They're not like us, the /. posters, who are intelligent, thoughtful, handsome, and socially adept.
  • Re:MySql (Score:5, Informative)

    by Carnildo ( 712617 ) on Thursday May 21, 2009 @09:05PM (#28048243) Homepage Journal

    SQLite is fast all right, but it doesn't scale at all.

    MySQL does?

    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)

    by mcrbids ( 148650 ) on Thursday May 21, 2009 @09:14PM (#28048307) Journal

    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?)


    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)

    by Anonymous Coward on Thursday May 21, 2009 @09:18PM (#28048343)

    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.

  • by Evets ( 629327 ) * on Thursday May 21, 2009 @09:57PM (#28048631) Homepage Journal

    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).

  • by kilodelta ( 843627 ) on Thursday May 21, 2009 @10:57PM (#28049043) Homepage
    Say what? In my experience an MS-SQL server could NOT keep up with heavy hits for a corporate database. We had to replicate the MS-SQL tables to MySQL in order not to have to restart a server every 30 minutes.
  • by shutdown -p now ( 807394 ) on Thursday May 21, 2009 @11:26PM (#28049153) Journal

    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.

  • by shutdown -p now ( 807394 ) on Thursday May 21, 2009 @11:30PM (#28049167) Journal

    And one more fork in the making that looks like it is going to have the same impact as XFree/ eventually, if not bigger: EGLIBC []

  • Re: Ingres (Score:3, Informative)

    by butlerm ( 3112 ) on Friday May 22, 2009 @12:48AM (#28049653)

    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.

  • Re:MySql (Score:3, Informative)

    by Tim99 ( 984437 ) on Friday May 22, 2009 @12:52AM (#28049675)
    The SQLite documentation [] states:-

    SQLite usually will work great as the database engine for low to medium traffic websites (which is to say, 99.9% of all websites). The amount of web traffic that SQLite can handle depends, of course, on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.

    SQLite will normally work fine as the database backend to a website. But if you website is so busy that you are thinking of splitting the database component off onto a separate machine, then you should definitely consider using an enterprise-class client/server database engine instead of SQLite.

    To get anything like decent performance you need to put your test loads into TRANSACTIONS. So start with a "BEGIN TRANSACTION" do the SQL stuff then "COMMIT" (or "ROLLBACK"). That way each disk read and write is controlled by its own lock - The performance difference for 1000 row INSERTS (see Threading on the SQLite site) is impressive: Summary Without transactions: 470 + 552 = 1022 collisions in ~8 seconds. With transactions: 0 + 117 = 117 collisions in ~3 seconds. For INSERTS of a couple of rows in a transaction you will probably get close to your 100 times better performance of MySQL.

    Having said all of the above, if you are really expecting the site to have 100 concurrent updates (say 300,000+ an hour) you should probably be looking at a big server running PostgreSQL or Oracle...

  • by Anonymous Coward on Friday May 22, 2009 @02:41AM (#28050145)

    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!

Machines that have broken down will work perfectly when the repairman arrives.