by Tokutek | Feb 1, 2011 | MySQL
Links to the FAQ Sections can be found here: General Information Open Source Technical Details Best Practices and Tools General Information ANY CHARACTER HERE 1. What is TokuDB? TokuDB is an ACID compliant storage engine for MySQL that is specifically designed for...
by Martin.FarachColton | Nov 17, 2010 | MySQL
Summary B-trees suffer from fragmentation. Fragmentation causes headaches — in query performance and space used. Solutions, like dump and reload or OPTIMIZE TABLE are a pain and not always effective. Fractal trees don’t fragment. So if fragmentation is a...
by Zardosht.Kasheff | Aug 11, 2010 | MySQL
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...
by Rich.Prohaska | Aug 3, 2010 | MySQL
In posts on June 30 and July 6, we 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...
by Zardosht.Kasheff | Jul 21, 2010 | MySQL
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...
by Zardosht.Kasheff | Jul 14, 2010 | MySQL
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...
by Zardosht.Kasheff | Jul 6, 2010 | MySQL
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...
by Zardosht.Kasheff | Jun 30, 2010 | MySQL
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”...
by Zardosht.Kasheff | Jun 22, 2010 | MySQL
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...
by Zardosht.Kasheff | Jun 18, 2010 | MySQL
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....
by Zardosht.Kasheff | Jun 8, 2010 | MySQL
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...
by Zardosht.Kasheff | Jun 2, 2010 | MySQL
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,...
