One of Profile Technology Ltd.’s most popular applications is their Advanced Search function for Facebook. Find out how TokuDB v3.0 dramatically increased their insertion speed performance in our new Case Study.
Tokutek is pleased to announce immediate availability of TokuDB for MySQL, version 3.0. It is designed for continuous querying and analysis of large volumes of rapidly arriving and changing data, while maintaining full ACID properties.
TokuDB v3.0 combines our long-standing performance advantages with ACID compliant transactional integrity:
- 10x-50x faster indexing for faster querying
- Full support for ACID transactions
- Fast recovery time (seconds or minutes, not hours or days)
- Immunity to database aging to eliminate performance degradation and maintenance headaches
- 5x-15x data compression for reduced disk use and lower storage costs
Because of its high indexing performance and transaction support, TokuDB is well suited to Web applications that must simultaneously store and query …
[Read more]In a follow-up experiment to an earlier post on TokuDB recovery times, I tried to create a better apples-to-apples comparison to InnoDB recovery time. If I measure recovery times when both DBs are doing the same amount of work, TokuDB requires only 2s to recover from a crash, compared to 1020s for InnoDB.
Background
In the first experiment, I compared recovery times when both storage engines (TokuDB and InnoDB) were inserting at maximum rates. In that experiment, following a power cord pull and server restart, TokuDB recovered in 501s, InnoDB in 18505s. In …
[Read more]We recently made transactions in TokuDB 3.0 durable. We write table changes into a log file so that in the event of a crash, the table changes up to the last checkpoint can be replayed. Durability requires the log file to be fsync’ed when a transaction is committed. Unfortunately, fsync’s are not free, and may cost 10’s of milliseconds of time. This may seriously affect the insertion rate into a TokuDB table. How can one achieve high insertion rates in TokuDB with durable transactions?
Decrease the fsync cost
The fsync of the TokuDB log file writes all of the dirty log file data that is cached in memory by the operating system to the underlying storage system. The fsync time can be modeled with a simple linear equation: fsync time = N/R + K, where N is the amount of dirty data that needs to by written to disk, R is the disk write rate, and K is a constant time defined by the …
[Read more]Last week Tokutek released version 3.0.0 of TokuDB, adding ACID transactions to its list of features. This post discusses an experiment we ran to measure recovery time following a system crash.
In summary, while actively inserting records into a MySQL database using iiBench, we compared the time to recover from a power-cord pull for both InnoDB and TokuDB.
Storage Engine | Recovery Time |
TokuDB | 501s (8 min, 21 sec) |
InnoDB | 18505s (5 hours, 8 min, 25 sec) |
This is by no means an exhaustive look at recovery performance, but does illustrate the benefits of …
[Read more]Last spring, we added a feature that allows the user to see the progress of writes in a statement. Vadim liked it. In 2.2.0, in “show processlist”, we add progress information on reads.
Here is an example of what “show processlist” displays on an update:
mysql> show processlist \G *************************** 1. row *************************** Id: 1 User: root Host: localhost db: test Command: Query Time: 7 State: Queried about 1576008 rows, Updated about 197000 rows Info: update foo set a=9 where a=8
Here is an example of what “show processlist” displays on an insert that requires a query:
mysql> show processlist \G *************************** 1. row *************************** Id: 1 User: root Host: localhost db: test Command: Query Time: 6 State: Queried about 1542001 rows, Inserted about 771000 …[Read more]
KAYAK, the world’s leading travel search engine, is using TokuDB for MySQL to provide a more personalized user experience. Read all about it in today’s press release.
For the past two months, I have been running tests on TokuDB in my free time. TokuDB is a storage engine put out by Tokutek. TokuDB uses fractal tree indexes instead of B-tree indexes to improve performance, which is dramatically noticeable when dealing with large tables (over 100 million rows).
For those that like the information “above the fold”, here is a table with results from a test comparing InnoDB and TokuDB. All the steps are explained in the post below, if you want more details, but here’s the table:
Action | InnoDB | TokuDB |
---|---|---|
Importing ~40 million rows | 119 min 20.596 sec | 69 min 1.982 sec |
INSERTing again, ~80 million rows total | 5 hours 13 min 52.58 sec … |
Tokutek is pleased to announce the general availability of TokuDB for MySQL, version 2.2.0. This version offers several improvements:
- Better multi-core load balancing for concurrent workloads.
- Faster bulk loading performance.
- Enhanced diagnostics for easier tuning and troubleshooting.
- Fixed all known bugs.
About TokuDB
TokuDB for MySQL is a storage engine built with Tokutek’s Fractal Tree technology. TokuDB provides near seamless compatibility for MySQL applications. Tables can be individually defined to use TokuDB, MyISAM, InnoDB or other MySQL-compliant storage engines. Data is loaded, inserted, and queried using standard MySQL commands, with no restrictions or special requirements. Our Fractal Tree technology indexes up to 50 times faster than traditional database technologies, enabling near …
[Read more]