ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Page replacement policy improvements (when persistent is enabled)
Date Thu, 16 Aug 2018 09:27:30 GMT

None database I know use separate regions for index pages due to the reason
I expressed above. Instead, they split all pages into two groups - hot and
cold. With certain rules on how to move pages inside and between these
groups. None of these algorithms are complex enough. In fact, they are
pretty straightforward and battle-tested. When implemented properly it
doesn't matter whether the page is index page or data page. The only thing
that matter is how often it is accessed. This is critical piece that we
lack in the product - our policy is called "random *LRU*", while in reality
is not LRU at all.

As far as index pages replacement we do not know whether this is problem at
all. We heard some complaints that it might be a problem. But we didn't see
any proofs (thanks to lack of monitoring) and even if this is a problem, we
do not understand how severe it is. May be it adds 1% overhead and can be
ignored for years, may be it adds 1000% overhead and must be fixed

This is sensitive piece of a product. Let's use objective data, not

On Thu, Aug 16, 2018 at 12:08 PM Dmitriy Setrakyan <dsetrakyan@apache.org>

> On Thu, Aug 16, 2018 at 2:01 AM, Vladimir Ozerov <vozerov@gridgain.com>
> wrote:
> > Hi Dima,
> >
> > Putting index pages in separate region is wrong approach, because data
> > pages may be equally important on certain workloads, especially in
> > heap-organized databases, such as Ignite
> Never seen a use case where the data page was more important than the index
> page. I think we are getting into a hypothetical land. Most Ignite users
> are having the reverse problem - index pages get evicted in the same way as
> data pages.
> Currently, we are solving it in a most awkward way by trying to give index
> pages a different eviction policy. A right solution would be to stick them
> into a different region and control the eviction policy for the index
> region separately from the data region.
> D.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message