Thanks to everyone who signed up and attended the webinar I gave this week with Tim Callaghan on Scaling MySQL. For those who missed it and are interested, the video and slides are now posted here.

A brief description of the webinar is also below.

MySQL implementations are often kept relatively small, often just a few hundred GB or less. Anything beyond this quickly leads to painful operational problems such as poor insertion rates, slow queries, hours to days offline for schema changes, prolonged downtime for dump/reload, etc. The promise of scalable MySQL has remained largely unfulfilled, until TokuDB.

TokuDB v5.0 delivers

• Exceptional Agility — Hot Schema Changes allow read/write operations during index creation or …

 
This version includes support for “SELECT … FOR UPDATE” as well as displaying table “create time” and “last update time” via “SHOW TABLE STATUS”. The release also addresses a number of other bugs and fixes such as “point update” and “replace into” deadlocks. For more details, see the release notes section of the user’s guide, available here. To get the latest version of TokuDB (free for evaluation, development, testing, qualification, experimentation, and POCs ) click here. Starting with this release, we’ve also streamlined the installation process by creating a combined tarball that includes both MySQL and TokuDB.

Note that we’ll be hosting an upcoming webinar on November 15th for those who want to learn more about TokuDB in general as well as …

I’ll be talking about How Fractal Trees Work  today at MIT in the Computational Research In Boston and Beyond (CRIBB) seminar (http://www-math.mit.edu/crib/2011/nov4.html). The talk is at 12:30 in the Stata Center room 32-141.  Pizza available before.

This talk will be academically-oriented (not much marketing).  The abstract is as follows:

Most storage systems employ B-trees to achieve a good tradeoff between the ability to update data quickly and to search it quickly.  It turns out that B-trees are far from the optimimum in this tradeoff space. I’ll talk about Fractal Tree indexes, which were developed in a collaboration between MIT, Stony Brook, and Rutgers.  I’ll talk about how they work, and what their performance bounds are.  My startup, Tokutek, is commercializing fractal tree …

MySQL implementations are often kept relatively small, often just a few hundred GB or less. Anything beyond this quickly leads to painful operational problems such as poor insertion rates, slow queries, hours to days offline for schema changes, prolonged downtime for dump/reload, etc. The promise of scalable MySQL has remained largely unfulfilled, until TokuDB.

Time: 2PM EST / 11AM PST

REGISTER TODAY

TokuDB v5.0 delivers

• Exceptional Agility — Hot Schema Changes allow read/write operations during index creation or column/field addition
• Unmatched Speed — Fractal Tree indexes are optimized for index insertion performance
• Maximum Scalability — Fractal Tree index performance scales even as the primary index …

I’ve been benchmarking and testing TokuDB for a few months now. One goal of benchmarking is to understand what is limiting the performance of a particular configuration. I frequently use “show engine [innodb/tokudb] status;” from within the MySQL command line client as part of my research.

As I run most of my benchmarks on InnoDB as well as TokuDB, I noticed that there are significant differences in the way each present status information. InnoDB returns a single row, with various sections and carriage returns to maintain readability. In contrast, TokuDB presents one piece of status information per row (currently 139 rows as of TokuDB v5.0.5). This is an important distinction if you want to parse, compare, or store discrete status values. Here is sample output from each engine. I’ve cut out portions of each to maintain readability.

InnoDB plugin v1.0.13

mysql> show engine innodb status; …

Review of Thursday’s Cloud Events in Boston

Everyone is well aware by now of the EC2 outage that Amazon had back in April and it would have surprised no one if that high profile had put a damper on cloud adoption. But judging what we heard yesterday at Boston’s two cloud events (MassTLC’s Cloud Computing Summit and Vilna’s Moving Your Data to the Cloud Panel), cloud solutions can work just fine. For example, there was the customer story told by Douglas Kim, Managing Director, Global Head, PaaS & Cloud Computing at PegaSystems. Pegasystems is a Boston tech company that started …

In my last post, we talked about the read/write tradeoff of indexing data structures, and some ways that people augment B-trees in order to get better write performance. We also talked about the significant drawbacks of each method, and I promised to show some more fundamental approaches.

We had two “workload-based” techniques: inserting in sequential order, and using fewer indexes, and two “data structure-based” techniques: a write buffer, and OLAP. Remember, the most common thing people do when faced with an insertion bottleneck is to use fewer indexes, and this kills query performance. So keep in mind that all our work on write-optimization is really work for read-optimization, in that write-optimized indexes are cheap enough that you can keep all the ones you need to get good read performance.

…

It’s Friday again (already?) and as usual, we have a free ticket for Percona Live London. This time Tokutek is doing the honors of running the contest and selecting the winner. Instructions for entering the contest are on their blog, at the top of my recent guest post about covering indexes.

Did you know that the following query actually performs a JOIN? You can’t see it, but it’s there:

SELECT the_day, COUNT(*), SUM(clicks), SUM(cost)
FROM ad_clicks_by_day
WHERE the_day >= …

Review of the O’Reilly Strata Making Data Work Conference

(reprinted from my guest blog for the Cloud Council of 7)

Monica Rogati of LinkedIn told a story of the early days at the firm, when the reporting system consisted of a single server under someone’s desk. One day, someone needed an Ethernet cable and unplugged the machine from the data outlet in the wall. LinkedIn’s data reporting, its life blood, instantly came to a screeching halt.

The Push to the …