[
https://issues.apache.org/jira/browse/IGNITE-21906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834334#comment-17834334
]
Aleksandr Polovtcev commented on IGNITE-21906:
----------------------------------------------
I've set the inline size to 0 in all HashIndexTrees and got the following
results running YCSB KV scenario:
Baseline:
[OVERALL]
RunTime(ms): 40648
Throughput(ops/sec): 6150.364101554812
Operations(payload): 250000
Operations(warm-up): 50000
[READ]
Operations: 250000
AverageLatency(us): 152.338772
MinLatency(us): 125
MaxLatency(us): 16355
95thPercentileLatency(us): 179
99thPercentileLatency(us): 232
Return=OK: 250000
No inlining
[OVERALL]
RunTime(ms): 41874
Throughput(ops/sec): 5970.291827864546
Operations(payload): 250000
Operations(warm-up): 50000
[READ]
Operations: 250000
AverageLatency(us): 158.05806
MinLatency(us): 126
MaxLatency(us): 23661
95thPercentileLatency(us): 186
99thPercentileLatency(us): 245
Return=OK: 250000
Looks like everything got a little bit slower.
> Consider disabling inline in PK index by default
> ------------------------------------------------
>
> Key: IGNITE-21906
> URL: https://issues.apache.org/jira/browse/IGNITE-21906
> Project: Ignite
> Issue Type: Improvement
> Reporter: Ivan Bessonov
> Assignee: Aleksandr Polovtcev
> Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In aipersist/aimem we attempt to inline binary tuples into pages for hash
> indexes by default. This, in theory, saves us from the necessity of accessing
> binary tuples from data pages for comparison, which is slower than comparing
> inlined data.
> But, assuming the good hash distribution, we would only have to do the real
> comparison for the matched tuple. At the same time, inlined data might be
> substantially larger than hash+link, meaning that B+Tree with inlined data
> has bigger height, which correlates with slower search speed.
> So, we have both pros and cons for inlining, and the only real way to
> reconcile them is to compare them with some benchmarks. This is exactly what
> I propose.
> TL;DR: force inline size to be 0 for hash indices and benchmark for put/get
> operations, with large enough amount of data.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
