Comments for Tokutek

Comment on About by MoreSQL (NewSQL) challenges NoSQL? - Open News

MoreSQL (NewSQL) challenges NoSQL? - Open News — Thu, 02 Feb 2012 04:10:04 +0000

[...] is also an area to improve database performance. If you are interested in this area, you can see Tokutek , the company claims that they improve the performance of database operations 20-80 [...]

Comment on 1 Billion Insertions – The Wait is Over! by 1 Billion Insertions – The Wait is Over! « Another Word For It

1 Billion Insertions – The Wait is Over! « Another Word For It — Tue, 31 Jan 2012 01:02:20 +0000

[...] 1 Billion Insertions – The Wait is Over! by Tim Callaghan. [...]

Comment on Announcing TokuDB v5.2: Improved Multi-Client Scaling and Faster Queries by Announcing TokuDB v5.2: Improved Multi-Client Scaling and Faster Queries « async I/O News

Sat, 21 Jan 2012 16:01:40 +0000

[...] Read full article Tagged as: MariaDB, MySQL, SQL, TokuDB Comments Off Comments (0) Trackbacks (0) ( subscribe to comments on this post ) [...]

Comment on Fractal Tree Indexes and Mead – MySQL Meetup by Fractal Tree Indexes and Mead – MySQL Meetup « Another Word For It

Fractal Tree Indexes and Mead – MySQL Meetup « Another Word For It — Thu, 12 Jan 2012 01:05:43 +0000

[...] Fractal Tree Indexes and Mead – MySQL Meetup [...]

Comment on FictionPress Selects TokuDB for Consistent Performance and Fast Disaster Recovery by Lawrence Schwartz

Lawrence Schwartz — Tue, 10 Jan 2012 19:49:31 +0000

@ADBer, To answer your second question first, for the time being we don't do Direct I/O. As for your first question about implementation, check this out for an overview of how Fractal Trees work.

Comment on FictionPress Selects TokuDB for Consistent Performance and Fast Disaster Recovery by ADBer

ADBer — Mon, 09 Jan 2012 09:03:11 +0000

Fractal Tree seems like awesome.
But I have some questions about it,
1) I can’t find some details about how is it implemented, such as how index storage and how data storage,and what the storage structured is?Is the last layer(32) is one big index file,if so,how to read it fast?
2)Is it Direct I/O?

Thanks.

Comment on Introducing Multiple Clustering Indexes by Zardosht Kasheff

Zardosht Kasheff — Thu, 22 Dec 2011 18:26:19 +0000

1) Yes, this is feasible. A clustering index can be defined just as a normal index is defined.

2) Both! For more information, see http://tokutek.com/downloads/mysqluc-2010-fractal-trees.pdf

3a) I assume you are asking about the advantages of single column non clustering indexes, such as key(a). Such an index takes less space on disk (so that is an advantage), but covers fewer queries. I don’t think there is an advantage to single row fetches, because if the index is not covering, then this may result in 2 disk seeks, where as a covering index may answer the query in one disk seek.

3b) I assume you are asking if there is an advantage to having both a clustering key (a) and a key(a). I see no advantage, other than for a small set of queries for which both key(a) and clustering key(a) are covering, key(a) is a little more efficient.

4) In our releases, the maximum number of columns is 32.

Comment on Making “Insert Ignore” Fast, by Avoiding Disk Seeks by zardosht

zardosht — Tue, 20 Dec 2011 20:38:59 +0000

There is no need to avoid “replace into”. If row based replication does not work with your “replace into” statement and TokuDB, then an error will be reported. You can choose to set tokudb_pk_insert_mode to 2, and get reduced performance, or you can switch to statement based replication.

Comment on Making “Insert Ignore” Fast, by Avoiding Disk Seeks by moses wejuli

moses wejuli — Mon, 19 Dec 2011 16:42:58 +0000

hi zardosht,

can i assume that with row-based replication, we are to completely avoid using “replace into” owing to the bug you filed: http://bugs.mysql.com/bug.php?id=53561 ?!

or has this been fixed? the bugs log doesn’t seem to suggest it’s been fixed tho……

many thanks,

moses.

Comment on Introducing Multiple Clustering Indexes by moses wejuli

moses wejuli — Mon, 19 Dec 2011 16:26:19 +0000

hi zardosht,

got a few queries for u here..

1) i know clustering indexes include all columns for the table, however, am keen to know if we can define multi-column clustering indexes for purposes of sorting e.g.
— create clustering index clstr_key on foo(a,b,c)
where column c is sorted relative to b, and b sorted relative to a, etc….. is this feasible?!

2) where does the index sorting happen with TokuDB? On disk or in memory? at what point do we get back to memory during this process?

3) with the advent of multiple clustering indexes per table with TokuDB, how useful are single column indexes for multi-row, multi-field result sets? seems to me that single column indexes will only be useful for a single row fetches only, if at all!

3) what are the advantages of defining a clustering index with a column that has been defined as a single row index elsewhere? or will that only be a waste of index?

4) what is the maximum number of columns that can be defined as part of a single composite or covering index (please specify for both TokuDB and InnoDB).

thanks,

moses.