Comments on: Introducing Multiple Clustering Indexes http://www.tokutek.com/2009/05/introducing_multiple_clustering_indexes/ Thu, 02 Feb 2012 04:10:04 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Zardosht Kasheff http://www.tokutek.com/2009/05/introducing_multiple_clustering_indexes/#comment-3485 Zardosht Kasheff Thu, 22 Dec 2011 18:26:19 +0000 http://introducing_multiple_clustering_indexes#comment-3485 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. 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.

]]> By: moses wejuli http://www.tokutek.com/2009/05/introducing_multiple_clustering_indexes/#comment-3353 moses wejuli Mon, 19 Dec 2011 16:26:19 +0000 http://introducing_multiple_clustering_indexes#comment-3353 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. 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.

]]> By: TokuDB FAQ | Tokutek http://www.tokutek.com/2009/05/introducing_multiple_clustering_indexes/#comment-83 TokuDB FAQ | Tokutek Tue, 01 Feb 2011 22:08:45 +0000 http://introducing_multiple_clustering_indexes#comment-83 [...] TokuDB, we have added functionality and grammar syntax to define multiple clustered indexes. As a result, users can get the performance advantages of clustered indexes for multiple indexes. [...] [...] TokuDB, we have added functionality and grammar syntax to define multiple clustered indexes. As a result, users can get the performance advantages of clustered indexes for multiple indexes. [...]

]]> By: Clustering indexes vs. Covering indexes | Tokutek http://www.tokutek.com/2009/05/introducing_multiple_clustering_indexes/#comment-82 Clustering indexes vs. Covering indexes | Tokutek Thu, 19 Aug 2010 19:45:42 +0000 http://introducing_multiple_clustering_indexes#comment-82 [...] I (Zardosht) posted an entry introducing clustering indexes. Here, I elaborate on three differences between a clustering index and a covering [...] [...] I (Zardosht) posted an entry introducing clustering indexes. Here, I elaborate on three differences between a clustering index and a covering [...]

]]> By: How clustering indexes sometimes help UPDATE and DELETE performance | Tokutek http://www.tokutek.com/2009/05/introducing_multiple_clustering_indexes/#comment-81 How clustering indexes sometimes help UPDATE and DELETE performance | Tokutek Thu, 19 Aug 2010 19:43:13 +0000 http://introducing_multiple_clustering_indexes#comment-81 [...] recently posted a blog entry on clustering indexes, which are good for speeding up queries. Eric Day brought up the concern that clustering indexes [...] [...] recently posted a blog entry on clustering indexes, which are good for speeding up queries. Eric Day brought up the concern that clustering indexes [...]

]]> By: MySQL 5.1 Grammar Changes to Support Clustering Indexes | Tokutek http://www.tokutek.com/2009/05/introducing_multiple_clustering_indexes/#comment-80 MySQL 5.1 Grammar Changes to Support Clustering Indexes | Tokutek Thu, 19 Aug 2010 19:42:12 +0000 http://introducing_multiple_clustering_indexes#comment-80 [...] blogging about TokuDB’s multiple clustering indexes feature, Baron Schwartz suggested we contribute the patch to allow other storage engine to [...] [...] blogging about TokuDB’s multiple clustering indexes feature, Baron Schwartz suggested we contribute the patch to allow other storage engine to [...]

]]> By: Improving TPC-H-like queries – Q17 | Tokutek http://www.tokutek.com/2009/05/introducing_multiple_clustering_indexes/#comment-79 Improving TPC-H-like queries – Q17 | Tokutek Thu, 19 Aug 2010 19:41:11 +0000 http://introducing_multiple_clustering_indexes#comment-79 [...] Summary: A query like TPC-H Query 17 can be sped up by large factors by using straight_joins and clustering indexes. (This entry posted by [...] [...] Summary: A query like TPC-H Query 17 can be sped up by large factors by using straight_joins and clustering indexes. (This entry posted by [...]

]]> By: Mark Callaghan http://www.tokutek.com/2009/05/introducing_multiple_clustering_indexes/#comment-78 Mark Callaghan Mon, 15 Mar 2010 21:19:49 +0000 http://introducing_multiple_clustering_indexes#comment-78 This is very nice. I missed this post when you first wrote it. It can be used to provide much better bounds on worst-case query performance (a few disk reads versus thousands) and do a much better job at making queries 'online'. This is very nice. I missed this post when you first wrote it. It can be used to provide much better bounds on worst-case query performance (a few disk reads versus thousands) and do a much better job at making queries ‘online’.

]]> By: Kristian Nielsen http://www.tokutek.com/2009/05/introducing_multiple_clustering_indexes/#comment-77 Kristian Nielsen Fri, 29 May 2009 03:07:22 +0000 http://introducing_multiple_clustering_indexes#comment-77 Ah, now I think I see the difference between this and normal covering indexes. The difference here is that the extra fields are only stored in the leaf nodes (assuming Btree index). The keys in interior nodes need not store the extra fields, unlike in traditional covering indexes where the extra fields needlessly increase the key size proper. That might be useful, especially when the row size is much bigger than the key size (not at all uncommon). Ah, now I think I see the difference between this and normal covering indexes. The difference here is that the extra fields are only stored in the leaf nodes (assuming Btree index). The keys in interior nodes need not store the extra fields, unlike in traditional covering indexes where the extra fields needlessly increase the key size proper.

That might be useful, especially when the row size is much bigger than the key size (not at all uncommon).

]]> By: Zardosht Kasheff http://www.tokutek.com/2009/05/introducing_multiple_clustering_indexes/#comment-76 Zardosht Kasheff Thu, 28 May 2009 23:59:45 +0000 http://introducing_multiple_clustering_indexes#comment-76 @Venu, with TokuDB, we typically measure compression ratios of 3x to 12x relative to the amount of raw data in a table. Since a clustering index is another copy of the table in a different sort order, it will probably consume somewhere between 1/3 and 1/12 of the table's raw data size. @Venu, with TokuDB, we typically measure compression ratios of 3x to 12x relative to the amount of raw data in a table. Since a clustering index is another copy of the table in a different sort order, it will probably consume somewhere between 1/3 and 1/12 of the table’s raw data size.

]]>