Re: Applicability of term 'cache' to Apache Ignite

[Valentin Kulichenko <va...@gmail.com>]

Igniters,

I would like to resurrect this discussion, as we have a chance to make the
change in Ignite 3.0.

The 'cache' term is clearly outdated and does not describe the
functionality of Ignite. It looks like the term 'table' got the most
support so far, and I think it quite accurately describes the generic tuple
storage described in the "Schema-first Approach" IEP [1].

Pure key-value API can be implemented as an IgniteMap facade, and
effectively become one of the data structures, along with IgniteQueue and
others.

Please share your thoughts.

[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach

-Val

On Thu, Oct 18, 2018 at 9:56 AM Dmitriy Setrakyan <ds...@apache.org>
wrote:

> I am beginning to like IgniteTable as well. How would something like this
> be introduced to Ignite? Would we have IgniteTable extend IgniteCache? What
> would happen to cache groups?
>
> D.
>
> On Thu, Oct 18, 2018 at 7:58 AM Павлухин Иван <vo...@gmail.com> wrote:
>
> > HI all,
> >
> > +1 for "table" from me. For me "table" has several benefits:
> > 1. It's common and consequently easy to explain and understand.
> > 2. It's quite universal. One can worry that "table" does not describes
> > key-value storage well.
> >     I don't see any problem here, because Hash Table data structure
> > contains "table" word it it's name.
> >     Also DHT comes to mind. Internally we have GridDhtCache class. So
> it's
> > already a "table".
> >
> > Regarding multiple QueryEntities in single cache. Correct me if I am
> wrong,
> > but currently we do not recommend to use them.
> >
> > чт, 18 окт. 2018 г. в 15:18, David Harvey <sy...@gmail.com>:
> >
> > > We had a terminology agreement early on where we agreed to call them
> > > caches, but we still call them tables anyway.
> > >
> > > When I finally understood how you could have multiple tables in a
> single
> > > cache,  I tried to find example use cases, but couldn't.  Is there
> even a
> > > test with multiple queryEntities?
> > >
> > > On Thu, Oct 18, 2018, 8:10 AM Alexey Zinoviev <za...@gmail.com>
> > > wrote:
> > >
> > > > From my perspective (ML module), it will be very easy to talk about
> > > Ignite
> > > > in SQL terms like table (with additional information about ability to
> > > make
> > > > key-value CRUD operations, not only SELECT * FROM Table)
> > > > Also we could look on PostgreSQL with different plugins for SQL
> > extension
> > > > like PostGIS or support of JSON-B and ability to store not only
> planar
> > > data
> > > > with strict schema (I agrre here with Vladimir).
> > > >
> > > > чт, 18 окт. 2018 г. в 14:33, Ilya Lantukh <il...@gridgain.com>:
> > > >
> > > > > I thought that current "caches" and "tables" have 1-to-N relation.
> If
> > > > > that's not a problem, than I also think that "table" is the best
> > term.
> > > > >
> > > > > On Thu, Oct 18, 2018 at 9:29 AM Vladimir Ozerov <
> > vozerov@gridgain.com>
> > > > > wrote:
> > > > >
> > > > > > Well, I never thought about term “table” as a replacement for
> > > “cache”,
> > > > > but
> > > > > > it appears to be good candidate.
> > > > > >
> > > > > > This is used by many some major vendors whose underlying storage
> is
> > > > > indeed
> > > > > > a kind of key-value data structure. Most well-known example is
> > MySQL
> > > > with
> > > > > > its MyISAM engine. Table can be used for both fixed and flexible
> > > (e.g.
> > > > > > JSON) schemas, as well as key-value access (hash map -> hash
> table,
> > > > both
> > > > > > are good).
> > > > > >
> > > > > > Another important thing - we already use term “table”, and it is
> > > always
> > > > > > hard to explain our users how it relates to “cache”. If “cache”
> is
> > > > > dropped,
> > > > > > then a single term “table” will be used everywhere.
> > > > > >
> > > > > > Last, but not least - “table” works well for both in-memory and
> > > > > persistent
> > > > > > modes.
> > > > > >
> > > > > > So if we are really aim to rename “cache”, then “table” is the
> best
> > > > > > candidate I’ve heard so far.
> > > > > >
> > > > > > чт, 18 окт. 2018 г. в 8:40, Alexey Zinoviev <
> > zaleslaw.sin@gmail.com
> > > >:
> > > > > >
> > > > > > > Or we could extend our SQL commands by "GET BY KEY = X" and
> "PUT
> > > (x1,
> > > > > x2,
> > > > > > > x3) BY KEY = X" and the IgniteTable could be correct.
> > > > > > > Agree with Denis that each table in the 3rd normal form is like
> > > > > key-value
> > > > > > > store. Key-value operations are only subset of rich SQL
> commands.
> > > > > > >
> > > > > > > The problem with IgniteData that it's too common. Also, it's
> > > > difficult
> > > > > to
> > > > > > > understand is it a plural or single object? For instance, the
> > bunch
> > > > of
> > > > > > > IgniteTables could be IgniteData. But the set of IgniteData?
> > > > > IgniteDatum?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > чт, 18 окт. 2018 г. в 4:18, Denis Magda <dm...@apache.org>:
> > > > > > >
> > > > > > > > Key-value calls are just primary key based calls. From a user
> > > > > > > perspective,
> > > > > > > > it's the same as "SELECT * FROM table WHERE primary_idx = X",
> > > just
> > > > > > > > different API.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Denis
> > > > > > > >
> > > > > > > > On Wed, Oct 17, 2018 at 5:04 PM Dmitriy Setrakyan <
> > > > > > dsetrakyan@apache.org
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Wed, Oct 17, 2018 at 4:58 PM Denis Magda <
> > dmagda@apache.org
> > > >
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > I've been calling everything "tables" instead of "caches"
> > > for a
> > > > > > > while.
> > > > > > > > > The
> > > > > > > > > > main reason is the maturity of our SQL engine - seeing
> more
> > > SQL
> > > > > > users
> > > > > > > > and
> > > > > > > > > > deployments which talk "tables" language.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > I think "IgniteTable" only implies SQL, not key-value. We
> > need
> > > > > both.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Ilya
> > > > >
> > > >
> > >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >
>

Re: Applicability of term 'cache' to Apache Ignite

[Denis Magda <dm...@apache.org>]

I cast my vote for the "table". This term is generic, well-understood and
naturally fits SQL-intensive use cases. Basically, we don't need to
reinvent the wheel and the "table" aligns with our internal storage
structure proposed for 3.0.

Vladimir Ozerov's thoughts down below this discussion thread are worth
paying attention to. Vladimir suggests settling with the "table".

-
Denis


On Fri, Sep 18, 2020 at 3:12 PM Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:

> Igniters,
>
> I would like to resurrect this discussion, as we have a chance to make the
> change in Ignite 3.0.
>
> The 'cache' term is clearly outdated and does not describe the
> functionality of Ignite. It looks like the term 'table' got the most
> support so far, and I think it quite accurately describes the generic tuple
> storage described in the "Schema-first Approach" IEP [1].
>
> Pure key-value API can be implemented as an IgniteMap facade, and
> effectively become one of the data structures, along with IgniteQueue and
> others.
>
> Please share your thoughts.
>
> [1]
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach
>
> -Val
>
> On Thu, Oct 18, 2018 at 9:56 AM Dmitriy Setrakyan <ds...@apache.org>
> wrote:
>
> > I am beginning to like IgniteTable as well. How would something like this
> > be introduced to Ignite? Would we have IgniteTable extend IgniteCache?
> What
> > would happen to cache groups?
> >
> > D.
> >
> > On Thu, Oct 18, 2018 at 7:58 AM Павлухин Иван <vo...@gmail.com>
> wrote:
> >
> > > HI all,
> > >
> > > +1 for "table" from me. For me "table" has several benefits:
> > > 1. It's common and consequently easy to explain and understand.
> > > 2. It's quite universal. One can worry that "table" does not describes
> > > key-value storage well.
> > >     I don't see any problem here, because Hash Table data structure
> > > contains "table" word it it's name.
> > >     Also DHT comes to mind. Internally we have GridDhtCache class. So
> > it's
> > > already a "table".
> > >
> > > Regarding multiple QueryEntities in single cache. Correct me if I am
> > wrong,
> > > but currently we do not recommend to use them.
> > >
> > > чт, 18 окт. 2018 г. в 15:18, David Harvey <sy...@gmail.com>:
> > >
> > > > We had a terminology agreement early on where we agreed to call them
> > > > caches, but we still call them tables anyway.
> > > >
> > > > When I finally understood how you could have multiple tables in a
> > single
> > > > cache,  I tried to find example use cases, but couldn't.  Is there
> > even a
> > > > test with multiple queryEntities?
> > > >
> > > > On Thu, Oct 18, 2018, 8:10 AM Alexey Zinoviev <
> zaleslaw.sin@gmail.com>
> > > > wrote:
> > > >
> > > > > From my perspective (ML module), it will be very easy to talk about
> > > > Ignite
> > > > > in SQL terms like table (with additional information about ability
> to
> > > > make
> > > > > key-value CRUD operations, not only SELECT * FROM Table)
> > > > > Also we could look on PostgreSQL with different plugins for SQL
> > > extension
> > > > > like PostGIS or support of JSON-B and ability to store not only
> > planar
> > > > data
> > > > > with strict schema (I agrre here with Vladimir).
> > > > >
> > > > > чт, 18 окт. 2018 г. в 14:33, Ilya Lantukh <il...@gridgain.com>:
> > > > >
> > > > > > I thought that current "caches" and "tables" have 1-to-N
> relation.
> > If
> > > > > > that's not a problem, than I also think that "table" is the best
> > > term.
> > > > > >
> > > > > > On Thu, Oct 18, 2018 at 9:29 AM Vladimir Ozerov <
> > > vozerov@gridgain.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Well, I never thought about term “table” as a replacement for
> > > > “cache”,
> > > > > > but
> > > > > > > it appears to be good candidate.
> > > > > > >
> > > > > > > This is used by many some major vendors whose underlying
> storage
> > is
> > > > > > indeed
> > > > > > > a kind of key-value data structure. Most well-known example is
> > > MySQL
> > > > > with
> > > > > > > its MyISAM engine. Table can be used for both fixed and
> flexible
> > > > (e.g.
> > > > > > > JSON) schemas, as well as key-value access (hash map -> hash
> > table,
> > > > > both
> > > > > > > are good).
> > > > > > >
> > > > > > > Another important thing - we already use term “table”, and it
> is
> > > > always
> > > > > > > hard to explain our users how it relates to “cache”. If “cache”
> > is
> > > > > > dropped,
> > > > > > > then a single term “table” will be used everywhere.
> > > > > > >
> > > > > > > Last, but not least - “table” works well for both in-memory and
> > > > > > persistent
> > > > > > > modes.
> > > > > > >
> > > > > > > So if we are really aim to rename “cache”, then “table” is the
> > best
> > > > > > > candidate I’ve heard so far.
> > > > > > >
> > > > > > > чт, 18 окт. 2018 г. в 8:40, Alexey Zinoviev <
> > > zaleslaw.sin@gmail.com
> > > > >:
> > > > > > >
> > > > > > > > Or we could extend our SQL commands by "GET BY KEY = X" and
> > "PUT
> > > > (x1,
> > > > > > x2,
> > > > > > > > x3) BY KEY = X" and the IgniteTable could be correct.
> > > > > > > > Agree with Denis that each table in the 3rd normal form is
> like
> > > > > > key-value
> > > > > > > > store. Key-value operations are only subset of rich SQL
> > commands.
> > > > > > > >
> > > > > > > > The problem with IgniteData that it's too common. Also, it's
> > > > > difficult
> > > > > > to
> > > > > > > > understand is it a plural or single object? For instance, the
> > > bunch
> > > > > of
> > > > > > > > IgniteTables could be IgniteData. But the set of IgniteData?
> > > > > > IgniteDatum?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > чт, 18 окт. 2018 г. в 4:18, Denis Magda <dm...@apache.org>:
> > > > > > > >
> > > > > > > > > Key-value calls are just primary key based calls. From a
> user
> > > > > > > > perspective,
> > > > > > > > > it's the same as "SELECT * FROM table WHERE primary_idx =
> X",
> > > > just
> > > > > > > > > different API.
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > On Wed, Oct 17, 2018 at 5:04 PM Dmitriy Setrakyan <
> > > > > > > dsetrakyan@apache.org
> > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > On Wed, Oct 17, 2018 at 4:58 PM Denis Magda <
> > > dmagda@apache.org
> > > > >
> > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > I've been calling everything "tables" instead of
> "caches"
> > > > for a
> > > > > > > > while.
> > > > > > > > > > The
> > > > > > > > > > > main reason is the maturity of our SQL engine - seeing
> > more
> > > > SQL
> > > > > > > users
> > > > > > > > > and
> > > > > > > > > > > deployments which talk "tables" language.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > I think "IgniteTable" only implies SQL, not key-value. We
> > > need
> > > > > > both.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Ilya
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> >
>