[jira] [Commented] (IGNITE-23120) Improve inline index feature
[
https://issues.apache.org/jira/browse/IGNITE-23120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18021136#comment-18021136
]
Filipp Shergalis commented on IGNITE-23120:
---
[~timonin.maksim] Hi! Recently I realized that second bug I described (about
ignoring user limits if configuredInlineSize is set) is a feature. It allows
user to configure a larger inline index without increasing limits for all
indexes. It is even documented:)
> Improve inline index feature
>
>
> Key: IGNITE-23120
> URL: https://issues.apache.org/jira/browse/IGNITE-23120
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Pligin
>Assignee: Filipp Shergalis
>Priority: Major
> Fix For: 2.18
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Ignite allows index rows to be inlined directly into the page. However, it
> doesn’t guard properly against too big inline size values. Currently, it uses
> {{PageIO.MAX_PAYLOAD_SIZE}} as the maximum allowed value, but this value can
> still be too large, because it does not take the page size and encryption
> (which adds additional bytes to the page header) into account. This possibly
> leads to a bad situation when only one item can fit in one page which can
> lead to BTree performance degradation.
> The following is expected to be done:
> # When inline size for an index is set, a maximum inline size should be
> computed:
> ## Considering we want to have _at least_ 2 items per page, here’s how the
> page layout with max inline size will look like: {{PS = H + L + I + L + I +
> L}} . Where PS - Page Size, H - page header size, L - size of the child link,
> I - item size.
> ## Using the above equation, we get the max possible item size to be equal
> to: {{I = (PS - H - 3L) / 2}} . However, for inline indexes, every item has
> an additional overhead to the actual inlined value (a.k.a payload), which
> depends on MVCC being present.
> ## Taking this into account, the maximum payload size will be equal: {{P =
> (PS - H - 3L) / 2 - X}} , where P - Payload size, X - overhead per item.
> ## In implementation terms, {{PS}} must be computed using the
> {{PageMemory#realPageSize}} which takes encryption overhead into
> account,{{{}H{}}} is equal to {{{}BPlusIo#ITEMS_OFF{}}}, {{L}} is 8 bytes and
> {{X}} depends on the actual {{AbstractH2ExtrasInnerIO}} implementation and
> varies between 8 and 28 bytes.
> # If the configured inline size exceeds the computed maximum size or
> {{PageIO.MAX_PAYLOAD_SIZE}} then an exception must be thrown with a message
> that notifies the user of the incorrect inline size value. Note that this
> should only happen for _new_ indexes, if a nodes is started on top of an
> existing PDS, no exceptions should be thrown and a warning should be printed
> instead, to preserve backwards compatibility.
> # Fix the “Indexed columns of a row cannot be fully inlined into index”
> warning to recommend at most the maximum allowed inline size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-23120) Improve inline index feature
[
https://issues.apache.org/jira/browse/IGNITE-23120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18008006#comment-18008006
]
Philipp Shergalis commented on IGNITE-23120:
[~timonin.maksim] Hi! Thanks for reviewing.
For loop in *computeInlineSize* serves two puproses: calculate total index size
and check if {*}all fields have fixed size{*}. But we break this loop early if
calculated size exceeds *propSize*
Consider that the *last field* in the index has *not fixed size* and earlier
fields ({*}with fixed size{*}) will exceed {*}propSize{*}. Then we hit
condition *size > propSize,* break for-loop early and variable *fixedSize* will
be true. But it must be false because of the last field
if (size > propSize) {
size = propSize;break;
}
> Improve inline index feature
>
>
> Key: IGNITE-23120
> URL: https://issues.apache.org/jira/browse/IGNITE-23120
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Pligin
>Assignee: Philipp Shergalis
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Ignite allows index rows to be inlined directly into the page. However, it
> doesn’t guard properly against too big inline size values. Currently, it uses
> {{PageIO.MAX_PAYLOAD_SIZE}} as the maximum allowed value, but this value can
> still be too large, because it does not take the page size and encryption
> (which adds additional bytes to the page header) into account. This possibly
> leads to a bad situation when only one item can fit in one page which can
> lead to BTree performance degradation.
> The following is expected to be done:
> # When inline size for an index is set, a maximum inline size should be
> computed:
> ## Considering we want to have _at least_ 2 items per page, here’s how the
> page layout with max inline size will look like: {{PS = H + L + I + L + I +
> L}} . Where PS - Page Size, H - page header size, L - size of the child link,
> I - item size.
> ## Using the above equation, we get the max possible item size to be equal
> to: {{I = (PS - H - 3L) / 2}} . However, for inline indexes, every item has
> an additional overhead to the actual inlined value (a.k.a payload), which
> depends on MVCC being present.
> ## Taking this into account, the maximum payload size will be equal: {{P =
> (PS - H - 3L) / 2 - X}} , where P - Payload size, X - overhead per item.
> ## In implementation terms, {{PS}} must be computed using the
> {{PageMemory#realPageSize}} which takes encryption overhead into
> account,{{{}H{}}} is equal to {{{}BPlusIo#ITEMS_OFF{}}}, {{L}} is 8 bytes and
> {{X}} depends on the actual {{AbstractH2ExtrasInnerIO}} implementation and
> varies between 8 and 28 bytes.
> # If the configured inline size exceeds the computed maximum size or
> {{PageIO.MAX_PAYLOAD_SIZE}} then an exception must be thrown with a message
> that notifies the user of the incorrect inline size value. Note that this
> should only happen for _new_ indexes, if a nodes is started on top of an
> existing PDS, no exceptions should be thrown and a warning should be printed
> instead, to preserve backwards compatibility.
> # Fix the “Indexed columns of a row cannot be fully inlined into index”
> warning to recommend at most the maximum allowed inline size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-23120) Improve inline index feature
[
https://issues.apache.org/jira/browse/IGNITE-23120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18007853#comment-18007853
]
Maksim Timonin commented on IGNITE-23120:
-
[~phillippko] for bugs you mention
Could you please explain in more detail how the first bug is reproduced? I'm
missing smth, don't see a problem
> Improve inline index feature
>
>
> Key: IGNITE-23120
> URL: https://issues.apache.org/jira/browse/IGNITE-23120
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Pligin
>Assignee: Philipp Shergalis
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Ignite allows index rows to be inlined directly into the page. However, it
> doesn’t guard properly against too big inline size values. Currently, it uses
> {{PageIO.MAX_PAYLOAD_SIZE}} as the maximum allowed value, but this value can
> still be too large, because it does not take the page size and encryption
> (which adds additional bytes to the page header) into account. This possibly
> leads to a bad situation when only one item can fit in one page which can
> lead to BTree performance degradation.
> The following is expected to be done:
> # When inline size for an index is set, a maximum inline size should be
> computed:
> ## Considering we want to have _at least_ 2 items per page, here’s how the
> page layout with max inline size will look like: {{PS = H + L + I + L + I +
> L}} . Where PS - Page Size, H - page header size, L - size of the child link,
> I - item size.
> ## Using the above equation, we get the max possible item size to be equal
> to: {{I = (PS - H - 3L) / 2}} . However, for inline indexes, every item has
> an additional overhead to the actual inlined value (a.k.a payload), which
> depends on MVCC being present.
> ## Taking this into account, the maximum payload size will be equal: {{P =
> (PS - H - 3L) / 2 - X}} , where P - Payload size, X - overhead per item.
> ## In implementation terms, {{PS}} must be computed using the
> {{PageMemory#realPageSize}} which takes encryption overhead into
> account,{{{}H{}}} is equal to {{{}BPlusIo#ITEMS_OFF{}}}, {{L}} is 8 bytes and
> {{X}} depends on the actual {{AbstractH2ExtrasInnerIO}} implementation and
> varies between 8 and 28 bytes.
> # If the configured inline size exceeds the computed maximum size or
> {{PageIO.MAX_PAYLOAD_SIZE}} then an exception must be thrown with a message
> that notifies the user of the incorrect inline size value. Note that this
> should only happen for _new_ indexes, if a nodes is started on top of an
> existing PDS, no exceptions should be thrown and a warning should be printed
> instead, to preserve backwards compatibility.
> # Fix the “Indexed columns of a row cannot be fully inlined into index”
> warning to recommend at most the maximum allowed inline size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-23120) Improve inline index feature
[
https://issues.apache.org/jira/browse/IGNITE-23120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18007835#comment-18007835
]
Maksim Timonin commented on IGNITE-23120:
-
[~phillippko] hi! The patch LGTM, I has checked your visa - there is a few
failed tests, but not related to your patch.
Thanks for your contribution, merged to master!
I will fire tickets for bugs you mention
> Improve inline index feature
>
>
> Key: IGNITE-23120
> URL: https://issues.apache.org/jira/browse/IGNITE-23120
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Pligin
>Assignee: Philipp Shergalis
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Ignite allows index rows to be inlined directly into the page. However, it
> doesn’t guard properly against too big inline size values. Currently, it uses
> {{PageIO.MAX_PAYLOAD_SIZE}} as the maximum allowed value, but this value can
> still be too large, because it does not take the page size and encryption
> (which adds additional bytes to the page header) into account. This possibly
> leads to a bad situation when only one item can fit in one page which can
> lead to BTree performance degradation.
> The following is expected to be done:
> # When inline size for an index is set, a maximum inline size should be
> computed:
> ## Considering we want to have _at least_ 2 items per page, here’s how the
> page layout with max inline size will look like: {{PS = H + L + I + L + I +
> L}} . Where PS - Page Size, H - page header size, L - size of the child link,
> I - item size.
> ## Using the above equation, we get the max possible item size to be equal
> to: {{I = (PS - H - 3L) / 2}} . However, for inline indexes, every item has
> an additional overhead to the actual inlined value (a.k.a payload), which
> depends on MVCC being present.
> ## Taking this into account, the maximum payload size will be equal: {{P =
> (PS - H - 3L) / 2 - X}} , where P - Payload size, X - overhead per item.
> ## In implementation terms, {{PS}} must be computed using the
> {{PageMemory#realPageSize}} which takes encryption overhead into
> account,{{{}H{}}} is equal to {{{}BPlusIo#ITEMS_OFF{}}}, {{L}} is 8 bytes and
> {{X}} depends on the actual {{AbstractH2ExtrasInnerIO}} implementation and
> varies between 8 and 28 bytes.
> # If the configured inline size exceeds the computed maximum size or
> {{PageIO.MAX_PAYLOAD_SIZE}} then an exception must be thrown with a message
> that notifies the user of the incorrect inline size value. Note that this
> should only happen for _new_ indexes, if a nodes is started on top of an
> existing PDS, no exceptions should be thrown and a warning should be printed
> instead, to preserve backwards compatibility.
> # Fix the “Indexed columns of a row cannot be fully inlined into index”
> warning to recommend at most the maximum allowed inline size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-23120) Improve inline index feature
[
https://issues.apache.org/jira/browse/IGNITE-23120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18007827#comment-18007827
]
Ignite TC Bot commented on IGNITE-23120:
{panel:title=Branch: [pull/12155/head] Base: [master] : Possible Blockers
(5)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Windows){color} [[tests 0 TIMEOUT , Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=8514360]]
{color:#d04437}Cache 2{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=8514297]]
* IgniteCacheTestSuite2:
IgniteCacheServerNodeConcurrentStart.testConcurrentStart - Test has low fail
rate in base branch 0,0% and is not flaky
{color:#d04437}Thin Client: Java{color} [[tests 0 TIMEOUT , Exit Code , Failure
on metric |https://ci2.ignite.apache.org/viewLog.html?buildId=8514379]]
{color:#d04437}Thin client: Node.js{color} [[tests 0 Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=8514380]]
{color:#d04437}Queries 1{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=8514361]]
* IgniteBinaryCacheQueryTestSuite:
DynamicIndexServerCoordinatorBasicSelfTest.testCreateIndexWithParallelismPartitionedTransactional
- Test has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/12155/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=8514402&buildTypeId=IgniteTests24Java8_RunAll]
> Improve inline index feature
>
>
> Key: IGNITE-23120
> URL: https://issues.apache.org/jira/browse/IGNITE-23120
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Pligin
>Assignee: Philipp Shergalis
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Ignite allows index rows to be inlined directly into the page. However, it
> doesn’t guard properly against too big inline size values. Currently, it uses
> {{PageIO.MAX_PAYLOAD_SIZE}} as the maximum allowed value, but this value can
> still be too large, because it does not take the page size and encryption
> (which adds additional bytes to the page header) into account. This possibly
> leads to a bad situation when only one item can fit in one page which can
> lead to BTree performance degradation.
> The following is expected to be done:
> # When inline size for an index is set, a maximum inline size should be
> computed:
> ## Considering we want to have _at least_ 2 items per page, here’s how the
> page layout with max inline size will look like: {{PS = H + L + I + L + I +
> L}} . Where PS - Page Size, H - page header size, L - size of the child link,
> I - item size.
> ## Using the above equation, we get the max possible item size to be equal
> to: {{I = (PS - H - 3L) / 2}} . However, for inline indexes, every item has
> an additional overhead to the actual inlined value (a.k.a payload), which
> depends on MVCC being present.
> ## Taking this into account, the maximum payload size will be equal: {{P =
> (PS - H - 3L) / 2 - X}} , where P - Payload size, X - overhead per item.
> ## In implementation terms, {{PS}} must be computed using the
> {{PageMemory#realPageSize}} which takes encryption overhead into
> account,{{{}H{}}} is equal to {{{}BPlusIo#ITEMS_OFF{}}}, {{L}} is 8 bytes and
> {{X}} depends on the actual {{AbstractH2ExtrasInnerIO}} implementation and
> varies between 8 and 28 bytes.
> # If the configured inline size exceeds the computed maximum size or
> {{PageIO.MAX_PAYLOAD_SIZE}} then an exception must be thrown with a message
> that notifies the user of the incorrect inline size value. Note that this
> should only happen for _new_ indexes, if a nodes is started on top of an
> existing PDS, no exceptions should be thrown and a warning should be printed
> instead, to preserve backwards compatibility.
> # Fix the “Indexed columns of a row cannot be fully inlined into index”
> warning to recommend at most the maximum allowed inline size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-23120) Improve inline index feature
[
https://issues.apache.org/jira/browse/IGNITE-23120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18004636#comment-18004636
]
Philipp Shergalis commented on IGNITE-23120:
[~timonin.maksim] Hi! Ping, just in case :)
> Improve inline index feature
>
>
> Key: IGNITE-23120
> URL: https://issues.apache.org/jira/browse/IGNITE-23120
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Pligin
>Assignee: Philipp Shergalis
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ignite allows index rows to be inlined directly into the page. However, it
> doesn’t guard properly against too big inline size values. Currently, it uses
> {{PageIO.MAX_PAYLOAD_SIZE}} as the maximum allowed value, but this value can
> still be too large, because it does not take the page size and encryption
> (which adds additional bytes to the page header) into account. This possibly
> leads to a bad situation when only one item can fit in one page which can
> lead to BTree performance degradation.
> The following is expected to be done:
> # When inline size for an index is set, a maximum inline size should be
> computed:
> ## Considering we want to have _at least_ 2 items per page, here’s how the
> page layout with max inline size will look like: {{PS = H + L + I + L + I +
> L}} . Where PS - Page Size, H - page header size, L - size of the child link,
> I - item size.
> ## Using the above equation, we get the max possible item size to be equal
> to: {{I = (PS - H - 3L) / 2}} . However, for inline indexes, every item has
> an additional overhead to the actual inlined value (a.k.a payload), which
> depends on MVCC being present.
> ## Taking this into account, the maximum payload size will be equal: {{P =
> (PS - H - 3L) / 2 - X}} , where P - Payload size, X - overhead per item.
> ## In implementation terms, {{PS}} must be computed using the
> {{PageMemory#realPageSize}} which takes encryption overhead into
> account,{{{}H{}}} is equal to {{{}BPlusIo#ITEMS_OFF{}}}, {{L}} is 8 bytes and
> {{X}} depends on the actual {{AbstractH2ExtrasInnerIO}} implementation and
> varies between 8 and 28 bytes.
> # If the configured inline size exceeds the computed maximum size or
> {{PageIO.MAX_PAYLOAD_SIZE}} then an exception must be thrown with a message
> that notifies the user of the incorrect inline size value. Note that this
> should only happen for _new_ indexes, if a nodes is started on top of an
> existing PDS, no exceptions should be thrown and a warning should be printed
> instead, to preserve backwards compatibility.
> # Fix the “Indexed columns of a row cannot be fully inlined into index”
> warning to recommend at most the maximum allowed inline size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-23120) Improve inline index feature
[
https://issues.apache.org/jira/browse/IGNITE-23120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18002700#comment-18002700
]
Philipp Shergalis commented on IGNITE-23120:
[~timonin.maksim] Hi! I updated PR so:
* real page size is used, number of children can be easily changed in future
* inline recommender warns if inline is too big and recommends to reduce it /
increase page size
* reverted changes to computeInlineSize, though they fixed 2 unrelated bugs
I don't see any tests for inline recommender :( TBH I don't want to introduce
them myself
Unrelated bugs:
1. We break loop for calculating size if limit is exceeded, but we could skip
fields with not fixed size
{code:java}
fixedSize &= keyType.keySize() != -1;
...
if (size > propSize) {
size = propSize;
break;
} {code}
1. ```size``` is limited by property and ```sqlIndexMaxInlineSize```, but for
```!fixedSize``` case we return configured size that could exceed them.
{code:java}
if (cfgInlineSize != -1) {
cfgInlineSize = Math.min(PageIO.MAX_PAYLOAD_SIZE, cfgInlineSize);
if (fixedSize && size < cfgInlineSize) {
log.warning("Explicit INLINE_SIZE for fixed size index item is too big.
" +
"This will lead to wasting of space inside index pages. Ignoring " +
"[index=" + name + ", explicitInlineSize=" + cfgInlineSize + ",
realInlineSize=" + size + ']');
return size;
}
return cfgInlineSize;
}
{code}
> Improve inline index feature
>
>
> Key: IGNITE-23120
> URL: https://issues.apache.org/jira/browse/IGNITE-23120
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Pligin
>Assignee: Philipp Shergalis
>Priority: Major
>
> Ignite allows index rows to be inlined directly into the page. However, it
> doesn’t guard properly against too big inline size values. Currently, it uses
> {{PageIO.MAX_PAYLOAD_SIZE}} as the maximum allowed value, but this value can
> still be too large, because it does not take the page size and encryption
> (which adds additional bytes to the page header) into account. This possibly
> leads to a bad situation when only one item can fit in one page which can
> lead to BTree performance degradation.
> The following is expected to be done:
> # When inline size for an index is set, a maximum inline size should be
> computed:
> ## Considering we want to have _at least_ 2 items per page, here’s how the
> page layout with max inline size will look like: {{PS = H + L + I + L + I +
> L}} . Where PS - Page Size, H - page header size, L - size of the child link,
> I - item size.
> ## Using the above equation, we get the max possible item size to be equal
> to: {{I = (PS - H - 3L) / 2}} . However, for inline indexes, every item has
> an additional overhead to the actual inlined value (a.k.a payload), which
> depends on MVCC being present.
> ## Taking this into account, the maximum payload size will be equal: {{P =
> (PS - H - 3L) / 2 - X}} , where P - Payload size, X - overhead per item.
> ## In implementation terms, {{PS}} must be computed using the
> {{PageMemory#realPageSize}} which takes encryption overhead into
> account,{{{}H{}}} is equal to {{{}BPlusIo#ITEMS_OFF{}}}, {{L}} is 8 bytes and
> {{X}} depends on the actual {{AbstractH2ExtrasInnerIO}} implementation and
> varies between 8 and 28 bytes.
> # If the configured inline size exceeds the computed maximum size or
> {{PageIO.MAX_PAYLOAD_SIZE}} then an exception must be thrown with a message
> that notifies the user of the incorrect inline size value. Note that this
> should only happen for _new_ indexes, if a nodes is started on top of an
> existing PDS, no exceptions should be thrown and a warning should be printed
> instead, to preserve backwards compatibility.
> # Fix the “Indexed columns of a row cannot be fully inlined into index”
> warning to recommend at most the maximum allowed inline size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-23120) Improve inline index feature
[
https://issues.apache.org/jira/browse/IGNITE-23120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17987255#comment-17987255
]
Maksim Timonin commented on IGNITE-23120:
-
Hi [~phillippko]
>> Then will add this check to InlineRecommender.recommend, not on tree creation
Yes, I propose to add additional check to InlineRecommender. If inlineSize >
threshold then WARN.
But you need check it, I'm not sure that the place we invoke the recommender
now is in a right place for a described scenario. If you find that this is not
a very good idea, then OK. Let's write somewhere else.
>> Should it be done only once, or every X (1000) invocations as with another
>> check
I'd make it regular (every X times), to highlight importance of that.
>> There is a way to disable a warn?
Actually, I thought that there is a way to disable the recommender. But it's
not. Not a problem I think.
>> How to choose reasonable percentage?)) Could we set a large limit (i.e. 20%)
>> and leave it to users to perftest further?
We can set up it to 40% (~ you calculated it above), if there is no other
calculations or ideas. Later we can make it more restrictive if needed.
> Improve inline index feature
>
>
> Key: IGNITE-23120
> URL: https://issues.apache.org/jira/browse/IGNITE-23120
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Pligin
>Assignee: Philipp Shergalis
>Priority: Major
>
> Ignite allows index rows to be inlined directly into the page. However, it
> doesn’t guard properly against too big inline size values. Currently, it uses
> {{PageIO.MAX_PAYLOAD_SIZE}} as the maximum allowed value, but this value can
> still be too large, because it does not take the page size and encryption
> (which adds additional bytes to the page header) into account. This possibly
> leads to a bad situation when only one item can fit in one page which can
> lead to BTree performance degradation.
> The following is expected to be done:
> # When inline size for an index is set, a maximum inline size should be
> computed:
> ## Considering we want to have _at least_ 2 items per page, here’s how the
> page layout with max inline size will look like: {{PS = H + L + I + L + I +
> L}} . Where PS - Page Size, H - page header size, L - size of the child link,
> I - item size.
> ## Using the above equation, we get the max possible item size to be equal
> to: {{I = (PS - H - 3L) / 2}} . However, for inline indexes, every item has
> an additional overhead to the actual inlined value (a.k.a payload), which
> depends on MVCC being present.
> ## Taking this into account, the maximum payload size will be equal: {{P =
> (PS - H - 3L) / 2 - X}} , where P - Payload size, X - overhead per item.
> ## In implementation terms, {{PS}} must be computed using the
> {{PageMemory#realPageSize}} which takes encryption overhead into
> account,{{{}H{}}} is equal to {{{}BPlusIo#ITEMS_OFF{}}}, {{L}} is 8 bytes and
> {{X}} depends on the actual {{AbstractH2ExtrasInnerIO}} implementation and
> varies between 8 and 28 bytes.
> # If the configured inline size exceeds the computed maximum size or
> {{PageIO.MAX_PAYLOAD_SIZE}} then an exception must be thrown with a message
> that notifies the user of the incorrect inline size value. Note that this
> should only happen for _new_ indexes, if a nodes is started on top of an
> existing PDS, no exceptions should be thrown and a warning should be printed
> instead, to preserve backwards compatibility.
> # Fix the “Indexed columns of a row cannot be fully inlined into index”
> warning to recommend at most the maximum allowed inline size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-23120) Improve inline index feature
[
https://issues.apache.org/jira/browse/IGNITE-23120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17986864#comment-17986864
]
Philipp Shergalis commented on IGNITE-23120:
[~timonin.maksim] >>then disable the WARN
There is a way to disable a warn? Could you give an example how to support it
correctly?
>> It says when inline size is small, let's also talk when inline size is big
Then will add this check to InlineRecommender.recommend, not on tree creation.
Should it be done only once, or every X (1000) invocations as with another
check?
{code:java}
if (!inlineSizeCalculationCntr.compareAndSet(invokeCnt, invokeCnt + 1))
return;
boolean throttle = invokeCnt + 1 % inlineSizeThrottleThreshold != 0;{code}
>> having even 2 elements per page is also weird and might affect performance
How to choose reasonable percentage?)) Could we set a large limit (i.e. 20%)
and leave it to users to perftest further?
> Improve inline index feature
>
>
> Key: IGNITE-23120
> URL: https://issues.apache.org/jira/browse/IGNITE-23120
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Pligin
>Assignee: Philipp Shergalis
>Priority: Major
>
> Ignite allows index rows to be inlined directly into the page. However, it
> doesn’t guard properly against too big inline size values. Currently, it uses
> {{PageIO.MAX_PAYLOAD_SIZE}} as the maximum allowed value, but this value can
> still be too large, because it does not take the page size and encryption
> (which adds additional bytes to the page header) into account. This possibly
> leads to a bad situation when only one item can fit in one page which can
> lead to BTree performance degradation.
> The following is expected to be done:
> # When inline size for an index is set, a maximum inline size should be
> computed:
> ## Considering we want to have _at least_ 2 items per page, here’s how the
> page layout with max inline size will look like: {{PS = H + L + I + L + I +
> L}} . Where PS - Page Size, H - page header size, L - size of the child link,
> I - item size.
> ## Using the above equation, we get the max possible item size to be equal
> to: {{I = (PS - H - 3L) / 2}} . However, for inline indexes, every item has
> an additional overhead to the actual inlined value (a.k.a payload), which
> depends on MVCC being present.
> ## Taking this into account, the maximum payload size will be equal: {{P =
> (PS - H - 3L) / 2 - X}} , where P - Payload size, X - overhead per item.
> ## In implementation terms, {{PS}} must be computed using the
> {{PageMemory#realPageSize}} which takes encryption overhead into
> account,{{{}H{}}} is equal to {{{}BPlusIo#ITEMS_OFF{}}}, {{L}} is 8 bytes and
> {{X}} depends on the actual {{AbstractH2ExtrasInnerIO}} implementation and
> varies between 8 and 28 bytes.
> # If the configured inline size exceeds the computed maximum size or
> {{PageIO.MAX_PAYLOAD_SIZE}} then an exception must be thrown with a message
> that notifies the user of the incorrect inline size value. Note that this
> should only happen for _new_ indexes, if a nodes is started on top of an
> existing PDS, no exceptions should be thrown and a warning should be printed
> instead, to preserve backwards compatibility.
> # Fix the “Indexed columns of a row cannot be fully inlined into index”
> warning to recommend at most the maximum allowed inline size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-23120) Improve inline index feature
[
https://issues.apache.org/jira/browse/IGNITE-23120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17986531#comment-17986531
]
Maksim Timonin commented on IGNITE-23120:
-
>> Client nodes calculate inline size (for INDEXES system view):
OK, thanks for pointing that. But I don't thinks we should take this
functionality into account. If logic of calculation become different on server
and client nodes, then we should stop show this info on client nodes.
>> You propose to remove forced limit and just print warning, yes? And only on
>> SERVER nodes, I suppose - then we can use real page size
Yes. I suppose that having even 2 elements per page is also weird and might
affect performance. I think we should choose reasonable percentage of inline in
page (5-10-20%?) and warn if it exceeded. User will see the WARN, perftest it,
and if he is OK, then disable the WARN.
Actually we already have such functionality - `InlineRecommender`. It says when
inline size is small, let's also talk when inline size is big. WDYT, can we use
it?
>> But users will likely check log only after encountering problems
I thinks this is a bad practice. We don't have too much WARNs to ignore them.
There are few ways user can break Ignite :) For example, they can ddos Ignite
with huge objects and in the same time configure small heap size. it doesn't
mean we should check size of entries and heap and stop grid. We have to provide
properties to configure, and log WARNs if any limits are close.
> Improve inline index feature
>
>
> Key: IGNITE-23120
> URL: https://issues.apache.org/jira/browse/IGNITE-23120
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Pligin
>Assignee: Philipp Shergalis
>Priority: Major
>
> Ignite allows index rows to be inlined directly into the page. However, it
> doesn’t guard properly against too big inline size values. Currently, it uses
> {{PageIO.MAX_PAYLOAD_SIZE}} as the maximum allowed value, but this value can
> still be too large, because it does not take the page size and encryption
> (which adds additional bytes to the page header) into account. This possibly
> leads to a bad situation when only one item can fit in one page which can
> lead to BTree performance degradation.
> The following is expected to be done:
> # When inline size for an index is set, a maximum inline size should be
> computed:
> ## Considering we want to have _at least_ 2 items per page, here’s how the
> page layout with max inline size will look like: {{PS = H + L + I + L + I +
> L}} . Where PS - Page Size, H - page header size, L - size of the child link,
> I - item size.
> ## Using the above equation, we get the max possible item size to be equal
> to: {{I = (PS - H - 3L) / 2}} . However, for inline indexes, every item has
> an additional overhead to the actual inlined value (a.k.a payload), which
> depends on MVCC being present.
> ## Taking this into account, the maximum payload size will be equal: {{P =
> (PS - H - 3L) / 2 - X}} , where P - Payload size, X - overhead per item.
> ## In implementation terms, {{PS}} must be computed using the
> {{PageMemory#realPageSize}} which takes encryption overhead into
> account,{{{}H{}}} is equal to {{{}BPlusIo#ITEMS_OFF{}}}, {{L}} is 8 bytes and
> {{X}} depends on the actual {{AbstractH2ExtrasInnerIO}} implementation and
> varies between 8 and 28 bytes.
> # If the configured inline size exceeds the computed maximum size or
> {{PageIO.MAX_PAYLOAD_SIZE}} then an exception must be thrown with a message
> that notifies the user of the incorrect inline size value. Note that this
> should only happen for _new_ indexes, if a nodes is started on top of an
> existing PDS, no exceptions should be thrown and a warning should be printed
> instead, to preserve backwards compatibility.
> # Fix the “Indexed columns of a row cannot be fully inlined into index”
> warning to recommend at most the maximum allowed inline size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-23120) Improve inline index feature
[
https://issues.apache.org/jira/browse/IGNITE-23120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17986509#comment-17986509
]
Philipp Shergalis commented on IGNITE-23120:
[~timonin.maksim] Client nodes calculate inline size (for INDEXES system view):
{code:java}
ClientIndexDefinition def = new ClientIndexDefinition(idxFullName, idxCols);
idx = ctx.indexProcessor().createIndex(cacheInfo.cacheContext(), new
ClientIndexFactory(), def);
// Here inline size is just for information (to be shown in system view).
inlineSize = InlineIndexTree.computeInlineSize(
idxFullName.fullName(),
InlineIndexKeyTypeRegistry.types(idxCols.values(), new
IndexKeyTypeSettings()),
new ArrayList<>(idxCols.values()),
idxDesc.inlineSize(),
tbl.cacheInfo().config().getSqlIndexMaxInlineSize(),
log
);{code}
You propose to remove forced limit and just print warning, yes? And only on
SERVER nodes, I suppose - then we can use real page size
>> Then this also might happen with 2 entries also, but less likely. Am I
>> correct?
If we have 2 child entries per node and 128 levels limit, I assume we would
need 2^128 entries to cause problems
> Improve inline index feature
>
>
> Key: IGNITE-23120
> URL: https://issues.apache.org/jira/browse/IGNITE-23120
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Pligin
>Assignee: Philipp Shergalis
>Priority: Major
>
> Ignite allows index rows to be inlined directly into the page. However, it
> doesn’t guard properly against too big inline size values. Currently, it uses
> {{PageIO.MAX_PAYLOAD_SIZE}} as the maximum allowed value, but this value can
> still be too large, because it does not take the page size and encryption
> (which adds additional bytes to the page header) into account. This possibly
> leads to a bad situation when only one item can fit in one page which can
> lead to BTree performance degradation.
> The following is expected to be done:
> # When inline size for an index is set, a maximum inline size should be
> computed:
> ## Considering we want to have _at least_ 2 items per page, here’s how the
> page layout with max inline size will look like: {{PS = H + L + I + L + I +
> L}} . Where PS - Page Size, H - page header size, L - size of the child link,
> I - item size.
> ## Using the above equation, we get the max possible item size to be equal
> to: {{I = (PS - H - 3L) / 2}} . However, for inline indexes, every item has
> an additional overhead to the actual inlined value (a.k.a payload), which
> depends on MVCC being present.
> ## Taking this into account, the maximum payload size will be equal: {{P =
> (PS - H - 3L) / 2 - X}} , where P - Payload size, X - overhead per item.
> ## In implementation terms, {{PS}} must be computed using the
> {{PageMemory#realPageSize}} which takes encryption overhead into
> account,{{{}H{}}} is equal to {{{}BPlusIo#ITEMS_OFF{}}}, {{L}} is 8 bytes and
> {{X}} depends on the actual {{AbstractH2ExtrasInnerIO}} implementation and
> varies between 8 and 28 bytes.
> # If the configured inline size exceeds the computed maximum size or
> {{PageIO.MAX_PAYLOAD_SIZE}} then an exception must be thrown with a message
> that notifies the user of the incorrect inline size value. Note that this
> should only happen for _new_ indexes, if a nodes is started on top of an
> existing PDS, no exceptions should be thrown and a warning should be printed
> instead, to preserve backwards compatibility.
> # Fix the “Indexed columns of a row cannot be fully inlined into index”
> warning to recommend at most the maximum allowed inline size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-23120) Improve inline index feature
[
https://issues.apache.org/jira/browse/IGNITE-23120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17986505#comment-17986505
]
Maksim Timonin commented on IGNITE-23120:
-
Hi [~phillippko] , thanks for clarifying this.
>> Constant (for 1KB page) limit is used because page size is not available on
>>client nodes, but they also calculate inline size
Client nodes don't hold index trees, then they don't calculate inline size. See
`ClientIndexFactory`.
>> It actually leads to node failing, ticket description is misleading
AFAIU, node failure happens due to increased number of layers in btree. Then
this also might happen with 2 entries also, but less likely. Am I correct?
If yes, I suppose we need WARN user if a calculated inline size looks big
(takes some % of page size). Then a user should configure inline size for his
needs. What do you think?
> Improve inline index feature
>
>
> Key: IGNITE-23120
> URL: https://issues.apache.org/jira/browse/IGNITE-23120
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Pligin
>Assignee: Philipp Shergalis
>Priority: Major
>
> Ignite allows index rows to be inlined directly into the page. However, it
> doesn’t guard properly against too big inline size values. Currently, it uses
> {{PageIO.MAX_PAYLOAD_SIZE}} as the maximum allowed value, but this value can
> still be too large, because it does not take the page size and encryption
> (which adds additional bytes to the page header) into account. This possibly
> leads to a bad situation when only one item can fit in one page which can
> lead to BTree performance degradation.
> The following is expected to be done:
> # When inline size for an index is set, a maximum inline size should be
> computed:
> ## Considering we want to have _at least_ 2 items per page, here’s how the
> page layout with max inline size will look like: {{PS = H + L + I + L + I +
> L}} . Where PS - Page Size, H - page header size, L - size of the child link,
> I - item size.
> ## Using the above equation, we get the max possible item size to be equal
> to: {{I = (PS - H - 3L) / 2}} . However, for inline indexes, every item has
> an additional overhead to the actual inlined value (a.k.a payload), which
> depends on MVCC being present.
> ## Taking this into account, the maximum payload size will be equal: {{P =
> (PS - H - 3L) / 2 - X}} , where P - Payload size, X - overhead per item.
> ## In implementation terms, {{PS}} must be computed using the
> {{PageMemory#realPageSize}} which takes encryption overhead into
> account,{{{}H{}}} is equal to {{{}BPlusIo#ITEMS_OFF{}}}, {{L}} is 8 bytes and
> {{X}} depends on the actual {{AbstractH2ExtrasInnerIO}} implementation and
> varies between 8 and 28 bytes.
> # If the configured inline size exceeds the computed maximum size or
> {{PageIO.MAX_PAYLOAD_SIZE}} then an exception must be thrown with a message
> that notifies the user of the incorrect inline size value. Note that this
> should only happen for _new_ indexes, if a nodes is started on top of an
> existing PDS, no exceptions should be thrown and a warning should be printed
> instead, to preserve backwards compatibility.
> # Fix the “Indexed columns of a row cannot be fully inlined into index”
> warning to recommend at most the maximum allowed inline size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-23120) Improve inline index feature
[
https://issues.apache.org/jira/browse/IGNITE-23120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17986333#comment-17986333
]
Philipp Shergalis commented on IGNITE-23120:
[~timonin.maksim] Hi! There is a SO discussion with explanation:
[https://stackoverflow.com/questions/78932092/is-there-a-correlation-between-index-inline-size-and-index-column-datastring-ty]
It actually leads to node failing, ticket description is misleading
Constant (for 1KB page) limit is used because page size is not available on
client nodes and it seems impossible to calculate it with actual page size
This constant is too strict for clients with larger page size, but I was told
that inline size shouldn't be very big and it's not a problem
> Improve inline index feature
>
>
> Key: IGNITE-23120
> URL: https://issues.apache.org/jira/browse/IGNITE-23120
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Pligin
>Assignee: Philipp Shergalis
>Priority: Major
>
> Ignite allows index rows to be inlined directly into the page. However, it
> doesn’t guard properly against too big inline size values. Currently, it uses
> {{PageIO.MAX_PAYLOAD_SIZE}} as the maximum allowed value, but this value can
> still be too large, because it does not take the page size and encryption
> (which adds additional bytes to the page header) into account. This possibly
> leads to a bad situation when only one item can fit in one page which can
> lead to BTree performance degradation.
> The following is expected to be done:
> # When inline size for an index is set, a maximum inline size should be
> computed:
> ## Considering we want to have _at least_ 2 items per page, here’s how the
> page layout with max inline size will look like: {{PS = H + L + I + L + I +
> L}} . Where PS - Page Size, H - page header size, L - size of the child link,
> I - item size.
> ## Using the above equation, we get the max possible item size to be equal
> to: {{I = (PS - H - 3L) / 2}} . However, for inline indexes, every item has
> an additional overhead to the actual inlined value (a.k.a payload), which
> depends on MVCC being present.
> ## Taking this into account, the maximum payload size will be equal: {{P =
> (PS - H - 3L) / 2 - X}} , where P - Payload size, X - overhead per item.
> ## In implementation terms, {{PS}} must be computed using the
> {{PageMemory#realPageSize}} which takes encryption overhead into
> account,{{{}H{}}} is equal to {{{}BPlusIo#ITEMS_OFF{}}}, {{L}} is 8 bytes and
> {{X}} depends on the actual {{AbstractH2ExtrasInnerIO}} implementation and
> varies between 8 and 28 bytes.
> # If the configured inline size exceeds the computed maximum size or
> {{PageIO.MAX_PAYLOAD_SIZE}} then an exception must be thrown with a message
> that notifies the user of the incorrect inline size value. Note that this
> should only happen for _new_ indexes, if a nodes is started on top of an
> existing PDS, no exceptions should be thrown and a warning should be printed
> instead, to preserve backwards compatibility.
> # Fix the “Indexed columns of a row cannot be fully inlined into index”
> warning to recommend at most the maximum allowed inline size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-23120) Improve inline index feature
[
https://issues.apache.org/jira/browse/IGNITE-23120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17986320#comment-17986320
]
Maksim Timonin commented on IGNITE-23120:
-
Hi [~Vladimir Pligin] [~phillippko]
>> This possibly leads to a bad situation when only one item can fit in one
>> page which can lead to BTree performance degradation
Why this is a problem of Ignite? Users can configure inline size for their
needs.
Whether 2 entries per page MUCH better than 1 entry per page?
> Improve inline index feature
>
>
> Key: IGNITE-23120
> URL: https://issues.apache.org/jira/browse/IGNITE-23120
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Pligin
>Assignee: Philipp Shergalis
>Priority: Major
>
> Ignite allows index rows to be inlined directly into the page. However, it
> doesn’t guard properly against too big inline size values. Currently, it uses
> {{PageIO.MAX_PAYLOAD_SIZE}} as the maximum allowed value, but this value can
> still be too large, because it does not take the page size and encryption
> (which adds additional bytes to the page header) into account. This possibly
> leads to a bad situation when only one item can fit in one page which can
> lead to BTree performance degradation.
> The following is expected to be done:
> # When inline size for an index is set, a maximum inline size should be
> computed:
> ## Considering we want to have _at least_ 2 items per page, here’s how the
> page layout with max inline size will look like: {{PS = H + L + I + L + I +
> L}} . Where PS - Page Size, H - page header size, L - size of the child link,
> I - item size.
> ## Using the above equation, we get the max possible item size to be equal
> to: {{I = (PS - H - 3L) / 2}} . However, for inline indexes, every item has
> an additional overhead to the actual inlined value (a.k.a payload), which
> depends on MVCC being present.
> ## Taking this into account, the maximum payload size will be equal: {{P =
> (PS - H - 3L) / 2 - X}} , where P - Payload size, X - overhead per item.
> ## In implementation terms, {{PS}} must be computed using the
> {{PageMemory#realPageSize}} which takes encryption overhead into
> account,{{{}H{}}} is equal to {{{}BPlusIo#ITEMS_OFF{}}}, {{L}} is 8 bytes and
> {{X}} depends on the actual {{AbstractH2ExtrasInnerIO}} implementation and
> varies between 8 and 28 bytes.
> # If the configured inline size exceeds the computed maximum size or
> {{PageIO.MAX_PAYLOAD_SIZE}} then an exception must be thrown with a message
> that notifies the user of the incorrect inline size value. Note that this
> should only happen for _new_ indexes, if a nodes is started on top of an
> existing PDS, no exceptions should be thrown and a warning should be printed
> instead, to preserve backwards compatibility.
> # Fix the “Indexed columns of a row cannot be fully inlined into index”
> warning to recommend at most the maximum allowed inline size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
