Hi Igniters, I may repeat what was said early, but still: I prefer way of speeding up indexes proposed by Vladimir in addition to page replacement optimizations related to index pages.
Also recently Ivan Rakov created issue intended to optimize findPageForReplacement method, it can also help with performance. End user can see results as index speedup, but internally it is about page replacement process. Sincerely, Dmitriy Pavlov вт, 8 мая 2018 г. в 1:12, Vladimir Ozerov <voze...@gridgain.com>: > Dima, Denis, > > Please stoooooooop wanting this! :-) > > Guys, there are no in-memory indexes just to be in-memory. Let me briefly > explain what other vendors do and why. There are three approaches: > 1) You may create *skip-list* based in-memory index. Goal - speedup > *READS*, not writes. Examples: MS SQL, Couchbase > 2) You may create *columnar* in-memory index. Goal - speedup *SCANS* in > OLAP cases, not writes. Example: Oracle [1] > 3) You may drop my beloved cache groups and introduce > *tablespaces*.instead. > Then you assign data and indexes to different tablespaces and assign them > to *different disks*. Goal - speedup index *WRITES* [2]. Example: all major > vendors. E.g. putting data and indexes on different disks is one of the > main Oracle recommendation in their capacity planning documents. > > As you see, nobody afraid of writes. Neither should we do. > > Vladimir. > > [1] > > http://www.oracle.com/technetwork/database/in-memory/overview/twp-oracle-database-in-memory-2245633.pdf > [2] This is one of the reasons why I want to kill cache groups so > desperately. > > On Mon, May 7, 2018 at 9:03 PM, Denis Magda <dma...@apache.org> wrote: > > > Truly like the idea of having a separate "indexes in memory only mode" > > regardless of the optimizations Vladimir keeps track of. > > > > In my observations, some database vendors support this as the only mode > > requiring to rebuild the indexes on a restart which confirms that there > is > > a demand for this configuration in the industry. > > > > -- > > Denis > > > > On Mon, May 7, 2018 at 7:42 AM, Vladimir Ozerov <voze...@gridgain.com> > > wrote: > > > > > Agree. > > > > > > On Mon, May 7, 2018 at 5:20 PM, Dmitriy Setrakyan < > dsetrak...@apache.org > > > > > > wrote: > > > > > > > On Mon, May 7, 2018 at 2:09 AM, Vladimir Ozerov < > voze...@gridgain.com> > > > > wrote: > > > > > > > > > Hi Dima, > > > > > > > > > > Update with indexes would definitely be slower than update without > > > them. > > > > > The question is how much slower. For now the slowdown comes mostly > > from > > > > > excessive data page reads ([1] and [2] in my previous email) > leading > > to > > > > > page evictions and additional IO. To the contrast, usually only a > > > single > > > > > page write is needed to update an index. Correct index > implementation > > > > ([1] > > > > > and [2] from previous email) would eliminate data page reads > > altogether > > > > and > > > > > should give dramatic speedup. > > > > > > > > > > > > > Sounds great. The changes you are suggesting should give us a great > > > > performance boost. Hopefully they should not take too long to > > implement. > > > > > > > > Regardless, once you are done, we should still perform a benchmark > with > > > > persistence indexes vs memory-only indexes. If memory-only will be > more > > > > than 20% faster, we should still implement it. > > > > > > > > D. > > > > > > > > > >
