MariaDB and the MySQL Sandbox

Published on 26 July 2010 by Rich Prohaska in TokuView

Tokutek tests its TokuDB Fractal Tree storage engine with multiple MySQL distributions. We make extensive use of the MySQL Sandbox in our test automation. We tweaked the regular expressions that match binary tarball names in the MySQL Sandbox so that MariaDB releases can be easily loaded by the MySQL Sandbox. These changes can be found [...]

0 comments | Continue Reading

In posts on June 30 and July 6, I explained how implementing the commands “replace into” and “insert ignore” with TokuDB’s fractal trees data structures can be two orders of magnitude faster than implementing them with B-trees. Towards the end of each post, I hinted at that there are some caveats that complicate the story [...]

0 comments | Continue Reading

In my post on June 18th, I explained why the semantics of normal ad-hoc insertions with a primary key are expensive because they require disk seeks on large data sets. I previously explained why it would be better to use “replace into” or to use “insert ignore” over normal inserts. In this post, I explain [...]

6 comments | Continue Reading

In my post from three weeks ago, I explained why the semantics of normal ad-hoc insertions with a primary key are expensive because they require disk seeks on large data sets. Towards the end of the post, I claimed that it would be better to use “replace into” or “insert ignore” over normal inserts, because [...]

0 comments | Continue Reading

Announcing TokuDB v4.0

Published on 03 July 2010 by John Partridge in TokuView

Tokutek is pleased to announce immediate availability of TokuDB for MySQL, version 4.0. It is designed for continuous querying and analysis of large volumes of rapidly arriving and changing data, while maintaining full ACID properties. New in TokuDB v4.0 is our multi-threaded Fast Loader. Capable of utilizing all available CPU cores, the Fast Loader greatly [...]

0 comments | Continue Reading

In this post two weeks ago, I explained why the semantics of normal ad-hoc insertions with a primary key are expensive because they require disk seeks on large data sets. Towards the end of the post, I claimed that it would be better to use “replace into” or “insert ignore” over normal inserts, because the [...]

3 comments | Continue Reading

The analysis that shows how to make deletions really fast by using clustering keys and TokuDB’s fractal tree based engine also applies to make updates really fast. (I left it out of the last post to keep the story simple). As a quick example, let’s look at the following statement: update foo set price=price+1 where [...]

0 comments | Continue Reading

Continuing in the theme from previous posts, I’d like to examine another case where we can eliminate all disk seeks from a MySQL operation and therefore get two orders-of-magnitude speedup. The general outline of these posts is: B-trees do insertion disk seeks. While they’re at it, they piggyback some other work on the disk seeks. [...]

2 comments | Continue Reading

In my last post, I discussed how fractal tree data structures can be up to two orders of magnitude faster on deletions over B-trees. I focused on the deletions where the row entry is known (the storage engine API handler::delete_row), but I did not fully analyze how MySQL delete statements can be fast. In this [...]

1 comment | Continue Reading

As mentioned in parts 1 and 2, having many disk seeks are bad (they slow down performance). Fractal tree data structures minimize disk seeks on ad-hoc insertions, whereas B-trees practically guarantee that disk seeks are performed on ad-hoc insertions. As a result, fractal tree data structures can insert data up to two orders of magnitude [...]

1 comment | Continue Reading