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 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 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 mulit-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

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.”

Issue addressed: Managing metadata at exabyte scale

Delivering Agile Storage in the Cloud with Billions of Assets

The Company: Founded in 2001, Limelight Networks, Inc (NASDAQ: LLNW) is an Internet platform and services company that integrates the most business-critical parts of the online content value chain. Limelight’s cloud-based services enable customers to profit from the shift of content and advertising to the online world, from the explosive growth of mobile and connected devices, and from the migration of IT applications and services to the cloud. More than 1,800 customers worldwide use Limelight’s massively scalable services to better engage audiences, optimize advertising, manage and monetize digital assets and build stronger customer relationships.

The Challenge: Limelight designed a unique high-availability Agile Storage cloud service, which gives users control over how and where their content is stored by offering massive storage capacity, extreme flexibility for setting business rules and replication policies, with localized ingest and content access around the globe. The service provides vast storage volumes for large libraries of any type of digital asset.

The system was designed for a total capacity on the order of exabytes worldwide and is presently capable of supporting over 100 billion assets. To succeed with the platform, Limelight needed a storage engine that could handle insertion and query performance on large tables and scale as the database grew, and it needed to accomplish this in a cost effective manner. “This vast amount of information brings with it a rich and large amount of metadata around policies, file names, storage pointers, asset registries, users, and groups” according to Wylie Swanson, VP Technology, Cloud Services at Limelight. “Ensuring the metadata could be managed in an efficient and flexible way was critical to the design of the offering.”

A number of options Limelight had considered were insufficient. These included:

InnoDB – Despite familiarity with the MySQL storage engine InnoDB, Limelight found that it didn’t meet the project’s requirements. According to Swanson “the minute you run out of RAM for indexing, InnoDB performance starts to fall apart. We were seeing this occur at 50M – 100M rows. You can shard content, of course, but that feeds back into application and management complexity. Moreover, not all of our database schema is amenable to simple sharding methods.”

RAM Expansion – “While high powered servers and more RAM can somewhat extend the size of a database that InnoDB can handle, doing so is ultimately cost prohibitive” according to Swanson. “To support our system using more traditional database technology, we would have had to purchase terabytes of RAM for our servers.”

Schooner – “Schooner offered performance improvements, but was too expensive. In addition, it didn’t look like it could achieve the performance levels of our commodity servers using TokuDB in our application” according to Swanson.

The Solution: Limelight Agile Storage uses TokuDB for metadata management

Limelight needed a system that could access the database remotely with high availability, flexibility, performance and capacity. Limelight chose MariaDB for components of the platform. To satisfy the need for high availability, the Agile Storage Service uses a high availability Linux cluster to manage the metadata.

For the requirements of flexibility, performance and capacity, TokuDB was an unparalleled choice. “TokuDB provides incredible scaling, keeping a high insert rate throughout as the metadata repository continues to grow” noted Swanson. “This is crucial to keeping up with high-ingest points that are spread all around the world. TokuDB also provides the underpinning for a system that supports arbitrary queries – for example which policies are expired on which assets.”

In addition, Limelight benefited from other TokuDB features such as high data compression yielding a savings of 65% of disk capacity for the meta-directory components.

The Benefits:

Scale: The Agile Storage platform was designed to scale to exabytes of data. Cost effectively scaling compute power, storage, and software was critical to the design. “We don’t know how we could have gotten to our required scale and price points for our meta-directory components without TokuDB” according to Swanson.

Ease of Implementation: Swanson noted that “TokuDB worked seamlessly from the start with MariaDB. Installing it was quick and simple, and we were up and running in a few hours and it worked out-of-the-box with default settings, so that we could focus on maximizing the performance of our platform, not our databases.”

Compression: In addition to fast insertion rates, TokuDB provides data compression levels that are much higher than InnoDB’s. TokuDB’s advanced compression technology reduced Limelight’s disk space requirements by roughly 3x, from over 1 TB down to about 350 GB.

This year again, MySQL will be represented by its Community.

If you want to discuss with friend’s of MySQL it’s the place to be in February !

Like every year, FOSDEM takes place the first week-end of February in Brussels.

The MySQL and Friends devroom is Room H.1309 (150 seats). We (the MySQL Community) will have the room on Sunday 5th February 2012, all day.

We are organizing a MySQL & Friends dinner on Saturday night, more to come later on this.

If you want to propose a talk (you are in fact invited to propose one !), the deadline is December 26th.
Like we did on past editions, as soon as the talks are submitted, we will ask everyone to vote on the talks via Twitter or email.

Propose your talk now() here.

Thank you and see you soon in Brussels to talk MySQL and/or have a nice Belgian Beer

We’re happy to announce the following:

• The next version of MariaDB, version 5.2.10 will include an open source PAM Authentication Plugin. MariaDB 5.2.10 is scheduled for release next week.
• A Windows Authentication Plugin is in development and QA currently and will be part of MariaDB 5.2.11, which is scheduled for release before Christmas.
• MariaDB 5.5 will include both of the above plugins and an open source thread pool implementation. The soon-to-be-launched first version however will not include the thread pool.

Stay tuned for more information as soon as we start launching the above features.

Mission critical services relying on MariaDB should be aware that SkySQL has familiarized themselves with the new features and are ready to support all of the above options.

With the release of TokuDB v5.0 last March, we delivered a powerful and agile storage engine that broke through traditional MySQL scalability and performance barriers. As deployments of TokuDB have grown more varied, one request we have repeatedly heard from customers and prospects, especially in areas such as online advertising, social media, and clickstream analysis, is for improved performance for multi-client workloads.

Tokutek is now pleased to announce limited beta availability for TokuDB v5.2. The latest version of our flagship product offers a significant improvement over TokuDB v5.0 in multi-client scaling as well as performance gains in point queries, range queries, and trickle load speed. There are a host of other smaller changes and improvements that are detailed in our release notes (available to beta participants).

TokuDB continues to lead the field by offering:

• 20x to 80x faster insertion speed
• Hot Schema Changes including Hot Index Add/Drop and Hot Column Add/Drop
• Full MySQL compatibility
• 5x to 15x compression
• Scalability to tens of TBs
• Non-fragmenting indexes
• ACID, MVCC, and SAVEPOINTS
• Compatibility with MariaDB

Enrollment in the TokuDB v5.2 beta is limited. If interested, please register on our site (if you haven’t already) and then send an e-mail to beta@tokutek.com.