Computer Sweden has a couple of nice article on OpenSource, GlassFish and MySQL.

If I were Sun, I would be tempted to have this next MySQL User Conference be the last one, and replace it with the "Open Source Database" conference, and have it be about MySQL, Postgress, JavaDB, and such stuff.

I think Brian is right with his The Death of Replication story.... replication is very useful for many cases, but RDBMS (commercial and FLOSS) have done a fairly dismal job at getting multiple writers to scale decently economically. And modern companies just don't have piles of cash to throw at this, nor does that really scale on the web scene (speed of deployment, etc).

In this context, I'm not sure the new memory based MySQL storage engines coming out are so relevant, they might be fixing the wrong thing in the wrong place. They'll have their place for now, but it's not moving us forward really.

What needs to be fixed is distributed writes. And economically!

Brian Aker writes in his "PostgreSQL to scale to 1 billion users" post:
Backup is irrelevant for those of you who care about this discussion. LVM/ZFS snapshots are the rule of the land.

While I agree with most of Brian's statements in the article, I respectfully disagree with the statement above, especially the bolded part. Copy-on-write snapshots are EVIL for very large databases operating in a high I/O environment and backup, by no means, is entirely irrelevant. Please correct me if I am wrong but it is my understanding that both LVM and ZFS implement copy-on-write snapshots. Backup may be irrelevant for most sites but not for us.

If, however, by "irrelevant" Brian meant that not important in choosing one database over another, I can agree with that. Why? Because no one benchmarks …

I spent my Sunday working on my three presentations that I will be presenting at the upcoming MySQL Conference. About two hours ago, as I was reviewing my stuff, I told my lovely wife that I may talk in my sessions how replication for read scalability no longer makes sense in high traffic environments. I told her, I am probably going to vote in favor of investing in memcached vs read slaves for scaling reads.

Believe it, or not, she hammered me with all sorts of questions. I spent some time answering her questions. I scanned my brain to gather more evidence to support myself including that at work we are moving and staying away from replication as much as possible.

Then, I got busy writing the post about Facebook using MySQL replication to update Memcached. After publishing the post, I checked Planet MySQL and found …

A number of months ago, possibly a year ago, I wrote an internal letter to the MySQL internal discuss list with the title of "The Death of Read Replication". Ever since then I've been getting pinged internally to publish my thoughts on this externally.

Here goes :)

Read replication is going to be in use for many years into the future. There are plenty of reasons to use it, and plenty of setups where it will make sense.

All of the scripting, management daemons, and ease of use scenarios will not solve its problems though, and I am finding that users have either moved away from it, or more often, have reduced their need for it.

A few reasons:
Latency is painful to manage.
Lots of servers means more head count (both disks and in numbers of people to manage it)
In web usage, the rule of thumb is to keep your query number under 7, for this reason you try make more out of …

Faced with the challenge "to figure out a way for memcached servers to replicate data concurrently with the MySQL databases," across the country, Facebook came up with a clever solution of "embedding extra information in to the MySQL replication stream that allows [Facebook] to properly update memcached [servers] in Virginia."

This is very smart! I am curious about how they implemented this. I wonder if by "replication stream" they are just referring to binary logs. The article didn't mention whether they hacked MySQL to do synchronous replication as well, like Google. That would be really neat: synchronous replication that updates memcached.

Synchronous or not, the idea is still uber cool and I would love to see more …

For reference:
http://highscalability.com/skype-plans-postgresql-scale-1-billion-users

Here are some observations by me on the state of database usage in Web 2.0:
All major web 2.0 sites now use object caching (of one type or another)
Sharding and now Proxy style solutions are becoming commodity. They are everywhere.

What does this mean?

Replication is dead except for replicating for "application" needs.

Good News :)

For MySQL it encourages multiple engines. For Postgres I suspect their flexible index design will be useful. The "I replicated over here for a backup, or to run reports..." is still happening a lot. Multi-master replication is one scenario to achieve high availability (DRBD on the low end... you will go broke trying to deploy …

I’ve managed my first week (well 4 days) at my new employer PrimeBase Technologies. Another open source company, a different open source company, my second in succession . A company that actually has it’s parent roots in the commercial sector and this is now branching into Open Source and supporting the community.

While my departure from MySQL was really no surprise to friends within the MySQL community, just some shock of the accelerated timing. Actually it should not have been a shock to my employer either as I’d expressed clearly these intentions in two reviews in the past twelve months. My April Fool’s managed to shock and catch out many to continue this saga.

Our focus has been the …

Here are two basic tips for proper indexing ...Don't mess with datatypes, too often people refer to an attribute defining it as one datatype in a table and as another in different tables, this actually prevents index usage in joins (forget about FKs for this time ;)) See an example here. You could declare a function based index as a workaround, but why don't we all try to make it right?Put