You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Ilya Lantukh <il...@gridgain.com> on 2018/10/15 11:49:11 UTC
Applicability of term 'cache' to Apache Ignite
Hi Igniters,
I would like to rise a question how we use the term *'cache'* in Ignite and
how it corresponds to terminology in IT industry in general.
From wikipedia:
In computing <https://en.wikipedia.org/wiki/Computing>, a *cache* /kæʃ/
<https://en.wikipedia.org/wiki/Help:IPA/English> *kash*
<https://en.wikipedia.org/wiki/Help:Pronunciation_respelling_key>, is a
hardware or software component that stores data so that future requests for
that data can be served faster; the data stored in a cache might be the
result of an earlier computation or a copy of data stored elsewhere. [1]
When the first version of Ignite was released, this term was correct. We
positioned Ignite mostly as an intermediate storage layer between
application and a database, designed to make data access faster.
However, since addition of native persistence we started to call Ignite a
"memory-centric database", and as far as I know, some organizations now use
it as a primary data storage, without underlying database. In this case,
calling our storage unit a *'cache'* causes unnecessary confusion.
Thus, I suggest to rename IgniteCache in Ignite 3.0 to something that would
fit both use-cases.
Personally I like the term IgniteSpace.
[1] https://en.wikipedia.org/wiki/Cache_(computing)
--
Best regards,
Ilya
Re: Applicability of term 'cache' to Apache Ignite
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Thu, Oct 18, 2018 at 5:18 AM David Harvey <sy...@gmail.com> 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.
Re: Applicability of term 'cache' to Apache Ignite
Posted by 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
> > >
> >
>
Re: Applicability of term 'cache' to Apache Ignite
Posted by 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
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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
Posted by Павлухин Иван <vo...@gmail.com>.
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 <vo...@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
Posted by 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 <vo...@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 <za...@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 <dm...@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
> >
>
Re: Applicability of term 'cache' to Apache Ignite
Posted by Alexey Zinoviev <za...@gmail.com>.
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 <vo...@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 <za...@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 <dm...@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
>
Re: Applicability of term 'cache' to Apache Ignite
Posted by 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 <vo...@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 <za...@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 <dm...@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
Re: Applicability of term 'cache' to Apache Ignite
Posted by Vladimir Ozerov <vo...@gridgain.com>.
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 <za...@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 <dm...@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.
> > >
> >
>
Re: Applicability of term 'cache' to Apache Ignite
Posted by Alexey Zinoviev <za...@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 <ds...@apache.org>
> wrote:
>
> > On Wed, Oct 17, 2018 at 4:58 PM Denis Magda <dm...@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.
> >
>
Re: Applicability of term 'cache' to Apache Ignite
Posted by 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 <ds...@apache.org>
wrote:
> On Wed, Oct 17, 2018 at 4:58 PM Denis Magda <dm...@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.
>
Re: Applicability of term 'cache' to Apache Ignite
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Wed, Oct 17, 2018 at 4:58 PM Denis Magda <dm...@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.
Re: Applicability of term 'cache' to Apache Ignite
Posted by Denis Magda <dm...@apache.org>.
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.
On Wed, Oct 17, 2018 at 3:55 PM Dmitriy Setrakyan <ds...@apache.org>
wrote:
> If dataset cannot be used, can we still consider "IgniteData"?
>
> D.
>
> On Wed, Oct 17, 2018 at 5:06 AM Ilya Lantukh <il...@gridgain.com>
> wrote:
>
> > As I see, many people agree that the term *"cache"* is outdated, but
> > consider these changes too disruptive.
> >
> > For me, keeping terminology up-to-date is important part of project
> > development. If we change some of our core terms with more relevant ones,
> > it indeed might cause confusion for current users, but in long term it
> will
> > help new users to understand what Ignite is and what it isn't. And most
> > short-term problems can easily be avoided by keeping @Deprecated
> > IgniteCache.
> >
> > On Wed, Oct 17, 2018 at 2:59 PM Ilya Lantukh <il...@gridgain.com>
> > wrote:
> >
> > > Unfortunately, we already use the word *"store"* for many other
> concepts,
> > > like CacheStore and PageStore. I'd prefer to avoid giving it one more
> > > meaning.
> > >
> > > As already mentioned, *"dataset"* has special meaning for ML folks.
> > >
> > > *"Bucket" *might give wrong association with bucket in a hash table.
> > >
> > > On Wed, Oct 17, 2018 at 1:49 PM Igor Sapego <is...@apache.org>
> wrote:
> > >
> > >> Well, the obvious term for me is a "Store" or "MemoryStore", as we
> > already
> > >> have persistence store.
> > >>
> > >> Best Regards,
> > >> Igor
> > >>
> > >>
> > >> On Wed, Oct 17, 2018 at 1:19 PM Andrey Kuznetsov <st...@gmail.com>
> > >> wrote:
> > >>
> > >> > I'm not an ML expert, so 'dataset' term just reminds me of various
> > >> client
> > >> > drivers to access tables from RDBM servers. For me, the only common
> > >> trait
> > >> > of all kinds of Ignite caches is their asociativity. So if we rename
> > >> them
> > >> > I'd suggest something like KVStore.
> > >> >
> > >> > ср, 17 окт. 2018 г. в 12:56, Alexey Zinoviev <
> zaleslaw.sin@gmail.com
> > >:
> > >> >
> > >> > > From my perspective, the main goal is to make easy the explanation
> > >> what
> > >> > is
> > >> > > Ignite on conferences, marketing deals, in papers, in
> documentation.
> > >> And
> > >> > > the
> > >> > > /cache/ term really reduces the area of Ignite usage in users
> minds.
> > >> > >
> > >> > > I don't support the critical changes in code base, but I support
> all
> > >> > > changes
> > >> > > that helps the goal described above in this letter.
> > >> > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > Best regards,
> > >> > Andrey Kuznetsov.
> > >> >
> > >>
> > >
> > >
> > > --
> > > Best regards,
> > > Ilya
> > >
> >
> >
> > --
> > Best regards,
> > Ilya
> >
>
Re: Applicability of term 'cache' to Apache Ignite
Posted by Dmitriy Setrakyan <ds...@apache.org>.
If dataset cannot be used, can we still consider "IgniteData"?
D.
On Wed, Oct 17, 2018 at 5:06 AM Ilya Lantukh <il...@gridgain.com> wrote:
> As I see, many people agree that the term *"cache"* is outdated, but
> consider these changes too disruptive.
>
> For me, keeping terminology up-to-date is important part of project
> development. If we change some of our core terms with more relevant ones,
> it indeed might cause confusion for current users, but in long term it will
> help new users to understand what Ignite is and what it isn't. And most
> short-term problems can easily be avoided by keeping @Deprecated
> IgniteCache.
>
> On Wed, Oct 17, 2018 at 2:59 PM Ilya Lantukh <il...@gridgain.com>
> wrote:
>
> > Unfortunately, we already use the word *"store"* for many other concepts,
> > like CacheStore and PageStore. I'd prefer to avoid giving it one more
> > meaning.
> >
> > As already mentioned, *"dataset"* has special meaning for ML folks.
> >
> > *"Bucket" *might give wrong association with bucket in a hash table.
> >
> > On Wed, Oct 17, 2018 at 1:49 PM Igor Sapego <is...@apache.org> wrote:
> >
> >> Well, the obvious term for me is a "Store" or "MemoryStore", as we
> already
> >> have persistence store.
> >>
> >> Best Regards,
> >> Igor
> >>
> >>
> >> On Wed, Oct 17, 2018 at 1:19 PM Andrey Kuznetsov <st...@gmail.com>
> >> wrote:
> >>
> >> > I'm not an ML expert, so 'dataset' term just reminds me of various
> >> client
> >> > drivers to access tables from RDBM servers. For me, the only common
> >> trait
> >> > of all kinds of Ignite caches is their asociativity. So if we rename
> >> them
> >> > I'd suggest something like KVStore.
> >> >
> >> > ср, 17 окт. 2018 г. в 12:56, Alexey Zinoviev <zaleslaw.sin@gmail.com
> >:
> >> >
> >> > > From my perspective, the main goal is to make easy the explanation
> >> what
> >> > is
> >> > > Ignite on conferences, marketing deals, in papers, in documentation.
> >> And
> >> > > the
> >> > > /cache/ term really reduces the area of Ignite usage in users minds.
> >> > >
> >> > > I don't support the critical changes in code base, but I support all
> >> > > changes
> >> > > that helps the goal described above in this letter.
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> >> > >
> >> >
> >> >
> >> > --
> >> > Best regards,
> >> > Andrey Kuznetsov.
> >> >
> >>
> >
> >
> > --
> > Best regards,
> > Ilya
> >
>
>
> --
> Best regards,
> Ilya
>
Re: Applicability of term 'cache' to Apache Ignite
Posted by Ilya Lantukh <il...@gridgain.com>.
As I see, many people agree that the term *"cache"* is outdated, but
consider these changes too disruptive.
For me, keeping terminology up-to-date is important part of project
development. If we change some of our core terms with more relevant ones,
it indeed might cause confusion for current users, but in long term it will
help new users to understand what Ignite is and what it isn't. And most
short-term problems can easily be avoided by keeping @Deprecated
IgniteCache.
On Wed, Oct 17, 2018 at 2:59 PM Ilya Lantukh <il...@gridgain.com> wrote:
> Unfortunately, we already use the word *"store"* for many other concepts,
> like CacheStore and PageStore. I'd prefer to avoid giving it one more
> meaning.
>
> As already mentioned, *"dataset"* has special meaning for ML folks.
>
> *"Bucket" *might give wrong association with bucket in a hash table.
>
> On Wed, Oct 17, 2018 at 1:49 PM Igor Sapego <is...@apache.org> wrote:
>
>> Well, the obvious term for me is a "Store" or "MemoryStore", as we already
>> have persistence store.
>>
>> Best Regards,
>> Igor
>>
>>
>> On Wed, Oct 17, 2018 at 1:19 PM Andrey Kuznetsov <st...@gmail.com>
>> wrote:
>>
>> > I'm not an ML expert, so 'dataset' term just reminds me of various
>> client
>> > drivers to access tables from RDBM servers. For me, the only common
>> trait
>> > of all kinds of Ignite caches is their asociativity. So if we rename
>> them
>> > I'd suggest something like KVStore.
>> >
>> > ср, 17 окт. 2018 г. в 12:56, Alexey Zinoviev <za...@gmail.com>:
>> >
>> > > From my perspective, the main goal is to make easy the explanation
>> what
>> > is
>> > > Ignite on conferences, marketing deals, in papers, in documentation.
>> And
>> > > the
>> > > /cache/ term really reduces the area of Ignite usage in users minds.
>> > >
>> > > I don't support the critical changes in code base, but I support all
>> > > changes
>> > > that helps the goal described above in this letter.
>> > >
>> > >
>> > >
>> > > --
>> > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>> > >
>> >
>> >
>> > --
>> > Best regards,
>> > Andrey Kuznetsov.
>> >
>>
>
>
> --
> Best regards,
> Ilya
>
--
Best regards,
Ilya
Re: Applicability of term 'cache' to Apache Ignite
Posted by Ilya Lantukh <il...@gridgain.com>.
Unfortunately, we already use the word *"store"* for many other concepts,
like CacheStore and PageStore. I'd prefer to avoid giving it one more
meaning.
As already mentioned, *"dataset"* has special meaning for ML folks.
*"Bucket" *might give wrong association with bucket in a hash table.
On Wed, Oct 17, 2018 at 1:49 PM Igor Sapego <is...@apache.org> wrote:
> Well, the obvious term for me is a "Store" or "MemoryStore", as we already
> have persistence store.
>
> Best Regards,
> Igor
>
>
> On Wed, Oct 17, 2018 at 1:19 PM Andrey Kuznetsov <st...@gmail.com>
> wrote:
>
> > I'm not an ML expert, so 'dataset' term just reminds me of various client
> > drivers to access tables from RDBM servers. For me, the only common trait
> > of all kinds of Ignite caches is their asociativity. So if we rename them
> > I'd suggest something like KVStore.
> >
> > ср, 17 окт. 2018 г. в 12:56, Alexey Zinoviev <za...@gmail.com>:
> >
> > > From my perspective, the main goal is to make easy the explanation what
> > is
> > > Ignite on conferences, marketing deals, in papers, in documentation.
> And
> > > the
> > > /cache/ term really reduces the area of Ignite usage in users minds.
> > >
> > > I don't support the critical changes in code base, but I support all
> > > changes
> > > that helps the goal described above in this letter.
> > >
> > >
> > >
> > > --
> > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> > >
> >
> >
> > --
> > Best regards,
> > Andrey Kuznetsov.
> >
>
--
Best regards,
Ilya
Re: Applicability of term 'cache' to Apache Ignite
Posted by Igor Sapego <is...@apache.org>.
Well, the obvious term for me is a "Store" or "MemoryStore", as we already
have persistence store.
Best Regards,
Igor
On Wed, Oct 17, 2018 at 1:19 PM Andrey Kuznetsov <st...@gmail.com> wrote:
> I'm not an ML expert, so 'dataset' term just reminds me of various client
> drivers to access tables from RDBM servers. For me, the only common trait
> of all kinds of Ignite caches is their asociativity. So if we rename them
> I'd suggest something like KVStore.
>
> ср, 17 окт. 2018 г. в 12:56, Alexey Zinoviev <za...@gmail.com>:
>
> > From my perspective, the main goal is to make easy the explanation what
> is
> > Ignite on conferences, marketing deals, in papers, in documentation. And
> > the
> > /cache/ term really reduces the area of Ignite usage in users minds.
> >
> > I don't support the critical changes in code base, but I support all
> > changes
> > that helps the goal described above in this letter.
> >
> >
> >
> > --
> > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> >
>
>
> --
> Best regards,
> Andrey Kuznetsov.
>
Re: Applicability of term 'cache' to Apache Ignite
Posted by Andrey Kuznetsov <st...@gmail.com>.
I'm not an ML expert, so 'dataset' term just reminds me of various client
drivers to access tables from RDBM servers. For me, the only common trait
of all kinds of Ignite caches is their asociativity. So if we rename them
I'd suggest something like KVStore.
ср, 17 окт. 2018 г. в 12:56, Alexey Zinoviev <za...@gmail.com>:
> From my perspective, the main goal is to make easy the explanation what is
> Ignite on conferences, marketing deals, in papers, in documentation. And
> the
> /cache/ term really reduces the area of Ignite usage in users minds.
>
> I don't support the critical changes in code base, but I support all
> changes
> that helps the goal described above in this letter.
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>
--
Best regards,
Andrey Kuznetsov.
Re: Applicability of term 'cache' to Apache Ignite
Posted by Alexey Zinoviev <za...@gmail.com>.
From my perspective, the main goal is to make easy the explanation what is
Ignite on conferences, marketing deals, in papers, in documentation. And the
/cache/ term really reduces the area of Ignite usage in users minds.
I don't support the critical changes in code base, but I support all changes
that helps the goal described above in this letter.
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: Applicability of term 'cache' to Apache Ignite
Posted by Alexey Zinoviev <za...@gmail.com>.
I'm sorry, but the IgniteDataset can not be used like a basic term, due to
it's ML specific term and also we have a few kind of datasets (that are not
equivalents of IgniteCache/Space and etc) like IgniteDataset,
PartitionBasedDataset, LocalCachedDataset and so on.
Of course, we could find a dataset as a primitive in Spark (but the main
reason to add this term there was a collaboration with Python - oriented
data scientists)
The real 'dataset' concept includes a lot of operations under the
'datasets': different math functions and etc
My suggestion: IDataBucket
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: Applicability of term 'cache' to Apache Ignite
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Hm... How about IgniteData or IgniteDataset?
D.
On Tue, Oct 16, 2018 at 11:52 AM Stanislav Lukyanov <st...@gmail.com>
wrote:
> I had an idea of “IgniteBucket” as in “a place to put things in”.
>
> But I think I like “space” since it sounds like and conceptually very
> close (if not identical) to “tablespace”.
>
> I have to say I never heard of JavaSpaces :) Don’t think many people will
> recall that.
>
> Stan
>
> From: Dmitriy Setrakyan
> Sent: 16 октября 2018 г. 20:21
> To: dev
> Subject: Re: Applicability of term 'cache' to Apache Ignite
>
> Although I agree that this change is disruptive, can we just entertain
> Ilya's idea for a bit? What if we were designing Ignite from scratch, what
> different name would we give to the IgniteCache abstraction? Ilya suggested
> "IgniteSpace", but I do not like it as it sounds too similar to JavaSpaces
> [1], which is an obsolete technology at this point.
>
> Any other ideas?
>
> [1]
> https://www.oracle.com/technetwork/articles/java/javaspaces-140665.html
>
> D.
>
> On Tue, Oct 16, 2018 at 6:27 AM Ivan Rakov <iv...@gmail.com> wrote:
>
> > Agree with Vladimir here.
> >
> > Let's stick to the "principle of least astonishment" - all current users
> > will be surprised if we'll rename IgniteCache, new users won't be
> > greatly surprised due to compliance with JCache.
> >
> > Best Regards,
> > Ivan Rakov
> >
> > On 16.10.2018 15:53, Vladimir Ozerov wrote:
> > > What is the ultimate goal of all these changes? While I agree that term
> > > "cache" might be a bit outdated at the moment, there is nothing
> > > fundamentally wrong with - data is still being cached in memory with an
> > > option to persist it on disk. We should remember, that legacy and
> > previous
> > > user experience is of great importance for users. And disruptive
> changes
> > > such as rename of a basic concept may make adoption of a new versions
> > > harder for users, with very questionable benefits on the other side.
> > >
> > > As far as wrappers, personally I do not support this idea. Both "cache"
> > and
> > > "sql" are access methods to some information ("space"), rather than
> > > wrappers around it. Moreover, it is hard to say whether we will have
> SQL
> > > API at all, because this is big effort with not very clear value,
> > provided
> > > that there are industrial interfaces (JDBC, ODBC).
> > >
> > > On Tue, Oct 16, 2018 at 3:23 PM Stanislav Lukyanov <
> > stanlukyanov@gmail.com>
> > > wrote:
> > >
> > >> How about separating our JCache implementation from the core of the
> > >> probuct.
> > >>
> > >> Currently IgniteCache is the heart of Ignite. It is the basic storage
> > unit.
> > >> At the same time, it is the direct implementation of the JCache API,
> > >> and some of the JCache features align somewhat awkwardly with Ignite
> > >> concepts.
> > >>
> > >> Would be nice to have something like IgniteSpace as our core
> component,
> > >> and have other components built on top of it as wrappers providing
> > various
> > >> APIs.
> > >> For example
> > >> - IgniteSpace itself is a distributed storage unit, that is
> partitioned,
> > >> that has affinity, etc;
> > >> note that it doesn’t have to have ANY particular API to add data, even
> > >> key-value
> > >> - IgniteCache is a wrapper around IgniteSpace that allows to store
> > >> key-value pairs and implements JCache API
> > >> - IgniteSql (we’re doing it eventually, right?) is a wrapper around
> > >> IgniteSpace that allows to store SQL tables and implements ANSI SQL
> > >> - IgniteQueue is a wrapper that implements Queue
> > >> and so on.
> > >>
> > >> WDYT?
> > >>
> > >> Stan
> > >>
> > >> From: Ilya Lantukh
> > >> Sent: 15 октября 2018 г. 14:49
> > >> To: dev@ignite.apache.org
> > >> Subject: Applicability of term 'cache' to Apache Ignite
> > >>
> > >> Hi Igniters,
> > >>
> > >> I would like to rise a question how we use the term *'cache'* in
> Ignite
> > and
> > >> how it corresponds to terminology in IT industry in general.
> > >>
> > >> From wikipedia:
> > >> In computing <https://en.wikipedia.org/wiki/Computing>, a *cache*
> /kæʃ/
> > >> <https://en.wikipedia.org/wiki/Help:IPA/English> *kash*
> > >> <https://en.wikipedia.org/wiki/Help:Pronunciation_respelling_key>,
> is a
> > >> hardware or software component that stores data so that future
> requests
> > for
> > >> that data can be served faster; the data stored in a cache might be
> the
> > >> result of an earlier computation or a copy of data stored elsewhere.
> [1]
> > >>
> > >> When the first version of Ignite was released, this term was correct.
> We
> > >> positioned Ignite mostly as an intermediate storage layer between
> > >> application and a database, designed to make data access faster.
> > >>
> > >> However, since addition of native persistence we started to call
> Ignite
> > a
> > >> "memory-centric database", and as far as I know, some organizations
> now
> > use
> > >> it as a primary data storage, without underlying database. In this
> case,
> > >> calling our storage unit a *'cache'* causes unnecessary confusion.
> > >>
> > >> Thus, I suggest to rename IgniteCache in Ignite 3.0 to something that
> > would
> > >> fit both use-cases.
> > >> Personally I like the term IgniteSpace.
> > >>
> > >> [1] https://en.wikipedia.org/wiki/Cache_(computing)
> > >> --
> > >> Best regards,
> > >> Ilya
> > >>
> > >>
> >
> >
>
>
RE: Applicability of term 'cache' to Apache Ignite
Posted by Stanislav Lukyanov <st...@gmail.com>.
I had an idea of “IgniteBucket” as in “a place to put things in”.
But I think I like “space” since it sounds like and conceptually very close (if not identical) to “tablespace”.
I have to say I never heard of JavaSpaces :) Don’t think many people will recall that.
Stan
From: Dmitriy Setrakyan
Sent: 16 октября 2018 г. 20:21
To: dev
Subject: Re: Applicability of term 'cache' to Apache Ignite
Although I agree that this change is disruptive, can we just entertain
Ilya's idea for a bit? What if we were designing Ignite from scratch, what
different name would we give to the IgniteCache abstraction? Ilya suggested
"IgniteSpace", but I do not like it as it sounds too similar to JavaSpaces
[1], which is an obsolete technology at this point.
Any other ideas?
[1] https://www.oracle.com/technetwork/articles/java/javaspaces-140665.html
D.
On Tue, Oct 16, 2018 at 6:27 AM Ivan Rakov <iv...@gmail.com> wrote:
> Agree with Vladimir here.
>
> Let's stick to the "principle of least astonishment" - all current users
> will be surprised if we'll rename IgniteCache, new users won't be
> greatly surprised due to compliance with JCache.
>
> Best Regards,
> Ivan Rakov
>
> On 16.10.2018 15:53, Vladimir Ozerov wrote:
> > What is the ultimate goal of all these changes? While I agree that term
> > "cache" might be a bit outdated at the moment, there is nothing
> > fundamentally wrong with - data is still being cached in memory with an
> > option to persist it on disk. We should remember, that legacy and
> previous
> > user experience is of great importance for users. And disruptive changes
> > such as rename of a basic concept may make adoption of a new versions
> > harder for users, with very questionable benefits on the other side.
> >
> > As far as wrappers, personally I do not support this idea. Both "cache"
> and
> > "sql" are access methods to some information ("space"), rather than
> > wrappers around it. Moreover, it is hard to say whether we will have SQL
> > API at all, because this is big effort with not very clear value,
> provided
> > that there are industrial interfaces (JDBC, ODBC).
> >
> > On Tue, Oct 16, 2018 at 3:23 PM Stanislav Lukyanov <
> stanlukyanov@gmail.com>
> > wrote:
> >
> >> How about separating our JCache implementation from the core of the
> >> probuct.
> >>
> >> Currently IgniteCache is the heart of Ignite. It is the basic storage
> unit.
> >> At the same time, it is the direct implementation of the JCache API,
> >> and some of the JCache features align somewhat awkwardly with Ignite
> >> concepts.
> >>
> >> Would be nice to have something like IgniteSpace as our core component,
> >> and have other components built on top of it as wrappers providing
> various
> >> APIs.
> >> For example
> >> - IgniteSpace itself is a distributed storage unit, that is partitioned,
> >> that has affinity, etc;
> >> note that it doesn’t have to have ANY particular API to add data, even
> >> key-value
> >> - IgniteCache is a wrapper around IgniteSpace that allows to store
> >> key-value pairs and implements JCache API
> >> - IgniteSql (we’re doing it eventually, right?) is a wrapper around
> >> IgniteSpace that allows to store SQL tables and implements ANSI SQL
> >> - IgniteQueue is a wrapper that implements Queue
> >> and so on.
> >>
> >> WDYT?
> >>
> >> Stan
> >>
> >> From: Ilya Lantukh
> >> Sent: 15 октября 2018 г. 14:49
> >> To: dev@ignite.apache.org
> >> Subject: Applicability of term 'cache' to Apache Ignite
> >>
> >> Hi Igniters,
> >>
> >> I would like to rise a question how we use the term *'cache'* in Ignite
> and
> >> how it corresponds to terminology in IT industry in general.
> >>
> >> From wikipedia:
> >> In computing <https://en.wikipedia.org/wiki/Computing>, a *cache* /kæʃ/
> >> <https://en.wikipedia.org/wiki/Help:IPA/English> *kash*
> >> <https://en.wikipedia.org/wiki/Help:Pronunciation_respelling_key>, is a
> >> hardware or software component that stores data so that future requests
> for
> >> that data can be served faster; the data stored in a cache might be the
> >> result of an earlier computation or a copy of data stored elsewhere. [1]
> >>
> >> When the first version of Ignite was released, this term was correct. We
> >> positioned Ignite mostly as an intermediate storage layer between
> >> application and a database, designed to make data access faster.
> >>
> >> However, since addition of native persistence we started to call Ignite
> a
> >> "memory-centric database", and as far as I know, some organizations now
> use
> >> it as a primary data storage, without underlying database. In this case,
> >> calling our storage unit a *'cache'* causes unnecessary confusion.
> >>
> >> Thus, I suggest to rename IgniteCache in Ignite 3.0 to something that
> would
> >> fit both use-cases.
> >> Personally I like the term IgniteSpace.
> >>
> >> [1] https://en.wikipedia.org/wiki/Cache_(computing)
> >> --
> >> Best regards,
> >> Ilya
> >>
> >>
>
>
Re: Applicability of term 'cache' to Apache Ignite
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Although I agree that this change is disruptive, can we just entertain
Ilya's idea for a bit? What if we were designing Ignite from scratch, what
different name would we give to the IgniteCache abstraction? Ilya suggested
"IgniteSpace", but I do not like it as it sounds too similar to JavaSpaces
[1], which is an obsolete technology at this point.
Any other ideas?
[1] https://www.oracle.com/technetwork/articles/java/javaspaces-140665.html
D.
On Tue, Oct 16, 2018 at 6:27 AM Ivan Rakov <iv...@gmail.com> wrote:
> Agree with Vladimir here.
>
> Let's stick to the "principle of least astonishment" - all current users
> will be surprised if we'll rename IgniteCache, new users won't be
> greatly surprised due to compliance with JCache.
>
> Best Regards,
> Ivan Rakov
>
> On 16.10.2018 15:53, Vladimir Ozerov wrote:
> > What is the ultimate goal of all these changes? While I agree that term
> > "cache" might be a bit outdated at the moment, there is nothing
> > fundamentally wrong with - data is still being cached in memory with an
> > option to persist it on disk. We should remember, that legacy and
> previous
> > user experience is of great importance for users. And disruptive changes
> > such as rename of a basic concept may make adoption of a new versions
> > harder for users, with very questionable benefits on the other side.
> >
> > As far as wrappers, personally I do not support this idea. Both "cache"
> and
> > "sql" are access methods to some information ("space"), rather than
> > wrappers around it. Moreover, it is hard to say whether we will have SQL
> > API at all, because this is big effort with not very clear value,
> provided
> > that there are industrial interfaces (JDBC, ODBC).
> >
> > On Tue, Oct 16, 2018 at 3:23 PM Stanislav Lukyanov <
> stanlukyanov@gmail.com>
> > wrote:
> >
> >> How about separating our JCache implementation from the core of the
> >> probuct.
> >>
> >> Currently IgniteCache is the heart of Ignite. It is the basic storage
> unit.
> >> At the same time, it is the direct implementation of the JCache API,
> >> and some of the JCache features align somewhat awkwardly with Ignite
> >> concepts.
> >>
> >> Would be nice to have something like IgniteSpace as our core component,
> >> and have other components built on top of it as wrappers providing
> various
> >> APIs.
> >> For example
> >> - IgniteSpace itself is a distributed storage unit, that is partitioned,
> >> that has affinity, etc;
> >> note that it doesn’t have to have ANY particular API to add data, even
> >> key-value
> >> - IgniteCache is a wrapper around IgniteSpace that allows to store
> >> key-value pairs and implements JCache API
> >> - IgniteSql (we’re doing it eventually, right?) is a wrapper around
> >> IgniteSpace that allows to store SQL tables and implements ANSI SQL
> >> - IgniteQueue is a wrapper that implements Queue
> >> and so on.
> >>
> >> WDYT?
> >>
> >> Stan
> >>
> >> From: Ilya Lantukh
> >> Sent: 15 октября 2018 г. 14:49
> >> To: dev@ignite.apache.org
> >> Subject: Applicability of term 'cache' to Apache Ignite
> >>
> >> Hi Igniters,
> >>
> >> I would like to rise a question how we use the term *'cache'* in Ignite
> and
> >> how it corresponds to terminology in IT industry in general.
> >>
> >> From wikipedia:
> >> In computing <https://en.wikipedia.org/wiki/Computing>, a *cache* /kæʃ/
> >> <https://en.wikipedia.org/wiki/Help:IPA/English> *kash*
> >> <https://en.wikipedia.org/wiki/Help:Pronunciation_respelling_key>, is a
> >> hardware or software component that stores data so that future requests
> for
> >> that data can be served faster; the data stored in a cache might be the
> >> result of an earlier computation or a copy of data stored elsewhere. [1]
> >>
> >> When the first version of Ignite was released, this term was correct. We
> >> positioned Ignite mostly as an intermediate storage layer between
> >> application and a database, designed to make data access faster.
> >>
> >> However, since addition of native persistence we started to call Ignite
> a
> >> "memory-centric database", and as far as I know, some organizations now
> use
> >> it as a primary data storage, without underlying database. In this case,
> >> calling our storage unit a *'cache'* causes unnecessary confusion.
> >>
> >> Thus, I suggest to rename IgniteCache in Ignite 3.0 to something that
> would
> >> fit both use-cases.
> >> Personally I like the term IgniteSpace.
> >>
> >> [1] https://en.wikipedia.org/wiki/Cache_(computing)
> >> --
> >> Best regards,
> >> Ilya
> >>
> >>
>
>
Re: Applicability of term 'cache' to Apache Ignite
Posted by Ivan Rakov <iv...@gmail.com>.
Agree with Vladimir here.
Let's stick to the "principle of least astonishment" - all current users
will be surprised if we'll rename IgniteCache, new users won't be
greatly surprised due to compliance with JCache.
Best Regards,
Ivan Rakov
On 16.10.2018 15:53, Vladimir Ozerov wrote:
> What is the ultimate goal of all these changes? While I agree that term
> "cache" might be a bit outdated at the moment, there is nothing
> fundamentally wrong with - data is still being cached in memory with an
> option to persist it on disk. We should remember, that legacy and previous
> user experience is of great importance for users. And disruptive changes
> such as rename of a basic concept may make adoption of a new versions
> harder for users, with very questionable benefits on the other side.
>
> As far as wrappers, personally I do not support this idea. Both "cache" and
> "sql" are access methods to some information ("space"), rather than
> wrappers around it. Moreover, it is hard to say whether we will have SQL
> API at all, because this is big effort with not very clear value, provided
> that there are industrial interfaces (JDBC, ODBC).
>
> On Tue, Oct 16, 2018 at 3:23 PM Stanislav Lukyanov <st...@gmail.com>
> wrote:
>
>> How about separating our JCache implementation from the core of the
>> probuct.
>>
>> Currently IgniteCache is the heart of Ignite. It is the basic storage unit.
>> At the same time, it is the direct implementation of the JCache API,
>> and some of the JCache features align somewhat awkwardly with Ignite
>> concepts.
>>
>> Would be nice to have something like IgniteSpace as our core component,
>> and have other components built on top of it as wrappers providing various
>> APIs.
>> For example
>> - IgniteSpace itself is a distributed storage unit, that is partitioned,
>> that has affinity, etc;
>> note that it doesn’t have to have ANY particular API to add data, even
>> key-value
>> - IgniteCache is a wrapper around IgniteSpace that allows to store
>> key-value pairs and implements JCache API
>> - IgniteSql (we’re doing it eventually, right?) is a wrapper around
>> IgniteSpace that allows to store SQL tables and implements ANSI SQL
>> - IgniteQueue is a wrapper that implements Queue
>> and so on.
>>
>> WDYT?
>>
>> Stan
>>
>> From: Ilya Lantukh
>> Sent: 15 октября 2018 г. 14:49
>> To: dev@ignite.apache.org
>> Subject: Applicability of term 'cache' to Apache Ignite
>>
>> Hi Igniters,
>>
>> I would like to rise a question how we use the term *'cache'* in Ignite and
>> how it corresponds to terminology in IT industry in general.
>>
>> From wikipedia:
>> In computing <https://en.wikipedia.org/wiki/Computing>, a *cache* /kæʃ/
>> <https://en.wikipedia.org/wiki/Help:IPA/English> *kash*
>> <https://en.wikipedia.org/wiki/Help:Pronunciation_respelling_key>, is a
>> hardware or software component that stores data so that future requests for
>> that data can be served faster; the data stored in a cache might be the
>> result of an earlier computation or a copy of data stored elsewhere. [1]
>>
>> When the first version of Ignite was released, this term was correct. We
>> positioned Ignite mostly as an intermediate storage layer between
>> application and a database, designed to make data access faster.
>>
>> However, since addition of native persistence we started to call Ignite a
>> "memory-centric database", and as far as I know, some organizations now use
>> it as a primary data storage, without underlying database. In this case,
>> calling our storage unit a *'cache'* causes unnecessary confusion.
>>
>> Thus, I suggest to rename IgniteCache in Ignite 3.0 to something that would
>> fit both use-cases.
>> Personally I like the term IgniteSpace.
>>
>> [1] https://en.wikipedia.org/wiki/Cache_(computing)
>> --
>> Best regards,
>> Ilya
>>
>>
Re: Applicability of term 'cache' to Apache Ignite
Posted by Ilya Lantukh <il...@gridgain.com>.
To me it seems that usage of term *"cache" *restricts adoption of Apache
Ignite as a primary data storage. If I didn't know anything about internal
implementation, storing critical data in IgniteCache would make me feel
that I'm doing something wrong. Of course it's just my point of view, and
things might look different for other Ignite users - so I'd like to ask
community members to share their opinion.
On Tue, Oct 16, 2018 at 3:54 PM Vladimir Ozerov <vo...@gridgain.com>
wrote:
> What is the ultimate goal of all these changes? While I agree that term
> "cache" might be a bit outdated at the moment, there is nothing
> fundamentally wrong with - data is still being cached in memory with an
> option to persist it on disk. We should remember, that legacy and previous
> user experience is of great importance for users. And disruptive changes
> such as rename of a basic concept may make adoption of a new versions
> harder for users, with very questionable benefits on the other side.
>
> As far as wrappers, personally I do not support this idea. Both "cache" and
> "sql" are access methods to some information ("space"), rather than
> wrappers around it. Moreover, it is hard to say whether we will have SQL
> API at all, because this is big effort with not very clear value, provided
> that there are industrial interfaces (JDBC, ODBC).
>
> On Tue, Oct 16, 2018 at 3:23 PM Stanislav Lukyanov <stanlukyanov@gmail.com
> >
> wrote:
>
> > How about separating our JCache implementation from the core of the
> > probuct.
> >
> > Currently IgniteCache is the heart of Ignite. It is the basic storage
> unit.
> > At the same time, it is the direct implementation of the JCache API,
> > and some of the JCache features align somewhat awkwardly with Ignite
> > concepts.
> >
> > Would be nice to have something like IgniteSpace as our core component,
> > and have other components built on top of it as wrappers providing
> various
> > APIs.
> > For example
> > - IgniteSpace itself is a distributed storage unit, that is partitioned,
> > that has affinity, etc;
> > note that it doesn’t have to have ANY particular API to add data, even
> > key-value
> > - IgniteCache is a wrapper around IgniteSpace that allows to store
> > key-value pairs and implements JCache API
> > - IgniteSql (we’re doing it eventually, right?) is a wrapper around
> > IgniteSpace that allows to store SQL tables and implements ANSI SQL
> > - IgniteQueue is a wrapper that implements Queue
> > and so on.
> >
> > WDYT?
> >
> > Stan
> >
> > From: Ilya Lantukh
> > Sent: 15 октября 2018 г. 14:49
> > To: dev@ignite.apache.org
> > Subject: Applicability of term 'cache' to Apache Ignite
> >
> > Hi Igniters,
> >
> > I would like to rise a question how we use the term *'cache'* in Ignite
> and
> > how it corresponds to terminology in IT industry in general.
> >
> > From wikipedia:
> > In computing <https://en.wikipedia.org/wiki/Computing>, a *cache* /kæʃ/
> > <https://en.wikipedia.org/wiki/Help:IPA/English> *kash*
> > <https://en.wikipedia.org/wiki/Help:Pronunciation_respelling_key>, is a
> > hardware or software component that stores data so that future requests
> for
> > that data can be served faster; the data stored in a cache might be the
> > result of an earlier computation or a copy of data stored elsewhere. [1]
> >
> > When the first version of Ignite was released, this term was correct. We
> > positioned Ignite mostly as an intermediate storage layer between
> > application and a database, designed to make data access faster.
> >
> > However, since addition of native persistence we started to call Ignite a
> > "memory-centric database", and as far as I know, some organizations now
> use
> > it as a primary data storage, without underlying database. In this case,
> > calling our storage unit a *'cache'* causes unnecessary confusion.
> >
> > Thus, I suggest to rename IgniteCache in Ignite 3.0 to something that
> would
> > fit both use-cases.
> > Personally I like the term IgniteSpace.
> >
> > [1] https://en.wikipedia.org/wiki/Cache_(computing)
> > --
> > Best regards,
> > Ilya
> >
> >
>
--
Best regards,
Ilya
Re: Applicability of term 'cache' to Apache Ignite
Posted by Vladimir Ozerov <vo...@gridgain.com>.
What is the ultimate goal of all these changes? While I agree that term
"cache" might be a bit outdated at the moment, there is nothing
fundamentally wrong with - data is still being cached in memory with an
option to persist it on disk. We should remember, that legacy and previous
user experience is of great importance for users. And disruptive changes
such as rename of a basic concept may make adoption of a new versions
harder for users, with very questionable benefits on the other side.
As far as wrappers, personally I do not support this idea. Both "cache" and
"sql" are access methods to some information ("space"), rather than
wrappers around it. Moreover, it is hard to say whether we will have SQL
API at all, because this is big effort with not very clear value, provided
that there are industrial interfaces (JDBC, ODBC).
On Tue, Oct 16, 2018 at 3:23 PM Stanislav Lukyanov <st...@gmail.com>
wrote:
> How about separating our JCache implementation from the core of the
> probuct.
>
> Currently IgniteCache is the heart of Ignite. It is the basic storage unit.
> At the same time, it is the direct implementation of the JCache API,
> and some of the JCache features align somewhat awkwardly with Ignite
> concepts.
>
> Would be nice to have something like IgniteSpace as our core component,
> and have other components built on top of it as wrappers providing various
> APIs.
> For example
> - IgniteSpace itself is a distributed storage unit, that is partitioned,
> that has affinity, etc;
> note that it doesn’t have to have ANY particular API to add data, even
> key-value
> - IgniteCache is a wrapper around IgniteSpace that allows to store
> key-value pairs and implements JCache API
> - IgniteSql (we’re doing it eventually, right?) is a wrapper around
> IgniteSpace that allows to store SQL tables and implements ANSI SQL
> - IgniteQueue is a wrapper that implements Queue
> and so on.
>
> WDYT?
>
> Stan
>
> From: Ilya Lantukh
> Sent: 15 октября 2018 г. 14:49
> To: dev@ignite.apache.org
> Subject: Applicability of term 'cache' to Apache Ignite
>
> Hi Igniters,
>
> I would like to rise a question how we use the term *'cache'* in Ignite and
> how it corresponds to terminology in IT industry in general.
>
> From wikipedia:
> In computing <https://en.wikipedia.org/wiki/Computing>, a *cache* /kæʃ/
> <https://en.wikipedia.org/wiki/Help:IPA/English> *kash*
> <https://en.wikipedia.org/wiki/Help:Pronunciation_respelling_key>, is a
> hardware or software component that stores data so that future requests for
> that data can be served faster; the data stored in a cache might be the
> result of an earlier computation or a copy of data stored elsewhere. [1]
>
> When the first version of Ignite was released, this term was correct. We
> positioned Ignite mostly as an intermediate storage layer between
> application and a database, designed to make data access faster.
>
> However, since addition of native persistence we started to call Ignite a
> "memory-centric database", and as far as I know, some organizations now use
> it as a primary data storage, without underlying database. In this case,
> calling our storage unit a *'cache'* causes unnecessary confusion.
>
> Thus, I suggest to rename IgniteCache in Ignite 3.0 to something that would
> fit both use-cases.
> Personally I like the term IgniteSpace.
>
> [1] https://en.wikipedia.org/wiki/Cache_(computing)
> --
> Best regards,
> Ilya
>
>
RE: Applicability of term 'cache' to Apache Ignite
Posted by Stanislav Lukyanov <st...@gmail.com>.
How about separating our JCache implementation from the core of the probuct.
Currently IgniteCache is the heart of Ignite. It is the basic storage unit.
At the same time, it is the direct implementation of the JCache API,
and some of the JCache features align somewhat awkwardly with Ignite concepts.
Would be nice to have something like IgniteSpace as our core component,
and have other components built on top of it as wrappers providing various APIs.
For example
- IgniteSpace itself is a distributed storage unit, that is partitioned, that has affinity, etc;
note that it doesn’t have to have ANY particular API to add data, even key-value
- IgniteCache is a wrapper around IgniteSpace that allows to store key-value pairs and implements JCache API
- IgniteSql (we’re doing it eventually, right?) is a wrapper around IgniteSpace that allows to store SQL tables and implements ANSI SQL
- IgniteQueue is a wrapper that implements Queue
and so on.
WDYT?
Stan
From: Ilya Lantukh
Sent: 15 октября 2018 г. 14:49
To: dev@ignite.apache.org
Subject: Applicability of term 'cache' to Apache Ignite
Hi Igniters,
I would like to rise a question how we use the term *'cache'* in Ignite and
how it corresponds to terminology in IT industry in general.
From wikipedia:
In computing <https://en.wikipedia.org/wiki/Computing>, a *cache* /kæʃ/
<https://en.wikipedia.org/wiki/Help:IPA/English> *kash*
<https://en.wikipedia.org/wiki/Help:Pronunciation_respelling_key>, is a
hardware or software component that stores data so that future requests for
that data can be served faster; the data stored in a cache might be the
result of an earlier computation or a copy of data stored elsewhere. [1]
When the first version of Ignite was released, this term was correct. We
positioned Ignite mostly as an intermediate storage layer between
application and a database, designed to make data access faster.
However, since addition of native persistence we started to call Ignite a
"memory-centric database", and as far as I know, some organizations now use
it as a primary data storage, without underlying database. In this case,
calling our storage unit a *'cache'* causes unnecessary confusion.
Thus, I suggest to rename IgniteCache in Ignite 3.0 to something that would
fit both use-cases.
Personally I like the term IgniteSpace.
[1] https://en.wikipedia.org/wiki/Cache_(computing)
--
Best regards,
Ilya