Applicability of term 'cache' to Apache Ignite

[Ilya Lantukh]

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 <[hidden email]>
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 <[hidden email]>:
>
> > 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 <[hidden email]>:
> >
> > > 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 <
> [hidden email]
> > >
> > > wrote:
> > >
> > > > On Wed, Oct 17, 2018 at 4:58 PM Denis Magda <[hidden email]>
> 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

[Alexey Zinoviev]

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 <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>:
> >
> > > 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 <[hidden email]>:
> > >
> > > > 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 <
> > [hidden email]
> > > >
> > > > wrote:
> > > >
> > > > > On Wed, Oct 17, 2018 at 4:58 PM Denis Magda <[hidden email]>
> > 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
>

[DaveWHarvey]

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 <[hidden email]>
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 <[hidden email]>:
>
> > 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 <[hidden email]>
> > 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 <[hidden email]>:
> > >
> > > > 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 <[hidden email]>:
> > > >
> > > > > 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 <
> > > [hidden email]
> > > > >
> > > > > wrote:
> > > > >
> > > > > > On Wed, Oct 17, 2018 at 4:58 PM Denis Magda <[hidden email]>
> > > 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
> >
>

[Ivan Pavlukhin]

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 <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>:
> >
> > > 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 <[hidden email]>
> > > 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 <[hidden email]
> >:
> > > >
> > > > > 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 <[hidden email]>:
> > > > >
> > > > > > 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 <
> > > > [hidden email]
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > On Wed, Oct 17, 2018 at 4:58 PM Denis Magda <[hidden email]
> >
> > > > 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

[dsetrakyan]

On Thu, Oct 18, 2018 at 5:18 AM David Harvey <[hidden email]> wrote:

> 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?


Multiple types per cache should still be supported, but I would definitely
advise against using it. Table per cache is much cleaner. On top of that,
Ignite has a notion of cache-groups, so you should combine all caches that
have identical configurations into one group. This will save you space and
make things faster.

D.

[dsetrakyan]

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 Павлухин Иван <[hidden email]> 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 <[hidden email]>:
>
> > 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 <[hidden email]>
> > 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 <[hidden email]>:
> > >
> > > > 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 <
> [hidden email]>
> > > > 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 <
> [hidden email]
> > >:
> > > > >
> > > > > > 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 <[hidden email]>:
> > > > > >
> > > > > > > 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 <
> > > > > [hidden email]
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Wed, Oct 17, 2018 at 4:58 PM Denis Magda <
> [hidden email]
> > >
> > > > > 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
>

[Valentin Kulichenko]

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 <[hidden email]>
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 Павлухин Иван <[hidden email]> 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 <[hidden email]>:
> >
> > > 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 <[hidden email]>
> > > 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 <[hidden email]>:
> > > >
> > > > > 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 <
> > [hidden email]>
> > > > > 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 <
> > [hidden email]
> > > >:
> > > > > >
> > > > > > > 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 <[hidden email]>:
> > > > > > >
> > > > > > > > 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 <
> > > > > > [hidden email]
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Wed, Oct 17, 2018 at 4:58 PM Denis Magda <
> > [hidden email]
> > > >
> > > > > > 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
> >
>

[dmagda]

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 <
[hidden email]> 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 <[hidden email]>
> 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 Павлухин Иван <[hidden email]>
> 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 <[hidden email]>:
> > >
> > > > 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 <
> [hidden email]>
> > > > 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 <[hidden email]>:
> > > > >
> > > > > > 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 <
> > > [hidden email]>
> > > > > > 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 <
> > > [hidden email]
> > > > >:
> > > > > > >
> > > > > > > > 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 <[hidden email]>:
> > > > > > > >
> > > > > > > > > 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 <
> > > > > > > [hidden email]
> > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > On Wed, Oct 17, 2018 at 4:58 PM Denis Magda <
> > > [hidden email]
> > > > >
> > > > > > > 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
> > >
> >
>