You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Vladimir Ozerov <vo...@gridgain.com> on 2017/04/19 20:32:36 UTC
Allow only one SQL table per cache
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.
Re: Allow only one SQL table per cache
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <dm...@apache.org> 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 <
> alexander.fedotoff@gmail.com> 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 <
> > christos@gridgain.com> 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 <vo...@gridgain.com>
> 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.
> >>
>
>
Re: Allow only one SQL table per cache
Posted by Denis Magda <dm...@apache.org>.
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 <al...@gmail.com> 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 <
> christos@gridgain.com> 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 <vo...@gridgain.com> 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.
>>
Re: Allow only one SQL table per cache
Posted by Alexander Fedotov <al...@gmail.com>.
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 <
christos@gridgain.com> 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 <vo...@gridgain.com> 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.
>
Re: Allow only one SQL table per cache
Posted by Christos Erotocritou <ch...@gridgain.com>.
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 <vo...@gridgain.com> 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.