MySQL Founder Starts Open Database Alliance, Plans Refactoring 153
Gary Pendergast writes "Monty Widenius, the 'father' of MySQL, has created the the Open Database Alliance, with the aim of becoming the industry hub for the MySQL open source database. He wants to unify all MySQL-related development and services, providing a potential solution to the fragmentation and uncertainty facing the communities, businesses and technical experts involved with MySQL, following the news of the Oracle acquisition of Sun." Related to this, an anonymous reader writes that "MySQL has announced a project to refactor MySQL to be a more Drizzle-like database." Update: 05/14 20:50 GMT by T : Original headline implied that this was a project of Sun, but (thanks to the open source nature of MySQL) it's actually Monty Widenius — no longer with Sun — leading this effort.
Re:why? (Score:3, Informative)
Existing products - there's some software packages people like to use from the open source world that are tied to MySQL.
But yeah, if I had any choice, there'd be no instances in which I'd pick MySQL over SQLite or Postgres.
Re:why? (Score:5, Informative)
I didn't ask if it worked. I asked in what scenario it would be a superior option (to the well-informed application architect, of course). The only real reason you gave is that you don't know much about Postgres. That means you're not really qualified to answer the question.
Does it scale better? Does it have better security? Is it easier to manage in some way? Is there a killer feature its two closest competitors lack? Those might be actual answers to the question. "I don't know much about it" is not an answer.
It's certainly commonly perceived that Postgres will scale better, and that it has a rather complete featureset. If this is indeed the case, I can't see a reason to select MySQL for a new project. Why limit yourself?
Re:Yes, but.... (Score:4, Informative)
Oracle has a number of lighter DB products, including Oracle Express Edition (XE) which is free (as in beer). They don't have anything (that I know of) that does the same kind of multi-backend thing that MySQL does, but certainly they have a number of products whose market niches at least overlap with that of MySQL.
(Also, Oracle is a lot more than a database development company and has certainly been more aggressively pushing into other areas; I suspect that their acquisition of Sun was more focussed on the non-MySQL parts of Sun than on MySQL.)
Re:why? (Score:2, Informative)
Maybe you should have followed your link:
"Fortunately, The Auto-Vacuum Daemon monitors table activity and performs VACUUMs when necessary. This eliminates the need for administrators to worry about disk space recovery in all but the most unusual cases."
Re:why? (Score:3, Informative)
Is sounds like you are saying that because it gets a lot of press causing a lot of people to know the name, then it must be the best database server out there. And it is more compatible and works better because of that? WTF? What the hell do you mean by compatible by the way?
More people know or knew how to program in Visual Basic than in Java or C or C++. Does that mean it is a better programming language and more compatible? You are going to tell me that what I just wrote doesn't make sense. And you would be correct. But neither did your statement. I also used Visual Basic as an example on purpose. Being popular doesn't make it the best, and using the most popular tool doesn't make the best programmer and subsequently the best code.
Both databases have JDBC and ODBC drivers, meaning both can be accessed by business systems requiring an RDBMS. They both use SQL, granted both have variations in the SQL statements as do all RDMBSs (but this should be a non-issue for new development as the differences are not great).
There is one area I think will differ greatly, and that is in database/schema design. Most/many MySQL-Java shops I have seen have poor database designs, especially when the Java programmers rely too heavily on Hibernate to create the design, which is almost always. I think Hibernate is a good tool if used appropriately, but there are too many cases of people using ORM ONLY to create their database, and don't think about the database design any other way. This leads to very poor and inefficient database design. Even at my present company, a high tech start up where much of the server side code and databases where built this way. The databases are now dragging their MySQL asses now that the volume of data is increasing. Not necessarily because of it being MySQL, but because the use of ORM ONLY to create the database design. I'm not saying that this can't happen in a Postgres shop, but I normally see more deliberate database designing where Postgres is used. Perhaps because it isn't quite as light weight it may require better designers to use it, which leads to better database designs. Similar to how C and C++ require more highly trained and deliberate programmers than Java in order to produce good code.
Flame on!
Re:why? (Score:5, Informative)
MySQL is better because I know how to use it and it works well enough. If I were to switch to Postgres, then I would have to spend time learning it.
My manager would rather me move some other feature forward rather than replace database A with database B.
When we hire somebody new, it is easier to find candidates who already know MySQL. That matters too.
-ec
Re:Yes, but.... (Score:3, Informative)
They don't have anything (that I know of) that does the same kind of multi-backend thing that MySQL does
Regular Oracle tables and index-organized tables have completely different physical implementations, and bitmap indexes have a completely different physical implementation from regular indexes. They're all ACID, though.
facebook uses it (Score:5, Informative)
...I saw in one presentation their chief architect did. They had no complaints about it; apparently it scales brilliantly as long as the db schema is very simple.
For heavy-weight databases though, I gather it's not so good.
Re:Yes, but.... (Score:3, Informative)
Since they have overlapping niches, probably some of Oracle's products, particularly at the low end, take a hit from MySQL. Since even their free low-end products are designed to be compatible with and provide an upgrade path to their pricier DB offerings while its probably as easy to go from MySQL to PostgreSQL-based EnterpriseDB, DB2, or MS SQL as from MySQL to Oracle, their certainly might be reasons why they'd rather, over the long term, either phase MySQL out or evolve it into something very different than it is now. They might not, too; its fairly popular, does have a commercial presence which (I assume) is profitable, and may bring enough to be worth keeping around even if it hurts sales of other Oracle products.
Re:why? (Score:1, Informative)
I was actually involved in the decision at my business to switch from Postgresql to MySQL, and documentation ended up being the deciding factor. Now I've been using Postgresql personally and professionally for years, and I love the database, but two days with the documentation for the various clustering / replication sub-projects was enough to make my brain hemmorage. It's like they took legitimate documentation in some language, randomly truncated one sentence every other paragraph, and then ran the whole thing through a series of babelfish translations before posting it to the web. Compare that with the MySQL online documentation and numerous third-party publications and you end up hard pressed to argue for Postgresql once you reach the boundaries of your experience and need to rely on published documents to move forward in a timely fashion.
Re:why? (Score:4, Informative)
I can't imagine a scenario when I would chose to use MySQL (or MS SQL, for that matter).
I work for a Fortune 500 company. We use MySQL with J2EE and Hibernate in a production environment. Postgres would be our fall-back option if MySQL ever stopped doing the trick for us, but it scales well to thousands of users.
MySQL can easily be configured for use as a production-quality database. We also use Oracle and DB2 on an i5 for certain purposes, but our biggest app (in terms of company scope and $$) employs MySQL in the back-end.
That's why :-P
Re:why? (Score:3, Informative)
Fewer than offer MySQL, but enough that if PostgreSQL is the right DB choice for technical reasons, this just means you don't choose one of the hosting providers that don't support PostgreSQL, not that you choose MySQL.
(Assuming, of course, that you are building a web app where a discount shared hosting service is the right choice to start with; of course, not all apps for which a DB is needed are web apps, and not all web apps are those for which a discount shared hosting service makes good sense.)
But, sure, if you are artificially constrained to choose from one of set of hosting providers, none of which offer PostgreSQL and some of which offer MySQL, that's certainly a reason to choose MySQL. But that sounds like a result of a bad planning process, not something that should ever occur in the implementation of a new application.
Re:why? (Score:3, Informative)
PostGres competing with MySQL is like alpha competing with Intel.
Even though IMO PG is technically superior in every way, MySQL is more widely supported, both directly and indirectly as a backend for many systems.
In fact, I am building a personal website and I want to add a message board. Guess which database backend every single one of them supports?
And until everyone else above me in the supply chain overcomes their collective inertia, my hands are tied because as of yet I do not have sufficient temporal resources (i.e. spare time) to implement a board myself.
Re:why? (Score:4, Informative)
For instance if you never delete from a table there's no need to bother trying to vacuum it.
Not quite. Because of the way postgres operates (MVCC) UPDATEs will result in space appearing in table structures too. With an MVCC based DB nothing is updated in-place (actually, in any good DB nothing is updated in-place, but with MVCC this is more obviously implied by any good description of how things work with multiple distinct transactions present). When a row is updated new version is added and the old version is removed when the transaction is complete and no other transactions might refer to the old copy. This has significant advantages for some use cases and loads, and some disadvantages in other
The wikipedia page (http://en.wikipedia.org/wiki/Multiversion_concurrency_control) isn't a great description though there is a bit more relevant information in http://en.wikipedia.org/wiki/Snapshot_isolation [wikipedia.org].
I've not used postgres much in anger, so I'm no expert, but personally I thought that being able to manually schedule cleanup was a good idea performance wise.
Re:why? (Score:3, Informative)
I asked in what scenario it would be a superior option
I'm with you on that - in the last 7 years, I've used PostgreSQL exclusively for projects that were under my control. I'm subscribed on the mailing lists, I know about all the misconceptions regarding performance, and I know that MySQL is nowhere near as reliable and professional as PG.
But since you asked: I'm still running MySQL on most of the servers, and the reason for that (the only reason) is third party support. When you're installing a web-based CMS, or bulletin board, or bug tracker, or gallery, or whatever, chances are it will work better with MySQL. The people who write these things are often more familiar with MySQL, and Postgres support (if available) is sketchy at best. Try Drupal with PG, for example. The core modules work fine, sure, but as soon as you start installing some of the more exotic modules you'll run into trouble.
I've given up trying to force these applications to play nice with Postgres. They can use MySQL if they have to, and I'll stick to a real database for data that matters.
CJ
Re:PostgreSQL (Score:3, Informative)
It is not that easy - Postgres right now is lacking in the area of replication and thus fails as a database for all those MySQL users that require replication for scaleout.
Postgres replication options usually are active-passive (WAL shipping solutions that recover the slave) or are trigger-based and syncronos such as Slony-I.
What MySQL users usually require is replication to be losely coupled and asynchronous in order for it to become a viable scaleout option.
Re:why? (Score:4, Informative)
Because MyISAM, which is what most MySQL users use, is not fucking ACID compliant.
Take a look [mysqlperformanceblog.com] at the potential problems. Take a look at recommended use cases: "Tables which contain read-only data, throw-away data, data which can be quickly re-generated." Are you bloody kidding me!?
I can't believe my eyes when I read questions (or posts) such as the above. Because it betrays your huge ignorance. Every man and his dog has heard of MySQL and is probably using it, true. But it's also true that most of them have no bloody idea of what ACID is or why it's desirable, or that MySQL with its MyISAM tables goes completely happy-go-lucky on the whole concept. These are the same people who probably don't bother using foreign keys, or have never even heard of transactions, or can't think why they'd need them.
Sure, MySQL offers InnoDB, which is supposed to rectify those issues. But how does it go about it, may I ask? Why, take a looksy [mysql.com]. It's an entire bloody SECTION of the manual, which goes to great lengths to explain all kinds of issues and exceptions to the rules and whatnot. Summary: "It locks rows like this, except if it's a full moon then you have to blink your left eye every five seconds, and if you're doing a particular SELECT you need to stand on one leg, except on Fridays when it's the right leg."
Now compare with the Postgres manual page describing their ACID implementation [postgresql.org]. It's a couple of pages, keeping things clear and simple, so that anybody can understand them.
Not to forget that if you want InnoDB you give up full text search capabilities. And you ask why we should use Postgres? Really?
MySQL has lowered the bar for complexity of use. But in doing so it has facilitated DB access to a whole bunch of people who don't have any idea what they're doing, or don't really care about data integrity. It's fast and it works most of the time so it's alright, yes? Yes, granted, nobody will care much if your personal blog goes tits up because of MySQL. But I expect people will care if a database in which data actually counts for something has problems. And in such cases I expect people will want a real database.
Re:PostgreSQL (Score:2, Informative)
Yes. And Slony is also difficult to administer and easy to break.
Postgres is very much lacking a simple replication solution. If you're in the cloud, it's far more likely you're going to have many many smaller database spread across many machines. You need to be able to bring up groups of 3 (minimum) machines that cluster an entire database quickly and easily. You don't need all the flexibility of Slony, and you certainly don't need it's administration headaches.
I can't even imagine trying to administer 10's of databases with Slony, not to even think about 100's or more.
Re:PostgreSQL (Score:4, Informative)
Slony-I is a dreadful hack that misuses triggers, and doesn't scale past a few nodes.
I'm sorry, but Slony-I is not a serious replication solution.