Slashdot Mirror
David Axmark Resigns From Sun
An anonymous reader writes "From Kay Arno's blog we see that David Axmark, MySQL's Co-Founder, has resigned. This comes on top of the maybe, maybe not, resignation of Monty. We saw earlier this year that Brian Aker, the Director of Architecture, has forked the server to create a web-focused database from MySQL called Drizzle. The MySQL server has been 'RC' now for a year with hundreds of bugs still listed as being active in the 5.1 version.
What is going on with MySQL?"
there's no need to start dicksizing about the type of databases you manage. no one is claiming that MySQL is the best database management system out there, or that it can handle any kind of application. but for a certain range of applications it's a very capable and well designed database server.
not everyone needs a multi-terabyte database. and the utility of a RDBMS is not defined by database sizes it can handle. MySQL is so popular precisely because most sub-enterprise businesses don't need anything as robust as Oracle. so MySQL is therefore a much more cost-effective solution.
That advice is only appropriate in the expected query results are small, on large tables using stored procedures can significantly reduce the load on the DB by not requiring it to handle open connections while a large amount of data is streamed to the remote client.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Hi!
We are still working on the first version of Drizzle. While folks are using it, I don't really recommend it at this point. When we feel like it is ready for adoption we will publicly start recommending it.
Cheers,
-Brian
You can't grep a dead tree.
Thanks slashdotters for being passionate about all topics FOSS and MySQL!
David's departure is in all ways amicable, and he will continue to be an ambassador for MySQL and for free and open source software in general. For some time already, David was working only part-time for MySQL. After about 25 years of working on MySQL and the projects that preceded MySQL, he very much deserves do whatever he pleases to.
Marten
SVP Database Group at Sun
(previously CEO of MySQL AB)
Don't use stored procedures.
That's a very narrow-minded statement. The application I maintain has an Oracle 10g backend, Pro*C middleware, and a Java fat client. The standard process for an action in the application is to ask the middleware to run a certain stored procedure in an Oracle package.
Given that this application is huge (I'm talking 1000+ tables, some with up to a million rows) and there are at least 1000 concurrent users, it's very convenient to have the logic on the server-side. Any code change to the client requires an outage (to replace the jar file), which is BAD if it's an emergency fix. By putting all the logic (and access to a vast amount of data) server-side, it reduces network traffic, allows easy rollbacks, and allows the support team to apply a fix without an outage.
Some more great things about our setup is that Oracle packages and triggers support networking. We have a publish/subscribe system tied to triggers such that when one user makes a change, it's instantly reflected on every other user's screen.
Obviously this solution isn't best for all situations, but it fits our needs very well. YMMV
Homonyms are fun!
You're driving your car, but they're riding their bikes there.
Does Sun have a competitive database? I ask because I don't know of any
"and the utility of a RDBMS is not defined by database sizes it can handle"
;).
:).
Actually there is some relevance.
If you needed a database gigabytes in size a few _years_ ago, MySQL would have been a really bad choice (it still is crap, just less so IMO).
For MyISAM:
You would have to configure it to get tables bigger than the default 4GB limit (there's a number of row limit and table size limit). Hope you don't make the new setting too small so you're still working in the place when those run out too
For Innodb:
Before the single file per table, if you're moving about gigabytes of stuff, you end up with one huge multigigabyte innodb table.
For both:
Adding an index was the same as "alter table" and involved making a copy of the table.
So let's say you have a 40GB table and 40GB of space free. No index add for you
Keep in mind if you have plenty of space free making a copy of a 40GB table does take time.
BTW concurrent inserts to an innodb table with an auto increment field were slow till only recently (well allegedly they've fixed that).
Well, there is this.
Youre joking right? PostgreSQL supports several replication engines which works fantastic great and it has been doing that for years!
You have:
PGCluster
Slony-I
DBBalancer
pgpool
PostgreSQL table comparator
SkyTools
Sequoia
You can read about what Skype use replication for PostgreSQL here:
https://developer.skype.com/SkypeGarage/DbProjects/SkypePostgresqlWhitepaper
And Slony for example is developed by Jan Weick, a PostgreSQL core team member.
Lots of press about a not to large event. I have been working less with MySQL over the past several years (as the company has grown). And when we got acquired we got to big for me (I like to know everyone in a company).
A huge part of my work have been spreading FreeSoftware/OpenSource and I will continue to do that. And tell about the MySQL story many times more hoping to inspire others to try to start FLOSS businesses.
And I hope to meet many of all the people who made MySQL such a sucess many times over the coming years. /David (who posts so seldom he does not remember his slash login/password..)