[Updated: 2008-03-05 Jeremy writes to tell that I left out the provenscaling.com contact form submission on the 21st and the blank email with a pdf on the 27th]
[Updated: 2008-03-26 Rob Young from MySQL AB sent me an email on the 17th saying, "We are currently working to implement PayPal to cut down on the email interactions we have in place around our manual fulfillment process. Testing is going well and we should have this implemented in the next few weeks."]

Recently Proven Scaling decided to purchase a MySQL Enterprise subscription. We will be evaluating Enterprise to see if it’s knowledge base is valuable to our customers as a supplement to Proven Scaling’s consulting services.

The subscription process seems remarkably manual on MySQL’s part. It involves them sending us five emails (not counting the mysql.com registration), all of which are from different senders. Some are from people others are automated. Here is a …

Implementing MySQL database in 24/7 environments we typically hope for uniform component performance, or at least would like to be able to control it. Typically this is indeed the case, for example CPU will perform with same performance day and night (unless system management software decides to lower CPU frequency due to overheating).

This is also almost the case with Hard Drives - there are possible performance differences based on where data is stored on the disk, amount of remapped sectors etc. There is also database and file system fragmentation however these also tend to accumulate in predictable fashion.

If you have RAID controller this well may not be the case - to protect your data RAID controller may implement bunch of algorithms which can affect performance dramatically.

For example speaking about PERC5 (LSI MegaRaid) - Pretty typical controller from Dell installed on PowerEdge 1950, 2950 etc you should be …

Our two part article on migrating a MySQL database to Oracle features in Database Journal in January and February of this year.  Take a look and please post your comments!

Migrating From MySQL To Oracle - Part I

Migrating From MySQL To Oracle - Part II

SCO files reorg plan with bankruptcy court. Acquia unveils Drupal commercialization plans. Microsoft expands support for web standards. (and more)

The SCO Group Files Formal Reorganization Plan With Bankruptcy Court, The SCO Group (Press Release)

Acquia Unveils Roadmap to Commercially Supported Drupal, Acquia (Press Release)

Microsoft Expands Support for Web Standards, Microsoft (Press Release)

Sun Microsystems Announces New Role Manager Software; Provides Overview of New Governance, Risk and Compliance …

Sorry for the delay, now on to range queries and lenient updates.  Let’s call them queries and updates, for short.  So far, I’ve shown that B-trees (and any of a number of other data structures) are very far from the “tight bound.” I’ll say a bound is a tight if it’s a lower bound and you can come up with data structure that matches it.

So how do we match the bandwidth bound for queries and updates?  I already mentioned in passing how to do this, but let’s look more closely.

Fast Updates

The way to get fast updates is to log them.  You can easily saturate disk bandwidth by writing out the insertion, deletion and update requests with no index. 

A query now will typically start by sorting the data.  Even a point query requires looking at all the data, but a range query requires looking at all the data log times (in order to sort it), or using a large amount of extra …

We got a couple of new servers at Solfo recently which showed me one of the reasons virtualization is so popular now: Servers are too fast!

The "standard issue" CPU is now a quad-2.5GHz CPU, so in each server we have 20 GHZ CPU and 32GB ram (at less than $50 per gigabyte it's too cheap to not just fill it up and be done upgrading). Just a few years ago the CPUs we were getting were "only" dual 2GHz, for ~8GHz CPU per box. That's a big increase!

In each "tier" of the application (app servers, db servers, search servers) our main reason for having more than one or two servers is redundancy / high availability - never lack of CPU and rarely because we need more memory.

Here's from one of our webservers (virtualized with Xen with 6 of the 8 CPUs on the "real" hardware).

The big exception is the MySQL servers where we get constrained by I/O so we need a single …

Hmm... understandable from a pure business perspective, but not the best outcome for this engine. It didn't have the highest of profiles and buzz, but I know that users were trying it and liked some of its features. Orphaned open source code tends to not go anywhere, unless someone else picks it up and runs it as a project. See the original announcement with links/refs below:
Update on solidDB for MySQL
By: Dhiren Patel (dhiren) - 2008-03-03 12:12

Dear Community Members,

As you may know, Solid was recently acquired by IBM to strengthen IBM?s Information Management Data Server offerings. As a result, I want to take a moment to give you an important update on the status of solidDB for MySQL.

Those …

I'd call this the 3rd strike and everybody knows what happens next

Marc Fleury has some good answers to the most clueless industry reporter around, starting with:
Spring is touting itself as a JBoss replacement. Smart PR, but false. Spring is a development framework comprising wrappers and dependency injection on top of Hibernate and Tomcat runtimes, both developed, and monetized by JBoss.

You can drop some balls, no one can keep track of what's going on in Open Source land, it's difficult enough to track what's going on in MySQL, Drupal, Virtualization and Distribution land but if you realize you don't have the whole picture (like not …

Sorry for the delay, now on to range queries and lenient updates.  Let’s call them queries and updates, for short.  So far, I’ve shown that B-trees (and any of a number of other data structures) are very far from the “tight bound.” I’ll say a bound is a tight if it’s a lower bound and you can come up with data structure that matches it.

So how do we match the bandwidth bound for queries and updates?  I already mentioned in passing how to do this, but let’s look more closely.

Fast Updates

The way to get fast updates is to log them.  You can easily saturate disk bandwidth by writing out the insertion, deletion and update requests with no index. 

A query now will typically start by sorting the data.  Even a point query requires looking at all the data, but a range query requires looking at all the data log times (in order to sort it), or using a large amount of extra …

In a previous post I explained about BCP. I have just finished my latest and nearly final test, and all worked as expected. For about an hour certain front end servers where hitting a database shard in 1 datacenter while the rest of the front ends hit the same shard in another datacenter.

What makes this incredible is that now data from mySQL can be close to geo-graphic locations of the end user, without having to make changes to the front end application. So fail over is silent from a database perspective if an entire datacenter is down. Actions outside of the application are also replicating seamlessly and in order. Latency is high but the goal is not to have a WWW in one datacenter talk to a shard in another datacenter. So, latency is in effect not an issue especially if one uses Akami-DNS to geo-graphically loadbalance your user …