Entirely in Spanish… I turn back to face the students. 120 students are waiting for me to speak. I realize that I don’t even know how to say simple constructions like “x plus y” or let alone “advanced data structure” or “order log log amortized time complexity.”

Is this a newfangled anxiety dream? Can this replace the tried and true: I’m in front of the class but I forgot to put on my pants? Can this replace the classic: I’m back in high school and have one just more class to take; but I haven’t been attending and don’t know what the material is about?

But I’m not dreaming. This actually happened.

This real-life anxiety dream, the prehistory of Tokutek, and the Imre Simon Test of Time Award come together in the following story.

The Latin American Symposium on Theoretical Informatics (LATIN 2012) is giving its first ever “Imre Simon Test of Time Award” to the paper deemed most influential from among all those published in LATIN at least ten years earlier. The prize is described on the conference website.

Martin Farach-Colton and I just learned that we are getting this award for our paper “The LCA Problem Revisited,” which we presented at LATIN 2000.

Although our paper doesn’t discuss Fractal Trees, cache-obliviousness, or even MySQL, we probably couldn’t have started Tokutek if we hadn’t written this paper first.

Here’s the story in (semi) brief.

In 1999 Martin and I taught a week-long course on advanced data structures at the University of Buenos Aires. We aimed to show that advanced data structures—which are frequently viewed as unwieldy and not very pretty—can be recast as things of beauty. In preparation for our course, we revisited some classic data structures and wrote several papers, including this one.

It is no exaggeration to say that this course in Buenos Aires changed our lives. Afterwards, Martin and I began developing I/O-efficient and cache-oblivious data structures (e.g., cache-oblivious B-trees, packed-memory arrays) and Bradley joined the effort soon after (e.g., Fractal Trees).

Need I mention that on the first day of class, Martin and I learned that we were speaking the wrong language.

Unbeknownst to us, the university had advertised that the class would be conducted in Spanish. We had prepared in English. But students and professors had showed up from all over Argentina, and we had no alternative but to switch languages. Martin speaks Spanish natively, but it was trial-by-fire for me since my rudimentary Spanish didn’t include a single technical word. Each morning, in preparation for class, Martin taught me the vocabulary that I would need to get through the day.

The class was a success and has since become a great memory.

So that’s the story. The bottom line is that Martin and I are thrilled that this paper, which came out of that class, has been recognized by the LATIN conference.

The conference offers a great overview of the big data space, with tracks on Data Science, Business and Industry, Visualization and Interfaces, Hadoop Applied, Hadoop Tech, Policy and Privacy, and Domain Data. With all of the “NoSQL” buzz and sessions at the show (Hadoop gets two tracks!), we are glad to be able to attend as a representative of the “NewSQL” community. We’ll be showing just how much MySQL, with the right storage engine, can scale to take on Big Data while giving up none of the power of ACID, familiar SQL interfaces, rich indexes, high insertion rates, and flexible schema.

If you will be there, please stop by to say hello! And please vote for us too (what can we say, it’s an election year all around).

The summit was well attended, with 350 registrants and keynotes from prominent MySQL users such as Mark Callaghan. The coverage was quite broad, with presentations running the gamut from grad students (complete with bodyguards and intimidating academic advisors) to established companies such as StreamBase. The sponsor list was an A-list this year as well, with EMC and Microsoft being the two biggest backers.

There were far too many and diverse topics to write about all of them. That said, here were a few of the notable ones.

Keynote #1: Johannes Gehrke (Cornell): Declarative Data-Driven Coordination

Johannes Gehrke of Cornell kicked off with the first keynote on Declarative-Driven Coordination. His methodology shed light on an alternative to out-of-band communication. The presentation focused on how to successfully handle entangled queries.

More Sleep for Tom and Meg if They Can Just Coordinate

In brief, what he showed is a way for someone to see if their friend is on a flight and have the database go about satisfying mutual constraints. With a proof that is outlined in his Sigmod paper, his main theorem is that any schedule that is entangled-isolated is also oracle-serializable. It’s a clever approach, as long as one’s set of friends being entangled remains small.

Keynote #2: Mark Callaghan (Facebook): Performance is Overrated

The room got a little quiet when Mark took the stage. Some people were expecting a possible rehash of this summer’s brouhaha between Mike Stonebraker and Facebook on the fate of MySQL. But, instead Mark jumped into some very practical discussions about managing MySQL at scale.

First, he noted that manageability needs more attention since…

• The cost of extra hardware can be predicted
• The cost of downtime cannot
• Downtime comes in many forms (server down and server too busy)

For Mark, manageability has a number of meanings. This includes the rate of interrupts/server for the operations team. Mark finds that while the server count grows quickly, his operations team grows slowly. Hence, it is imperative that the quality-of-service improve over time (i.e., Does work get done? Does work get done on time?).

Mark and his team use MySQL for a number of reasons. First, it was there when Mark arrived. Second, Mark and his team made it scale 10x. Finally, Mark likes MySQL for OLTP.

As Facebook has grown though, so have the number of servers. This is due to “Big Data” x high QPS. Hence, they have had to add servers to add IOPs. To address this, Mark noted that flash memory (SSD) is very interesting as are (we blush) write-optimized databases.

The last part of his presentation focused on advice for scaling: More Data, More QPS. His tips were quite straightforward:

• Fix stalls to make use of capacity
• Don’t make MySQL faster, make it less slow
• Improve efficiency to use less
• Repeat

 Additional details can be found in Sheeri’s excellent live blog of the presentation.

New Tools and Systems Session: Willis Lang (University of Wisconsin): Energy-Conscious Data Management Systems

Just as Mark stressed that performance isn’t everything when he spoke about management, Willis Lang pointed out another key concern.  His slides noted that “three decades of database research has optimized for the highest possible performance possible regardless of energy consumption.” (We agree and have written about this topic as well).

Willis and his team have been looking at various techniques for addressing this such as using variable speed disks. He has been systematically studying the power/performance trade-offs of hardware components. The preliminary memory-based results showed that interesting trade-off opportunities exist if one rethinks database design principles. His presentation focused on the improvements that can be seen with memory parking. Additional details on his research can be found here.

As mentioned previously, there were many good talks — much more could be written about the event. Other interesting speakers included David Karger who introduced Dido, which seeks to make database manipulation as easy as document editing, and Alvin Cheung whose Pyxis project eases application development with automatic code partitioning based on application and server characteristics.

Kudos to Samuel Madden (MIT) and Ugur Cetintemel (Brown University) for organizing the event. Additional details can also be found via the Twitter hashtag #nedb12 and the event homepage.

Throughout my career I’ve been involved with maintaining the performance of database applications and therefore created many benchmark frameworks. At Tokutek, an important part of my role is measuring the performance of our storage engine over time and versus competing solutions. There is nothing proprietary about what I’ve created, it can be used anywhere.

My presentation will cover how I created the benchmark infrastructure at Tokutek:

• Hardware and software considerations (including physical vs. virtual)
• Selecting benchmarks
• Capturing detailed information during the benchmark
• Automation
• Storing results
• Visualization
• Trend analysis
• Continuous integration (monitoring the performance of future versions)
• Self-service (let people get the information they want)

Track: Tools
Experience level: Intermediate

Tokutek is also a sponsor of the show and will have an expo booth. So, I hope to see you at my talk and/or at our booth.

The results are shown below. At the end of the test, TokuDB’s insertion rate remained at 17,028 inserts/second whereas InnoDB had dropped to 1,050 inserts/second. That is a difference of over 16x. Our complete set of benchmarks for TokuDB v5.2 can be found here.

We developed the iiBench benchmark to measure performance for a use case that occurs commonly in production applications, such as online advertising, social media, and network management.

iiBench simulates a pattern of usage for always-on applications that:

• Require fast query performance and hence require indexes
• Have high data insert rates
• Cannot wait for offline batch processing and hence require the indexes be maintained as data comes in

Note that iiBench was created as an open-source benchmark, which allows others to freely use it, extend it, and contribute their changes back. We originally unveiled the benchmark in the context of a challenge issued at the 2008 OpenSQL camp. Since then, iiBench has been downloaded and used many times, and ported by the community (in this case, Mark Callaghan) to a Python Script.

Please let us know any feedback you have on iiBench. For additional information on…

• iibench overview click here
• TokuDB version 5.2 Overview click here
• TokuDB version 5.2 Performance, including iibench, SysBench, Compression, and TPCC-like, click here

This version offers performance enhancements over previous releases, especially for multi-client scale up and point queries, and extends the cases where ALTER TABLE is non-blocking, in particular adding Hot Column Rename.

TokuDB v5.2 maintains all our established advantages: fast trickle load, fast bulk load, fast range queries through clustering indexes, hot schema changes, great compression, no fragmentation, and full MySQL compatibility for ease of installation. See our benchmark page for details.

Multi-client workloads

In TokuDB v5.2, we have reworked our locking scheme to better support multi-client workloads, and as always, we have focused on large databases. How did we do? Let’s check out some benchmark numbers.

SysBench

This is a SysBench comparison of InnoDB 1.1.8 and TokuDB v5.2. Prior to the run we started the database from a cold back-up (the cache is empty at the beginning of the 1 client thread run) and ran for 1 hour at each number of client threads. The following graph shows a significant performance improvement (10%-60%) at all measured levels of concurrency. The values shown are the average transactions per second for the final 15 minutes of the benchmark.

Additional details on the software settings for Sysbench can also be found in the Appendix at the end of this page.

TPCC

This is a TPCC-like comparison of InnoDB and TokuDB v5.2 on a 5000 warehouse database. The horizontal axis is the number of clients, the vertical axis shows throughput (New Order Transactions/10 seconds). Our multi-client work brings us to parity with InnoDB for this test.

Other key improvements

Both the Sysbench and the TPCC-like benchmarks have strong point-query components. Our improved performance over InnoDB, even with one client, shows that we are now outperforming InnoDB for point queries, at least in these tests. We’ll be blogging more specifically about point query performance so stay tuned. One way we achieve better point query performance is to have a different read-block size and write-block size. I’ll explain what that means in later blog posts, but one consequence is that read-intensive loads on RAIDed disks now perform many fewer I/Os.

In other news, we previously released Hot Indexing (HI) and Hot Column Addition and Deletion (HCAD). In both cases, the downtime of these Alter Table operations goes from hours to seconds.

In v5.2, we have added Hot Column Rename to the suite of online operations we support. You’ll be able to change the name of a column in a matter of seconds, just as you can now add or delete columns. We have also made Optimize Table hot, but it’s important to note that in TokuDB, Optimize Table only flushes background work, such as that produced by a column addition or deletion. It does not rebuild indexes, nor does it need to, because TokuDB indexes don’t fragment.

Summary

TokuDB v5.2 offers great scaling with increasing client thread count, improved point query performance, and Hot Column Rename. In the next couple of weeks, we’ll be posting more performance information, so stay tuned. TokuDB v5.2 is available for download.

Appendix – Configuration Details

Hardware

Centos 5.7; 2x Xeon L5520; 72GB RAM; 8x 300GB 10k SAS in RAID10.
TokuDB (running MySQL 5.1.52) is configured to use 36GB cache,
and InnoDB (running MySQL 5.5.16) with 52GB cache.

The difference is because InnoDB uses direct I/O whereas TokuDB reserves space for the OS cache.

TokuDB MySQL Config File (TokuDB v5.2 on MySQL 5.1.52)

[mysqld]
max_connections=400
table_open_cache=2048

InnoDB MySQL Config File (InnoDB v1.1.8 on MySQL 5.5.16)

[mysqld]
innodb_flush_method=O_DIRECT
innodb_thread_concurrency=0
innodb_log_file_size=1900M
innodb_log_files_in_group=2
innodb_file_per_table=true
innodb_log_buffer_size=16M
innodb_file_format=barracuda
innodb_buffer_pool_size=52G
innodb_flush_log_at_trx_commit=1
max_connections=400
table_open_cache=2048

TPCC
All TPCC-like benchmarks were run with the following command line:

tpcc-mysql/tpcc_start localhost tpcc root 5000 \
         ${num_threads} 10 3600

Sysbench
All sysbench benchmarks were run with the following command line:

sysbench --test sysbench-0.5/sysbench/tests/db/oltp.lua
--oltp_tables_count 16  --oltp-table-size 50000000 --rand-init on
--num-threads ${num_threads} --oltp-read-only off
--report-interval 10 --rand-type uniform --mysql-socket
/tmp/mysql.sock --mysql-table-engine tokudb --max-time 3600
--mysql-user root --mysql-password --mysql-db sbtest
--max-requests 0 --percentile 99 run

In addition, the conversation spilled over late into the night as we made our way over to nearby Mead Hall afterwards for a few drinks, some food, and to continue the discussion.

The presentation is available here.

As a brief overview – most databases 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 optimum in this tradeoff space. This led to the development at MIT, Rutgers and Stony Brook of Fractal Tree indexes. Fractal Tree indexes improve MySQL^® scalability and query performance by allowing greater insertion rates, supporting rich indexing and offering efficient compression. They can also eliminate operational headaches such as dump/reloads, inflexible schemas and partitions.

The presentation provides an overview on how Fractal Tree indexes work, and then gets into some specific product features, benchmarks, and customer use cases that show where people have deployed Fractal Tree indexes via the TokuDB^® storage engine.
 

Issues addressed:

• Support complex and efficient indexes at 100+ million rows.
• Predicable and consistent performance regardless of data size growth.
• Fast recovery.

Ensuring Predictable Performance at Scale

The Company:  FictionPress operates both FictionPress.com and FanFiction.net and is home to over 6 million works of fiction, with millions of writers/readers participating from around the world in over 30 languages

The Challenge: FictionPress offers a number of interactive features to its large user base. These include discussion forums, in-site messaging and user reviews. FictionPress made the decision to build its own discussion forums to meet its strict security and performance requirements. Xing Li, CTO of FictionPress, noted that the site “needs to host hundreds of thousands of forums. Existing forum software doesn’t do this while meeting our performance and security targets.”

To ensure the real-time responsiveness of the forums, FictionPress needs the ability to create and efficiently maintain complex indexes and be able to support millions of small rows. In addition, it needs the ability to index them with minimal impact to resource costs and performance. “The only way to make this all work and provide a good customer experience is to guarantee that we can deliver a flat predictable performance with our database back-end even as the number of rows crosses the 100 million mark,” according to Li.

FictionPress considered InnoDB, the default storage engine for MySQL, but it did not offer predictable performance at scale. Indexes became dramatically slower as the number of rows increased, causing a reduction of both read and write performance. InnoDB also did not offer the performance-enhancing feature of multiple clustering indexes.

The Solution:  FictionPress uses MariaDB and TokuDB to manage its discussion forums, reviews, and in-site messaging systems.

FictionPress installed TokuDB in a Linux environment with dedicated hardware. Each configuration has a single master with multiple read slaves. “TokuDB’s high write concurrency and support for multiple clustering indexes gave us the freedom to design and deploy better performing queries at scale,” according to Li. This was important to FictionPress as its environment is continually expanding.

The Benefits:

Predictable Performance: “While raw performance is important, the predictability of response time as one scales the system was our focal point” according to Li. “InnoDB can only have one clustering index, but TokuDB gives you basically an unlimited number. In addition, both MyISAM and InnoDB slow down with many indexes on databases of our size. MyISAM also causes replication lag due to concurrency. In the end, TokuDB gives us predictability, performance at scale, and more flexible indexing without the limitations found in other MySQL options.”

Cost: “To get additional performance, one can always throw hardware at the problem,” according to Li. “By utilizing TokuDB instead we improved scalability and at the same time saved on costs for additional server hardware that would have been required if TokuDB was not in the picture. In addition, we saw an 8x size reduction in disk space compared to MyISAM due to improved compression. The hardware cost saving made moving to TokuDB an easy decision.”

Crash Recovery: FictionPress had been using MyISAM initially. “We needed a replacement for MyISAM for small BLOB data,” according to Li. “In fact, we wanted to move away from MyISAM whenever possible to shorten its long crash recovery. InnoDB was an option but TokuDB offered better compression and a smaller storage footprint for both core data and index data for our own data sets.”

Hot Schema Changes: “For performance reasons we need a lot of indexes but also need to add and maintain these indexes quickly,” according to Li. “TokuDB is the only MySQL solution I found that offers Hot Schema changes such as Hot Indexing. Hot Schema changes are a powerful capability which we use to minimize downtime during system-wide upgrades and shorten our application/schema development cycle.”

The MySQL council advocates for the MySQL community, and needs community leaders to help address issues such as keeping the bug database open and keeping the user conference from fragmenting.  The council tries to help solve issues that the community faces with Oracle, IOUG, or anyone else.  The council comprises four to six members representing a mix of consultants, volunteers, community activists, developers, and vendors.  The council is not meant to replace any existing grass roots organizations, rather it may be helpful for gaining visibility for their issues.

As a council member, you would be asked to participate in meetings (they’ve been about once a month by phone, but there may be a face-to-face meeting).  You will also be asked to help promote speaking and volunteering communities.  The term of office is one calendar year, and you receive a one-year IOUG membership, discounted event registration, and a “MySQL Council” pin.

Please consider applying via this IOUG link.

It’s almost the end of the year – that means holiday cards, shopping, cooking, parties, and the inevitable year-end top lists (including gems like this one).

In the spirit of end of year list making, we fed our 60+ blogs this year through Google Analytics to find out what our own top ten blogs were (outside of product announcements). So if you missed an episode of the View (TokuView that is) we’ve got a Tokutek Top Ten for you (spoiler alert – they are mostly technical):

10. Cage Match: OldSQL, NoSQL and NewSQL – References to mud wrestling priests and Lady Gaga heat up the debate over MySQL and its variations and alternatives.

9. Indexing, the Director’s Cut – Zardosht Kasheff took his indexing talk on the road this year to the Boston, SF, and NY MySQL meetups. This was from the SF meetup.

8. The Challenges of Big Databases with MySQL: OOW11 Presentation – A popular conference talk from Tokutek co-founder and Chief Architect Bradley Kuszmaul.

7. From Under the Desk to The Cloud – A Review of the O’Reilly Strata Making Data Work Conference.

6. MySQL Partitioning: A Flow Chart – There are almost always better (higher performing, more robust, lower maintenance) alternatives to partitioning.

5. A Case for Write Optimizations in MySQL – Suggested API improvements to increase the performance of writes, and more specifically, updates.

4. Compression Benchmarking: Size Vs. Speed (I Want Both) – TokuDB achieves the highest level of compression while out-performing InnoDB.

3. Write Optimization: Myths, Comparison, Clarifications – Explains how write optimization is the best read optimization.

Tied for First. The top two weren’t even written by the Tokutek team…

Alter Table Engine TokuDB – A blog with test results by Stephane Varoqui, Principal Consultant at SkySQL.

Are You Forcing MySQL to Do Twice as Many JOINs as Necessary? – A guest blog from Baron Schwartz, Chief Performance Architect, Percona.

Of course, Tokutek blogs only make up a small fraction of all the great blogs and news out there in 2011 on MySQL. If folks have other good MySQL year-end “top ten” lists to share, let us know.

In the meantime, have a great end of year and happy holidays!