Folks,
Currently we allow multiple SQL tables per cache. This considered a bad practice as single cache is getting polluted with unrelated key-value pairs. Earlier this use case made sense due to high per-cache overhead and some limitation of FairAffinityFunction which cannot guarantee equal partition distribution. AFAIK both issues are resolved. I think we have no reason to allow multiple tables per cache at the moment. If we restrict it to one table we will be able to simplify significantly query engine internals and improve performance a bit. Also it aligns nicely with upcoming CREATE TABLE feature. What do you think about this change? Vladimir. |
I've not come across a case where we used multiple tables per cache and generally advise against it. Because it is allowed I have though witnessed cases where users at an early stage use one cache for multiple entities and ended up confused. From a users stand point I would agree with Vlad to remove this.
C. > On 19 Apr 2017, at 21:32, Vladimir Ozerov <[hidden email]> wrote: > > Folks, > > Currently we allow multiple SQL tables per cache. This considered a bad > practice as single cache is getting polluted with unrelated key-value pairs. > > Earlier this use case made sense due to high per-cache overhead and some > limitation of FairAffinityFunction which cannot guarantee equal partition > distribution. AFAIK both issues are resolved. > > I think we have no reason to allow multiple tables per cache at the moment. > If we restrict it to one table we will be able to simplify significantly > query engine internals and improve performance a bit. Also it aligns nicely > with upcoming CREATE TABLE feature. > > What do you think about this change? > > Vladimir. |
Hi,
Actually, this is useful in case of migration from RDBMS where you have multiple tables in the same schema. And if you don't want to amend queries specifying cache name explicitly then one cache with multiple instances (tables) is a very convenient way to go, especially in the case of a very large set of queries. I know at least about one such case. Kind regards, Alex. On Thu, Apr 20, 2017 at 12:26 AM, Christos Erotocritou < [hidden email]> wrote: > I've not come across a case where we used multiple tables per cache and > generally advise against it. Because it is allowed I have though witnessed > cases where users at an early stage use one cache for multiple entities and > ended up confused. From a users stand point I would agree with Vlad to > remove this. > > C. > > > On 19 Apr 2017, at 21:32, Vladimir Ozerov <[hidden email]> wrote: > > > > Folks, > > > > Currently we allow multiple SQL tables per cache. This considered a bad > > practice as single cache is getting polluted with unrelated key-value > pairs. > > > > Earlier this use case made sense due to high per-cache overhead and some > > limitation of FairAffinityFunction which cannot guarantee equal partition > > distribution. AFAIK both issues are resolved. > > > > I think we have no reason to allow multiple tables per cache at the > moment. > > If we restrict it to one table we will be able to simplify significantly > > query engine internals and improve performance a bit. Also it aligns > nicely > > with upcoming CREATE TABLE feature. > > > > What do you think about this change? > > > > Vladimir. >
Kind regards,
Alexander |
Alex F.,
Once we introduce true “schema name” as a part of DDL activities this will no longer be an issue. Presently, you use “single-cache->multiple-types(tables)” as a workaround to simplify development. In general, I’m in the same boat with Chris - didn’t see production use cases that leveraged from this feature. Vovan, I hope we can rework this in 2.1, if the consensus is achieved, right? I would encourage us to stop stuffing 2.0 with minor changes :) It’s time to pass it on to QA. — Denis > On Apr 19, 2017, at 2:34 PM, Alexander Fedotov <[hidden email]> wrote: > > Hi, > Actually, this is useful in case of migration from RDBMS where you have > multiple tables in the same schema. And if you don't want to amend queries > specifying cache name explicitly then one cache with multiple instances > (tables) is a very convenient way to go, especially in the case of a very > large set of queries. > I know at least about one such case. > > Kind regards, > Alex. > > On Thu, Apr 20, 2017 at 12:26 AM, Christos Erotocritou < > [hidden email]> wrote: > >> I've not come across a case where we used multiple tables per cache and >> generally advise against it. Because it is allowed I have though witnessed >> cases where users at an early stage use one cache for multiple entities and >> ended up confused. From a users stand point I would agree with Vlad to >> remove this. >> >> C. >> >>> On 19 Apr 2017, at 21:32, Vladimir Ozerov <[hidden email]> wrote: >>> >>> Folks, >>> >>> Currently we allow multiple SQL tables per cache. This considered a bad >>> practice as single cache is getting polluted with unrelated key-value >> pairs. >>> >>> Earlier this use case made sense due to high per-cache overhead and some >>> limitation of FairAffinityFunction which cannot guarantee equal partition >>> distribution. AFAIK both issues are resolved. >>> >>> I think we have no reason to allow multiple tables per cache at the >> moment. >>> If we restrict it to one table we will be able to simplify significantly >>> query engine internals and improve performance a bit. Also it aligns >> nicely >>> with upcoming CREATE TABLE feature. >>> >>> What do you think about this change? >>> >>> Vladimir. >> |
Can we make cache-per-table a requirement only for CREATE TABLE command?
Not sure why would we have to prohibit the current behavior. On Wed, Apr 19, 2017 at 4:15 PM, Denis Magda <[hidden email]> wrote: > Alex F., > > Once we introduce true “schema name” as a part of DDL activities this will > no longer be an issue. Presently, you use “single-cache->multiple-types(tables)” > as a workaround to simplify development. > > In general, I’m in the same boat with Chris - didn’t see production use > cases that leveraged from this feature. > > Vovan, I hope we can rework this in 2.1, if the consensus is achieved, > right? I would encourage us to stop stuffing 2.0 with minor changes :) It’s > time to pass it on to QA. > > — > Denis > > > On Apr 19, 2017, at 2:34 PM, Alexander Fedotov < > [hidden email]> wrote: > > > > Hi, > > Actually, this is useful in case of migration from RDBMS where you have > > multiple tables in the same schema. And if you don't want to amend > queries > > specifying cache name explicitly then one cache with multiple instances > > (tables) is a very convenient way to go, especially in the case of a very > > large set of queries. > > I know at least about one such case. > > > > Kind regards, > > Alex. > > > > On Thu, Apr 20, 2017 at 12:26 AM, Christos Erotocritou < > > [hidden email]> wrote: > > > >> I've not come across a case where we used multiple tables per cache and > >> generally advise against it. Because it is allowed I have though > witnessed > >> cases where users at an early stage use one cache for multiple entities > and > >> ended up confused. From a users stand point I would agree with Vlad to > >> remove this. > >> > >> C. > >> > >>> On 19 Apr 2017, at 21:32, Vladimir Ozerov <[hidden email]> > wrote: > >>> > >>> Folks, > >>> > >>> Currently we allow multiple SQL tables per cache. This considered a bad > >>> practice as single cache is getting polluted with unrelated key-value > >> pairs. > >>> > >>> Earlier this use case made sense due to high per-cache overhead and > some > >>> limitation of FairAffinityFunction which cannot guarantee equal > partition > >>> distribution. AFAIK both issues are resolved. > >>> > >>> I think we have no reason to allow multiple tables per cache at the > >> moment. > >>> If we restrict it to one table we will be able to simplify > significantly > >>> query engine internals and improve performance a bit. Also it aligns > >> nicely > >>> with upcoming CREATE TABLE feature. > >>> > >>> What do you think about this change? > >>> > >>> Vladimir. > >> > > |
Free forum by Nabble | Edit this page |