[ 
https://issues.apache.org/jira/browse/IGNITE-6983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16279940#comment-16279940
 ] 

Taras Ledkov commented on IGNITE-6983:
--------------------------------------

The result of the simple simple benchmark of the index creation.
Host: 2x Xeon X5570 96Gb 512GB SSD 2048GB HDD 
Ignite configuration: storage is enabled, but checkpoint frequency is 
{{Long.MAX_VALUE}}, and data region is 60G (so checkpoint doesn't happen for 
the benchmark run).

|| master / patch  ||  parallel 1 || parallel  4 || parallel 8 ||
| Keys *5M | 185 / 193 {color:red}-4%{color}      | 65 / 61 
{color:green}+6%{color}     | 51 / 40 {color:green}+27%{color}|
| Keys *10M | 373 / 375 0%                                 | 129 / 123 +4%      
                         | 103 / 81 {color:green}+27%{color} |
| Keys *20M | 758 / 793 {color:red}-4%{color}     | 285 / 277 +2%               
                | 220 / 172 {color:green}+28%{color} |
| Keys *50M | 2117 / 2202 {color:red}-3%{color} | 728 / 671 
{color:green}+8%{color} | -- |

> SQL: optimize CREATE INDEX and BPlusTree interaction
> ----------------------------------------------------
>
>                 Key: IGNITE-6983
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6983
>             Project: Ignite
>          Issue Type: Task
>          Components: cache, sql
>            Reporter: Vladimir Ozerov
>              Labels: iep-1
>             Fix For: 2.4
>
>
> Currently index is built as follows:
> 1) Get next entry from partition's tree
> 2) Read it's key (copy to heap)
> 3) Acquire lock on {{GridCacheMapEntry}}
> 4) Lookup the same key in the tree from the top
> 5) Read it's value (copy to heap)
> 6) Add to index.
> This is very complex flow. We can optimize two things - tree lookup and value 
> deserialization as follows:
> 1) Every data page will have update counter, which is incremented every time 
> anything is changed.
> 2) When lock on {{GridCacheMapEntry}} is acquired, we will acquire lock on 
> the data page and re-check update counter. 
> 3) If page was changed between iterator read and lock acquisition then use 
> old flow. 
> 4) Otherwise - set read lock on the page, read value as *offheap* object, 
> apply it to index.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to