[
https://issues.apache.org/jira/browse/IGNITE-17536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17536:
-------------------------------------
Description:
In a simple implementation, instead of a *BinaryTuple*, we store its link from
the *FreeList* in the key, this is not optimal and we need to inline the
*BinaryTuple* in the key, for starters, you can see how to do this in 2.0.
What should be done:
* Calculate approximate inline size:
** It is set by the user through the configuration or calculated automatically,
but should not be more than 2 KB (similar to *PageIO#MAX_PAYLOAD_SIZE* from
2.0);
** For automatic calculation, the *BinaryTuple* format must be taken into
account: header + null map + offset table;
*** To cover most cases, we will consider the size class to be 2 bytes
([BinaryTupleFormat-Header|https://cwiki.apache.org/confluence/display/IGNITE/IEP-92%3A+Binary+Tuple+Format#IEP92:BinaryTupleFormat-Header]);
*** For columns of variable length (for example, a string), we will assume that
10 bytes should be enough;
* Write *BinaryTuple* as is up to inline size;
** If the user *BinaryTuple* is larger than the inline size, then without its
transformations (as it is) we will write it according to the inline size (cut
it off);
** If the user *BinaryTuple* is less than or equal to the inline size, then we
will write it as is without writing it to the FreeList;
*** At the same time, we need to make a note somewhere that the *BinaryTuple*
is written in full, this will help us when comparing *BinaryTuple*'s inside the
B+tree;
* Comparing *BinaryTuple*'s at B+tree nodes:
** If the *BinaryTuple* in the tree node is completely written, then compare
them without loading the *BinaryTuple*' by link (since we will not write it to
the *FreeList*);
** Otherwise, we load the *BinaryTuple* by link and compare it with it, in the
future this should be optimized.
was:
In a simple implementation, instead of a *BinaryTuple*, we store its link from
the *FreeList* in the key, this is not optimal and we need to inline the
*BinaryTuple* in the key, for starters, you can see how to do this in 2.0.
What should be done:
* Calculate approximate inline size:
** It is set by the user through the configuration or calculated automatically,
but should not be more than 2 KB (similar to *PageIO#MAX_PAYLOAD_SIZE* from
2.0);
** For automatic calculation, the *BinaryTuple* format must be taken into
account: header + zero map + offset table;
*** To cover most cases, we will consider the size class to be 2 bytes
([BinaryTupleFormat-Header|https://cwiki.apache.org/confluence/display/IGNITE/IEP-92%3A+Binary+Tuple+Format#IEP92:BinaryTupleFormat-Header]);
*** For columns of variable length (for example, a string), we will assume that
10 bytes should be enough;
* Write *BinaryTuple* as is up to inline size;
** If the user *BinaryTuple* is larger than the inline size, then without its
transformations (as it is) we will write it according to the inline size (cut
it off);
** If the user *BinaryTuple* is less than or equal to the inline size, then we
will write it as is without writing it to the FreeList;
*** At the same time, we need to make a note somewhere that the *BinaryTuple*
is written in full, this will help us when comparing *BinaryTuple*'s inside the
B+tree;
* Comparing *BinaryTuple*'s at B+tree nodes:
** If the *BinaryTuple* in the tree node is completely written, then compare
them without loading the *BinaryTuple*' by link (since we will not write it to
the *FreeList*);
** Otherwise, we load the *BinaryTuple* by link and compare it with it, in the
future this should be optimized.
> Implement BinaryTuple inlining in a hash index B+Tree
> -----------------------------------------------------
>
> Key: IGNITE-17536
> URL: https://issues.apache.org/jira/browse/IGNITE-17536
> Project: Ignite
> Issue Type: Task
> Reporter: Kirill Tkalenko
> Assignee: Kirill Tkalenko
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> In a simple implementation, instead of a *BinaryTuple*, we store its link
> from the *FreeList* in the key, this is not optimal and we need to inline the
> *BinaryTuple* in the key, for starters, you can see how to do this in 2.0.
> What should be done:
> * Calculate approximate inline size:
> ** It is set by the user through the configuration or calculated
> automatically, but should not be more than 2 KB (similar to
> *PageIO#MAX_PAYLOAD_SIZE* from 2.0);
> ** For automatic calculation, the *BinaryTuple* format must be taken into
> account: header + null map + offset table;
> *** To cover most cases, we will consider the size class to be 2 bytes
> ([BinaryTupleFormat-Header|https://cwiki.apache.org/confluence/display/IGNITE/IEP-92%3A+Binary+Tuple+Format#IEP92:BinaryTupleFormat-Header]);
> *** For columns of variable length (for example, a string), we will assume
> that 10 bytes should be enough;
> * Write *BinaryTuple* as is up to inline size;
> ** If the user *BinaryTuple* is larger than the inline size, then without its
> transformations (as it is) we will write it according to the inline size (cut
> it off);
> ** If the user *BinaryTuple* is less than or equal to the inline size, then
> we will write it as is without writing it to the FreeList;
> *** At the same time, we need to make a note somewhere that the *BinaryTuple*
> is written in full, this will help us when comparing *BinaryTuple*'s inside
> the B+tree;
> * Comparing *BinaryTuple*'s at B+tree nodes:
> ** If the *BinaryTuple* in the tree node is completely written, then compare
> them without loading the *BinaryTuple*' by link (since we will not write it
> to the *FreeList*);
> ** Otherwise, we load the *BinaryTuple* by link and compare it with it, in
> the future this should be optimized.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
