Apache Ignite Developers - Legacy Mail Archive

Applicability of term 'cache' to Apache Ignite

Classic

List

Threaded

28 messages Options

Ilya Lantukh

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

Stanislav Lukyanov

RE: Applicability of term 'cache' to Apache Ignite

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

Vladimir Ozerov

Re: Applicability of term 'cache' to Apache Ignite

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

Ilya Lantukh

Re: Applicability of term 'cache' to Apache Ignite

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

Ivan Rakov

Re: Applicability of term 'cache' to Apache Ignite

In reply to this post by Vladimir Ozerov

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

dsetrakyan

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

Stanislav Lukyanov

RE: Applicability of term 'cache' to Apache Ignite

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

dsetrakyan

Re: Applicability of term 'cache' to Apache Ignite

Hm... How about IgniteData or IgniteDataset?

D.

On Tue, Oct 16, 2018 at 11:52 AM Stanislav Lukyanov <[hidden email]>
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 <[hidden email]> 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 <
> > [hidden email]>
> > > 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: [hidden email]
> > >> 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
> > >>
> > >>
> >
> >
>
>

Alexey Zinoviev

Re: Applicability of term 'cache' to Apache Ignite

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/

Alexey Zinoviev

Re: Applicability of term 'cache' to Apache Ignite

In reply to this post by Vladimir Ozerov

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/

Andrey Kuznetsov

Re: Applicability of term 'cache' to Apache Ignite

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

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

Igor Sapego-2

Re: Applicability of term 'cache' to Apache Ignite

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

Ilya Lantukh

Re: Applicability of term 'cache' to Apache Ignite

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

Ilya Lantukh

Re: Applicability of term 'cache' to Apache Ignite

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

dsetrakyan

Re: Applicability of term 'cache' to Apache Ignite

If dataset cannot be used, can we still consider "IgniteData"?

D.

On Wed, Oct 17, 2018 at 5:06 AM Ilya Lantukh <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> >> 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 <[hidden email]
> >:
> >> >
> >> > > 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
>

dmagda

Re: Applicability of term 'cache' to Apache Ignite

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

> If dataset cannot be used, can we still consider "IgniteData"?
>
> D.
>
> On Wed, Oct 17, 2018 at 5:06 AM Ilya Lantukh <[hidden email]>
> 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 <[hidden email]>
> > 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 <[hidden email]>
> 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 <[hidden email]>
> > >> 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 <
> [hidden email]
> > >:
> > >> >
> > >> > > 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
> >
>

dsetrakyan

Re: Applicability of term 'cache' to Apache Ignite

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.

dmagda

Re: Applicability of term 'cache' to Apache Ignite

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

Alexey Zinoviev

Re: Applicability of term 'cache' to Apache Ignite

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

Vladimir Ozerov

Re: Applicability of term 'cache' to Apache Ignite

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