[DISCUSSION] Renaming Ignite's product category

[dmagda]

Igniters,

Throughout the history of our project, we could see how the addition of
certain features required us to reassess the project's name and category.

Before Ignite joined the ASF, it supported only compute APIs resembling the
MapReduce engine of Hadoop. Those days, it was fair to define Ignite as "a
distributed in-memory computing engine". Next, at the time of the project
donation, it already included key-value/SQL/transactional APIs, was used as
a distributed cache, and significantly outgrew the "in-memory computing
engine" use case. That's how the project transitioned to the product
category of in-memory caches and we started to name it as an "in-memory
data grid" or "in-memory computing platform" to differentiate from
classical caching products such as Memcached and Redis.

Nowadays, the project outgrew its caching use case, and the classification
of Ignite as an "in-memory data grid" or "in-memory computing platform"
doesn't sound accurate. We rebuilt our storage engine by replacing a
typical key-value engine with a B-tree engine that spans across memory and
disk tiers. And it's not surprising to see more deployments of Ignite as a
database on its own. So, it feels like we need to reconsider Ignite
positioning again so that a) application developers can discover it easily
via search engines and b) the project can stand out from in-memory projects
with intersecting capabilities.

To the point, I'm suggesting to reposition Ignite in one of the following
ways:

   1. Ignite is a "distributed X database". We are indeed a distributed
   partitioned database where X can be "multi-tiered" or "memory-first" to
   emphasize that we are more than an in-memory database.
   2. Keep defining Ignite as "an in-memory computing platform" but name
   our storage engine uniquely as "IgniteDB" to highlight that the platform is
   powered by a "distributed multi-tiered/memory-first database".

What is your thinking?


(Also, regardless of a selected name, Ignite still will be used as a cache
and grid, and we're not going to stop appealing to those use cases. But
those are just use cases while Ignite has to figure out its new identity
... again).


-
Denis

[Valentin Kulichenko]

My vote is for the "distributed memory-first database". It clearly states
that Ignite is a database (which is true at this point), while still
emphasizing the in-memory computing power endorsed by the platform.

The "in-memory computing platform" is an ambiguous term and doesn't really
reflect what Ignite is, especially in its current state.

-Val

On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]> wrote:

> Igniters,
>
> Throughout the history of our project, we could see how the addition of
> certain features required us to reassess the project's name and category.
>
> Before Ignite joined the ASF, it supported only compute APIs resembling the
> MapReduce engine of Hadoop. Those days, it was fair to define Ignite as "a
> distributed in-memory computing engine". Next, at the time of the project
> donation, it already included key-value/SQL/transactional APIs, was used as
> a distributed cache, and significantly outgrew the "in-memory computing
> engine" use case. That's how the project transitioned to the product
> category of in-memory caches and we started to name it as an "in-memory
> data grid" or "in-memory computing platform" to differentiate from
> classical caching products such as Memcached and Redis.
>
> Nowadays, the project outgrew its caching use case, and the classification
> of Ignite as an "in-memory data grid" or "in-memory computing platform"
> doesn't sound accurate. We rebuilt our storage engine by replacing a
> typical key-value engine with a B-tree engine that spans across memory and
> disk tiers. And it's not surprising to see more deployments of Ignite as a
> database on its own. So, it feels like we need to reconsider Ignite
> positioning again so that a) application developers can discover it easily
> via search engines and b) the project can stand out from in-memory projects
> with intersecting capabilities.
>
> To the point, I'm suggesting to reposition Ignite in one of the following
> ways:
>
>    1. Ignite is a "distributed X database". We are indeed a distributed
>    partitioned database where X can be "multi-tiered" or "memory-first" to
>    emphasize that we are more than an in-memory database.
>    2. Keep defining Ignite as "an in-memory computing platform" but name
>    our storage engine uniquely as "IgniteDB" to highlight that the
> platform is
>    powered by a "distributed multi-tiered/memory-first database".
>
> What is your thinking?
>
>
> (Also, regardless of a selected name, Ignite still will be used as a cache
> and grid, and we're not going to stop appealing to those use cases. But
> those are just use cases while Ignite has to figure out its new identity
> ... again).
>
>
> -
> Denis
>

[Pavel Tupitsyn]

Agree with Val, even experienced developers have a hard time understanding
what "in-memory computing platform" really does.

"distributed memory-first database" is right on point.

On Thu, Sep 17, 2020 at 8:30 AM Valentin Kulichenko <
[hidden email]> wrote:

> My vote is for the "distributed memory-first database". It clearly states
> that Ignite is a database (which is true at this point), while still
> emphasizing the in-memory computing power endorsed by the platform.
>
> The "in-memory computing platform" is an ambiguous term and doesn't really
> reflect what Ignite is, especially in its current state.
>
> -Val
>
> On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]> wrote:
>
> > Igniters,
> >
> > Throughout the history of our project, we could see how the addition of
> > certain features required us to reassess the project's name and category.
> >
> > Before Ignite joined the ASF, it supported only compute APIs resembling
> the
> > MapReduce engine of Hadoop. Those days, it was fair to define Ignite as
> "a
> > distributed in-memory computing engine". Next, at the time of the project
> > donation, it already included key-value/SQL/transactional APIs, was used
> as
> > a distributed cache, and significantly outgrew the "in-memory computing
> > engine" use case. That's how the project transitioned to the product
> > category of in-memory caches and we started to name it as an "in-memory
> > data grid" or "in-memory computing platform" to differentiate from
> > classical caching products such as Memcached and Redis.
> >
> > Nowadays, the project outgrew its caching use case, and the
> classification
> > of Ignite as an "in-memory data grid" or "in-memory computing platform"
> > doesn't sound accurate. We rebuilt our storage engine by replacing a
> > typical key-value engine with a B-tree engine that spans across memory
> and
> > disk tiers. And it's not surprising to see more deployments of Ignite as
> a
> > database on its own. So, it feels like we need to reconsider Ignite
> > positioning again so that a) application developers can discover it
> easily
> > via search engines and b) the project can stand out from in-memory
> projects
> > with intersecting capabilities.
> >
> > To the point, I'm suggesting to reposition Ignite in one of the following
> > ways:
> >
> >    1. Ignite is a "distributed X database". We are indeed a distributed
> >    partitioned database where X can be "multi-tiered" or "memory-first"
> to
> >    emphasize that we are more than an in-memory database.
> >    2. Keep defining Ignite as "an in-memory computing platform" but name
> >    our storage engine uniquely as "IgniteDB" to highlight that the
> > platform is
> >    powered by a "distributed multi-tiered/memory-first database".
> >
> > What is your thinking?
> >
> >
> > (Also, regardless of a selected name, Ignite still will be used as a
> cache
> > and grid, and we're not going to stop appealing to those use cases. But
> > those are just use cases while Ignite has to figure out its new identity
> > ... again).
> >
> >
> > -
> > Denis
> >
>

[Roman Kondakov]

I would not say that Ignite is an in-memory database in a general sense
of this term. Ignite uses disk-oriented buffer pools (aka page memory)
under the hood, which makes similar to traditional distributed
databases. See abstract and intro in [1] for detailed explanation of the
differences between "in-memory" and "traditional" databases. The term
"in-memory database" may confuse our users that expect Ignite is a "true
in-memory database".

I would vote for "distributed database and computing engine" or
something like this.


[1] http://www.vldb.org/pvldb/vol8/p37-graefe.pdf

--
Roman Kondakov

On 17.09.2020 12:07, Pavel Tupitsyn wrote:

> Agree with Val, even experienced developers have a hard time understanding
> what "in-memory computing platform" really does.
>
> "distributed memory-first database" is right on point.
>
> On Thu, Sep 17, 2020 at 8:30 AM Valentin Kulichenko <
> [hidden email]> wrote:
>
>> My vote is for the "distributed memory-first database". It clearly states
>> that Ignite is a database (which is true at this point), while still
>> emphasizing the in-memory computing power endorsed by the platform.
>>
>> The "in-memory computing platform" is an ambiguous term and doesn't really
>> reflect what Ignite is, especially in its current state.
>>
>> -Val
>>
>> On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]> wrote:
>>
>>> Igniters,
>>>
>>> Throughout the history of our project, we could see how the addition of
>>> certain features required us to reassess the project's name and category.
>>>
>>> Before Ignite joined the ASF, it supported only compute APIs resembling
>> the
>>> MapReduce engine of Hadoop. Those days, it was fair to define Ignite as
>> "a
>>> distributed in-memory computing engine". Next, at the time of the project
>>> donation, it already included key-value/SQL/transactional APIs, was used
>> as
>>> a distributed cache, and significantly outgrew the "in-memory computing
>>> engine" use case. That's how the project transitioned to the product
>>> category of in-memory caches and we started to name it as an "in-memory
>>> data grid" or "in-memory computing platform" to differentiate from
>>> classical caching products such as Memcached and Redis.
>>>
>>> Nowadays, the project outgrew its caching use case, and the
>> classification
>>> of Ignite as an "in-memory data grid" or "in-memory computing platform"
>>> doesn't sound accurate. We rebuilt our storage engine by replacing a
>>> typical key-value engine with a B-tree engine that spans across memory
>> and
>>> disk tiers. And it's not surprising to see more deployments of Ignite as
>> a
>>> database on its own. So, it feels like we need to reconsider Ignite
>>> positioning again so that a) application developers can discover it
>> easily
>>> via search engines and b) the project can stand out from in-memory
>> projects
>>> with intersecting capabilities.
>>>
>>> To the point, I'm suggesting to reposition Ignite in one of the following
>>> ways:
>>>
>>>     1. Ignite is a "distributed X database". We are indeed a distributed
>>>     partitioned database where X can be "multi-tiered" or "memory-first"
>> to
>>>     emphasize that we are more than an in-memory database.
>>>     2. Keep defining Ignite as "an in-memory computing platform" but name
>>>     our storage engine uniquely as "IgniteDB" to highlight that the
>>> platform is
>>>     powered by a "distributed multi-tiered/memory-first database".
>>>
>>> What is your thinking?
>>>
>>>
>>> (Also, regardless of a selected name, Ignite still will be used as a
>> cache
>>> and grid, and we're not going to stop appealing to those use cases. But
>>> those are just use cases while Ignite has to figure out its new identity
>>> ... again).
>>>
>>>
>>> -
>>> Denis
>>>
>>
>

[sdarlington]

I think this is a great question. Explaining what Ignite does is always a challenge, so having a useful “tag line” would be very valuable.

I’m not sure what the answer is but I think calling it a “database” devalues all the compute facilities. "Computing platform” may be too vague but it at least says that we do more than “just” store data.

> On 17 Sep 2020, at 06:29, Valentin Kulichenko <[hidden email]> wrote:
>
> My vote is for the "distributed memory-first database". It clearly states that Ignite is a database (which is true at this point), while still emphasizing the in-memory computing power endorsed by the platform.
>
> The "in-memory computing platform" is an ambiguous term and doesn't really reflect what Ignite is, especially in its current state.
>
> -Val
>
> On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email] <mailto:[hidden email]>> wrote:
> Igniters,
>
> Throughout the history of our project, we could see how the addition of
> certain features required us to reassess the project's name and category.
>
> Before Ignite joined the ASF, it supported only compute APIs resembling the
> MapReduce engine of Hadoop. Those days, it was fair to define Ignite as "a
> distributed in-memory computing engine". Next, at the time of the project
> donation, it already included key-value/SQL/transactional APIs, was used as
> a distributed cache, and significantly outgrew the "in-memory computing
> engine" use case. That's how the project transitioned to the product
> category of in-memory caches and we started to name it as an "in-memory
> data grid" or "in-memory computing platform" to differentiate from
> classical caching products such as Memcached and Redis.
>
> Nowadays, the project outgrew its caching use case, and the classification
> of Ignite as an "in-memory data grid" or "in-memory computing platform"
> doesn't sound accurate. We rebuilt our storage engine by replacing a
> typical key-value engine with a B-tree engine that spans across memory and
> disk tiers. And it's not surprising to see more deployments of Ignite as a
> database on its own. So, it feels like we need to reconsider Ignite
> positioning again so that a) application developers can discover it easily
> via search engines and b) the project can stand out from in-memory projects
> with intersecting capabilities.
>
> To the point, I'm suggesting to reposition Ignite in one of the following
> ways:
>
>    1. Ignite is a "distributed X database". We are indeed a distributed
>    partitioned database where X can be "multi-tiered" or "memory-first" to
>    emphasize that we are more than an in-memory database.
>    2. Keep defining Ignite as "an in-memory computing platform" but name
>    our storage engine uniquely as "IgniteDB" to highlight that the platform is
>    powered by a "distributed multi-tiered/memory-first database".
>
> What is your thinking?
>
>
> (Also, regardless of a selected name, Ignite still will be used as a cache
> and grid, and we're not going to stop appealing to those use cases. But
> those are just use cases while Ignite has to figure out its new identity
> ... again).
>
>
> -
> Denis

[Glenn Wiebe-2]

I agree with Stephen about "database" devaluing what Ignite can do (though
it probably hits the majority of existing use cases). I tend to go with
"massively distributed storage and compute platform"

I know, I didn't take sides, I just have both.

Cheers,
  Glenn

On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
[hidden email]> wrote:

> I think this is a great question. Explaining what Ignite does is always a
> challenge, so having a useful “tag line” would be very valuable.
>
> I’m not sure what the answer is but I think calling it a “database”
> devalues all the compute facilities. "Computing platform” may be too vague
> but it at least says that we do more than “just” store data.
>
> On 17 Sep 2020, at 06:29, Valentin Kulichenko <
> [hidden email]> wrote:
>
> My vote is for the "distributed memory-first database". It clearly states
> that Ignite is a database (which is true at this point), while still
> emphasizing the in-memory computing power endorsed by the platform.
>
> The "in-memory computing platform" is an ambiguous term and doesn't really
> reflect what Ignite is, especially in its current state.
>
> -Val
>
> On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]> wrote:
>
>> Igniters,
>>
>> Throughout the history of our project, we could see how the addition of
>> certain features required us to reassess the project's name and category.
>>
>> Before Ignite joined the ASF, it supported only compute APIs resembling
>> the
>> MapReduce engine of Hadoop. Those days, it was fair to define Ignite as "a
>> distributed in-memory computing engine". Next, at the time of the project
>> donation, it already included key-value/SQL/transactional APIs, was used
>> as
>> a distributed cache, and significantly outgrew the "in-memory computing
>> engine" use case. That's how the project transitioned to the product
>> category of in-memory caches and we started to name it as an "in-memory
>> data grid" or "in-memory computing platform" to differentiate from
>> classical caching products such as Memcached and Redis.
>>
>> Nowadays, the project outgrew its caching use case, and the classification
>> of Ignite as an "in-memory data grid" or "in-memory computing platform"
>> doesn't sound accurate. We rebuilt our storage engine by replacing a
>> typical key-value engine with a B-tree engine that spans across memory and
>> disk tiers. And it's not surprising to see more deployments of Ignite as a
>> database on its own. So, it feels like we need to reconsider Ignite
>> positioning again so that a) application developers can discover it easily
>> via search engines and b) the project can stand out from in-memory
>> projects
>> with intersecting capabilities.
>>
>> To the point, I'm suggesting to reposition Ignite in one of the following
>> ways:
>>
>>    1. Ignite is a "distributed X database". We are indeed a distributed
>>    partitioned database where X can be "multi-tiered" or "memory-first" to
>>    emphasize that we are more than an in-memory database.
>>    2. Keep defining Ignite as "an in-memory computing platform" but name
>>    our storage engine uniquely as "IgniteDB" to highlight that the
>> platform is
>>    powered by a "distributed multi-tiered/memory-first database".
>>
>> What is your thinking?
>>
>>
>> (Also, regardless of a selected name, Ignite still will be used as a cache
>> and grid, and we're not going to stop appealing to those use cases. But
>> those are just use cases while Ignite has to figure out its new identity
>> ... again).
>>
>>
>> -
>> Denis
>>
>
>
>

[Ilya Kasnacheev]

Hello!

Can you please clarify which databases you refer to when you say
"traditional distributed databases"?

I didn't consider it to be a mature enough field to have tradition.

Regards,
--
Ilya Kasnacheev


чт, 17 сент. 2020 г. в 13:44, Roman Kondakov <[hidden email]>:

> I would not say that Ignite is an in-memory database in a general sense
> of this term. Ignite uses disk-oriented buffer pools (aka page memory)
> under the hood, which makes similar to traditional distributed
> databases. See abstract and intro in [1] for detailed explanation of the
> differences between "in-memory" and "traditional" databases. The term
> "in-memory database" may confuse our users that expect Ignite is a "true
> in-memory database".
>
> I would vote for "distributed database and computing engine" or
> something like this.
>
>
> [1] http://www.vldb.org/pvldb/vol8/p37-graefe.pdf
>
> --
> Roman Kondakov
>
> On 17.09.2020 12:07, Pavel Tupitsyn wrote:
> > Agree with Val, even experienced developers have a hard time
> understanding
> > what "in-memory computing platform" really does.
> >
> > "distributed memory-first database" is right on point.
> >
> > On Thu, Sep 17, 2020 at 8:30 AM Valentin Kulichenko <
> > [hidden email]> wrote:
> >
> >> My vote is for the "distributed memory-first database". It clearly
> states
> >> that Ignite is a database (which is true at this point), while still
> >> emphasizing the in-memory computing power endorsed by the platform.
> >>
> >> The "in-memory computing platform" is an ambiguous term and doesn't
> really
> >> reflect what Ignite is, especially in its current state.
> >>
> >> -Val
> >>
> >> On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]> wrote:
> >>
> >>> Igniters,
> >>>
> >>> Throughout the history of our project, we could see how the addition of
> >>> certain features required us to reassess the project's name and
> category.
> >>>
> >>> Before Ignite joined the ASF, it supported only compute APIs resembling
> >> the
> >>> MapReduce engine of Hadoop. Those days, it was fair to define Ignite as
> >> "a
> >>> distributed in-memory computing engine". Next, at the time of the
> project
> >>> donation, it already included key-value/SQL/transactional APIs, was
> used
> >> as
> >>> a distributed cache, and significantly outgrew the "in-memory computing
> >>> engine" use case. That's how the project transitioned to the product
> >>> category of in-memory caches and we started to name it as an "in-memory
> >>> data grid" or "in-memory computing platform" to differentiate from
> >>> classical caching products such as Memcached and Redis.
> >>>
> >>> Nowadays, the project outgrew its caching use case, and the
> >> classification
> >>> of Ignite as an "in-memory data grid" or "in-memory computing platform"
> >>> doesn't sound accurate. We rebuilt our storage engine by replacing a
> >>> typical key-value engine with a B-tree engine that spans across memory
> >> and
> >>> disk tiers. And it's not surprising to see more deployments of Ignite
> as
> >> a
> >>> database on its own. So, it feels like we need to reconsider Ignite
> >>> positioning again so that a) application developers can discover it
> >> easily
> >>> via search engines and b) the project can stand out from in-memory
> >> projects
> >>> with intersecting capabilities.
> >>>
> >>> To the point, I'm suggesting to reposition Ignite in one of the
> following
> >>> ways:
> >>>
> >>>     1. Ignite is a "distributed X database". We are indeed a
> distributed
> >>>     partitioned database where X can be "multi-tiered" or
> "memory-first"
> >> to
> >>>     emphasize that we are more than an in-memory database.
> >>>     2. Keep defining Ignite as "an in-memory computing platform" but
> name
> >>>     our storage engine uniquely as "IgniteDB" to highlight that the
> >>> platform is
> >>>     powered by a "distributed multi-tiered/memory-first database".
> >>>
> >>> What is your thinking?
> >>>
> >>>
> >>> (Also, regardless of a selected name, Ignite still will be used as a
> >> cache
> >>> and grid, and we're not going to stop appealing to those use cases. But
> >>> those are just use cases while Ignite has to figure out its new
> identity
> >>> ... again).
> >>>
> >>>
> >>> -
> >>> Denis
> >>>
> >>
> >
>

[Roman Kondakov]

Hello!

The word "traditional" here is not about the technology age. It's about
using buffer pool like in traditional databases (PG, Oracle, etc).

--
Roman Kondakov

On 17.09.2020 17:09, Ilya Kasnacheev wrote:
> Hello!
>
> Can you please clarify which databases you refer to when you say
> "traditional distributed databases"?
>
> I didn't consider it to be a mature enough field to have tradition.
>
> Regards,
>

[Carbone, Adam]

So when I came across Ignite It was described as an In Memory Data Grid

So one way to look at this is who do you fashion as Ignite competing against?

Are competing against Redis, Aerospike - In Memory Databases

Or are you more competing with

Gigaspaces - True In memory Compute platform

And then you have like of

Hazelcast that started as a Distributed Hash and have gained some features...

On thing that I think is a differentiator that isn't being highlighted but Is  unique feature to Ignited, and the primary reason we ended up here; The integration with spark and it's distributed/shared Datasets/Dataframes.

I don't know for me the In Memory Data Grid I think fits what Ignite is...

Regards

~Adam

Adam Carbone | Director of Innovation – Intelligent Platform Team | Bottomline Technologies
Office: 603-501-6446 | Mobile: [phone]
www.bottomline.com
 
 

On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]> wrote:

    I agree with Stephen about "database" devaluing what Ignite can do (though
    it probably hits the majority of existing use cases). I tend to go with
    "massively distributed storage and compute platform"

    I know, I didn't take sides, I just have both.

    Cheers,
      Glenn

    On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
    [hidden email]> wrote:

    > I think this is a great question. Explaining what Ignite does is always a
    > challenge, so having a useful “tag line” would be very valuable.
    >
    > I’m not sure what the answer is but I think calling it a “database”
    > devalues all the compute facilities. "Computing platform” may be too vague
    > but it at least says that we do more than “just” store data.
    >
    > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
    > [hidden email]> wrote:
    >
    > My vote is for the "distributed memory-first database". It clearly states
    > that Ignite is a database (which is true at this point), while still
    > emphasizing the in-memory computing power endorsed by the platform.
    >
    > The "in-memory computing platform" is an ambiguous term and doesn't really
    > reflect what Ignite is, especially in its current state.
    >
    > -Val
    >
    > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]> wrote:
    >
    >> Igniters,
    >>
    >> Throughout the history of our project, we could see how the addition of
    >> certain features required us to reassess the project's name and category.
    >>
    >> Before Ignite joined the ASF, it supported only compute APIs resembling
    >> the
    >> MapReduce engine of Hadoop. Those days, it was fair to define Ignite as "a
    >> distributed in-memory computing engine". Next, at the time of the project
    >> donation, it already included key-value/SQL/transactional APIs, was used
    >> as
    >> a distributed cache, and significantly outgrew the "in-memory computing
    >> engine" use case. That's how the project transitioned to the product
    >> category of in-memory caches and we started to name it as an "in-memory
    >> data grid" or "in-memory computing platform" to differentiate from
    >> classical caching products such as Memcached and Redis.
    >>
    >> Nowadays, the project outgrew its caching use case, and the classification
    >> of Ignite as an "in-memory data grid" or "in-memory computing platform"
    >> doesn't sound accurate. We rebuilt our storage engine by replacing a
    >> typical key-value engine with a B-tree engine that spans across memory and
    >> disk tiers. And it's not surprising to see more deployments of Ignite as a
    >> database on its own. So, it feels like we need to reconsider Ignite
    >> positioning again so that a) application developers can discover it easily
    >> via search engines and b) the project can stand out from in-memory
    >> projects
    >> with intersecting capabilities.
    >>
    >> To the point, I'm suggesting to reposition Ignite in one of the following
    >> ways:
    >>
    >>    1. Ignite is a "distributed X database". We are indeed a distributed
    >>    partitioned database where X can be "multi-tiered" or "memory-first" to
    >>    emphasize that we are more than an in-memory database.
    >>    2. Keep defining Ignite as "an in-memory computing platform" but name
    >>    our storage engine uniquely as "IgniteDB" to highlight that the
    >> platform is
    >>    powered by a "distributed multi-tiered/memory-first database".
    >>
    >> What is your thinking?
    >>
    >>
    >> (Also, regardless of a selected name, Ignite still will be used as a cache
    >> and grid, and we're not going to stop appealing to those use cases. But
    >> those are just use cases while Ignite has to figure out its new identity
    >> ... again).
    >>
    >>
    >> -
    >> Denis
    >>
    >
    >
    >

[Saikat Maitra]

Hi,

My thoughts are similar to as Denis and Val mentioned like Apache Ignite -
"A Memory Centric Database".

It aligns to current features of Apache Ignite as mentioned in the below
post.

https://thenewstack.io/memory-centric-architectures-whats-next-for-in-memory-computing

Regards,
Saikat

On Fri, Sep 18, 2020 at 9:02 AM Carbone, Adam <[hidden email]>
wrote:

> So when I came across Ignite It was described as an In Memory Data Grid
>
> So one way to look at this is who do you fashion as Ignite competing
> against?
>
> Are competing against Redis, Aerospike - In Memory Databases
>
> Or are you more competing with
>
> Gigaspaces - True In memory Compute platform
>
> And then you have like of
>
> Hazelcast that started as a Distributed Hash and have gained some
> features...
>
> On thing that I think is a differentiator that isn't being highlighted but
> Is  unique feature to Ignited, and the primary reason we ended up here; The
> integration with spark and it's distributed/shared Datasets/Dataframes.
>
> I don't know for me the In Memory Data Grid I think fits what Ignite is...
>
> Regards
>
> ~Adam
>
> Adam Carbone | Director of Innovation – Intelligent Platform Team |
> Bottomline Technologies
> Office: 603-501-6446 | Mobile: [phone]
> www.bottomline.com
>
>
>
> On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]> wrote:
>
>     I agree with Stephen about "database" devaluing what Ignite can do
> (though
>     it probably hits the majority of existing use cases). I tend to go with
>     "massively distributed storage and compute platform"
>
>     I know, I didn't take sides, I just have both.
>
>     Cheers,
>       Glenn
>
>     On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
>     [hidden email]> wrote:
>
>     > I think this is a great question. Explaining what Ignite does is
> always a
>     > challenge, so having a useful “tag line” would be very valuable.
>     >
>     > I’m not sure what the answer is but I think calling it a “database”
>     > devalues all the compute facilities. "Computing platform” may be too
> vague
>     > but it at least says that we do more than “just” store data.
>     >
>     > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
>     > [hidden email]> wrote:
>     >
>     > My vote is for the "distributed memory-first database". It clearly
> states
>     > that Ignite is a database (which is true at this point), while still
>     > emphasizing the in-memory computing power endorsed by the platform.
>     >
>     > The "in-memory computing platform" is an ambiguous term and doesn't
> really
>     > reflect what Ignite is, especially in its current state.
>     >
>     > -Val
>     >
>     > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]>
> wrote:
>     >
>     >> Igniters,
>     >>
>     >> Throughout the history of our project, we could see how the
> addition of
>     >> certain features required us to reassess the project's name and
> category.
>     >>
>     >> Before Ignite joined the ASF, it supported only compute APIs
> resembling
>     >> the
>     >> MapReduce engine of Hadoop. Those days, it was fair to define
> Ignite as "a
>     >> distributed in-memory computing engine". Next, at the time of the
> project
>     >> donation, it already included key-value/SQL/transactional APIs, was
> used
>     >> as
>     >> a distributed cache, and significantly outgrew the "in-memory
> computing
>     >> engine" use case. That's how the project transitioned to the product
>     >> category of in-memory caches and we started to name it as an
> "in-memory
>     >> data grid" or "in-memory computing platform" to differentiate from
>     >> classical caching products such as Memcached and Redis.
>     >>
>     >> Nowadays, the project outgrew its caching use case, and the
> classification
>     >> of Ignite as an "in-memory data grid" or "in-memory computing
> platform"
>     >> doesn't sound accurate. We rebuilt our storage engine by replacing a
>     >> typical key-value engine with a B-tree engine that spans across
> memory and
>     >> disk tiers. And it's not surprising to see more deployments of
> Ignite as a
>     >> database on its own. So, it feels like we need to reconsider Ignite
>     >> positioning again so that a) application developers can discover it
> easily
>     >> via search engines and b) the project can stand out from in-memory
>     >> projects
>     >> with intersecting capabilities.
>     >>
>     >> To the point, I'm suggesting to reposition Ignite in one of the
> following
>     >> ways:
>     >>
>     >>    1. Ignite is a "distributed X database". We are indeed a
> distributed
>     >>    partitioned database where X can be "multi-tiered" or
> "memory-first" to
>     >>    emphasize that we are more than an in-memory database.
>     >>    2. Keep defining Ignite as "an in-memory computing platform" but
> name
>     >>    our storage engine uniquely as "IgniteDB" to highlight that the
>     >> platform is
>     >>    powered by a "distributed multi-tiered/memory-first database".
>     >>
>     >> What is your thinking?
>     >>
>     >>
>     >> (Also, regardless of a selected name, Ignite still will be used as
> a cache
>     >> and grid, and we're not going to stop appealing to those use cases.
> But
>     >> those are just use cases while Ignite has to figure out its new
> identity
>     >> ... again).
>     >>
>     >>
>     >> -
>     >> Denis
>     >>
>     >
>     >
>     >
>
>

[nivanov]

My vote is to just call ignite "IgniteDB". That's it. No other additional
explanation is required as no amount of additional verbiage will help.
Every DB is different: from MongoDB, to RedisDB, to CockroachDB, to Oracle
- they all look & act completely different, and they don't go around trying
to explain in one line what they do and how they are different.

"IgniteDB" is clear, concise and gives us the broadest initial acceptance
from the new user perspective.

Thanks,
--
Nikita Ivanov



On Sat, Sep 19, 2020 at 1:10 PM Saikat Maitra <[hidden email]>
wrote:

> Hi,
>
> My thoughts are similar to as Denis and Val mentioned like Apache Ignite -
> "A Memory Centric Database".
>
> It aligns to current features of Apache Ignite as mentioned in the below
> post.
>
>
> https://thenewstack.io/memory-centric-architectures-whats-next-for-in-memory-computing
>
> Regards,
> Saikat
>
> On Fri, Sep 18, 2020 at 9:02 AM Carbone, Adam <[hidden email]>
> wrote:
>
>> So when I came across Ignite It was described as an In Memory Data Grid
>>
>> So one way to look at this is who do you fashion as Ignite competing
>> against?
>>
>> Are competing against Redis, Aerospike - In Memory Databases
>>
>> Or are you more competing with
>>
>> Gigaspaces - True In memory Compute platform
>>
>> And then you have like of
>>
>> Hazelcast that started as a Distributed Hash and have gained some
>> features...
>>
>> On thing that I think is a differentiator that isn't being highlighted
>> but Is  unique feature to Ignited, and the primary reason we ended up here;
>> The integration with spark and it's distributed/shared Datasets/Dataframes.
>>
>> I don't know for me the In Memory Data Grid I think fits what Ignite
>> is...
>>
>> Regards
>>
>> ~Adam
>>
>> Adam Carbone | Director of Innovation – Intelligent Platform Team |
>> Bottomline Technologies
>> Office: 603-501-6446 | Mobile: [phone]
>> www.bottomline.com
>>
>>
>>
>> On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]> wrote:
>>
>>     I agree with Stephen about "database" devaluing what Ignite can do
>> (though
>>     it probably hits the majority of existing use cases). I tend to go
>> with
>>     "massively distributed storage and compute platform"
>>
>>     I know, I didn't take sides, I just have both.
>>
>>     Cheers,
>>       Glenn
>>
>>     On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
>>     [hidden email]> wrote:
>>
>>     > I think this is a great question. Explaining what Ignite does is
>> always a
>>     > challenge, so having a useful “tag line” would be very valuable.
>>     >
>>     > I’m not sure what the answer is but I think calling it a “database”
>>     > devalues all the compute facilities. "Computing platform” may be
>> too vague
>>     > but it at least says that we do more than “just” store data.
>>     >
>>     > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
>>     > [hidden email]> wrote:
>>     >
>>     > My vote is for the "distributed memory-first database". It clearly
>> states
>>     > that Ignite is a database (which is true at this point), while still
>>     > emphasizing the in-memory computing power endorsed by the platform.
>>     >
>>     > The "in-memory computing platform" is an ambiguous term and doesn't
>> really
>>     > reflect what Ignite is, especially in its current state.
>>     >
>>     > -Val
>>     >
>>     > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]>
>> wrote:
>>     >
>>     >> Igniters,
>>     >>
>>     >> Throughout the history of our project, we could see how the
>> addition of
>>     >> certain features required us to reassess the project's name and
>> category.
>>     >>
>>     >> Before Ignite joined the ASF, it supported only compute APIs
>> resembling
>>     >> the
>>     >> MapReduce engine of Hadoop. Those days, it was fair to define
>> Ignite as "a
>>     >> distributed in-memory computing engine". Next, at the time of the
>> project
>>     >> donation, it already included key-value/SQL/transactional APIs,
>> was used
>>     >> as
>>     >> a distributed cache, and significantly outgrew the "in-memory
>> computing
>>     >> engine" use case. That's how the project transitioned to the
>> product
>>     >> category of in-memory caches and we started to name it as an
>> "in-memory
>>     >> data grid" or "in-memory computing platform" to differentiate from
>>     >> classical caching products such as Memcached and Redis.
>>     >>
>>     >> Nowadays, the project outgrew its caching use case, and the
>> classification
>>     >> of Ignite as an "in-memory data grid" or "in-memory computing
>> platform"
>>     >> doesn't sound accurate. We rebuilt our storage engine by replacing
>> a
>>     >> typical key-value engine with a B-tree engine that spans across
>> memory and
>>     >> disk tiers. And it's not surprising to see more deployments of
>> Ignite as a
>>     >> database on its own. So, it feels like we need to reconsider Ignite
>>     >> positioning again so that a) application developers can discover
>> it easily
>>     >> via search engines and b) the project can stand out from in-memory
>>     >> projects
>>     >> with intersecting capabilities.
>>     >>
>>     >> To the point, I'm suggesting to reposition Ignite in one of the
>> following
>>     >> ways:
>>     >>
>>     >>    1. Ignite is a "distributed X database". We are indeed a
>> distributed
>>     >>    partitioned database where X can be "multi-tiered" or
>> "memory-first" to
>>     >>    emphasize that we are more than an in-memory database.
>>     >>    2. Keep defining Ignite as "an in-memory computing platform"
>> but name
>>     >>    our storage engine uniquely as "IgniteDB" to highlight that the
>>     >> platform is
>>     >>    powered by a "distributed multi-tiered/memory-first database".
>>     >>
>>     >> What is your thinking?
>>     >>
>>     >>
>>     >> (Also, regardless of a selected name, Ignite still will be used as
>> a cache
>>     >> and grid, and we're not going to stop appealing to those use
>> cases. But
>>     >> those are just use cases while Ignite has to figure out its new
>> identity
>>     >> ... again).
>>     >>
>>     >>
>>     >> -
>>     >> Denis
>>     >>
>>     >
>>     >
>>     >
>>
>>

[Konstantin Boudnik-2]

+1

With regards,
   Cos

On 2020-09-21 20:35, Nikita Ivanov wrote:

> My vote is to just call ignite "IgniteDB". That's it. No other additional
> explanation is required as no amount of additional verbiage will help.
> Every DB is different: from MongoDB, to RedisDB, to CockroachDB, to Oracle
> - they all look & act completely different, and they don't go around trying
> to explain in one line what they do and how they are different.
>
> "IgniteDB" is clear, concise and gives us the broadest initial acceptance
> from the new user perspective.
>
> Thanks,
> --
> Nikita Ivanov
>
>
>
> On Sat, Sep 19, 2020 at 1:10 PM Saikat Maitra <[hidden email]>
> wrote:
>
>> Hi,
>>
>> My thoughts are similar to as Denis and Val mentioned like Apache Ignite -
>> "A Memory Centric Database".
>>
>> It aligns to current features of Apache Ignite as mentioned in the below
>> post.
>>
>>
>> https://thenewstack.io/memory-centric-architectures-whats-next-for-in-memory-computing
>>
>> Regards,
>> Saikat
>>
>> On Fri, Sep 18, 2020 at 9:02 AM Carbone, Adam <[hidden email]>
>> wrote:
>>
>>> So when I came across Ignite It was described as an In Memory Data Grid
>>>
>>> So one way to look at this is who do you fashion as Ignite competing
>>> against?
>>>
>>> Are competing against Redis, Aerospike - In Memory Databases
>>>
>>> Or are you more competing with
>>>
>>> Gigaspaces - True In memory Compute platform
>>>
>>> And then you have like of
>>>
>>> Hazelcast that started as a Distributed Hash and have gained some
>>> features...
>>>
>>> On thing that I think is a differentiator that isn't being highlighted
>>> but Is  unique feature to Ignited, and the primary reason we ended up here;
>>> The integration with spark and it's distributed/shared Datasets/Dataframes.
>>>
>>> I don't know for me the In Memory Data Grid I think fits what Ignite
>>> is...
>>>
>>> Regards
>>>
>>> ~Adam
>>>
>>> Adam Carbone | Director of Innovation – Intelligent Platform Team |
>>> Bottomline Technologies
>>> Office: 603-501-6446 | Mobile: [phone]
>>> www.bottomline.com
>>>
>>>
>>>
>>> On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]> wrote:
>>>
>>>      I agree with Stephen about "database" devaluing what Ignite can do
>>> (though
>>>      it probably hits the majority of existing use cases). I tend to go
>>> with
>>>      "massively distributed storage and compute platform"
>>>
>>>      I know, I didn't take sides, I just have both.
>>>
>>>      Cheers,
>>>        Glenn
>>>
>>>      On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
>>>      [hidden email]> wrote:
>>>
>>>      > I think this is a great question. Explaining what Ignite does is
>>> always a
>>>      > challenge, so having a useful “tag line” would be very valuable.
>>>      >
>>>      > I’m not sure what the answer is but I think calling it a “database”
>>>      > devalues all the compute facilities. "Computing platform” may be
>>> too vague
>>>      > but it at least says that we do more than “just” store data.
>>>      >
>>>      > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
>>>      > [hidden email]> wrote:
>>>      >
>>>      > My vote is for the "distributed memory-first database". It clearly
>>> states
>>>      > that Ignite is a database (which is true at this point), while still
>>>      > emphasizing the in-memory computing power endorsed by the platform.
>>>      >
>>>      > The "in-memory computing platform" is an ambiguous term and doesn't
>>> really
>>>      > reflect what Ignite is, especially in its current state.
>>>      >
>>>      > -Val
>>>      >
>>>      > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]>
>>> wrote:
>>>      >
>>>      >> Igniters,
>>>      >>
>>>      >> Throughout the history of our project, we could see how the
>>> addition of
>>>      >> certain features required us to reassess the project's name and
>>> category.
>>>      >>
>>>      >> Before Ignite joined the ASF, it supported only compute APIs
>>> resembling
>>>      >> the
>>>      >> MapReduce engine of Hadoop. Those days, it was fair to define
>>> Ignite as "a
>>>      >> distributed in-memory computing engine". Next, at the time of the
>>> project
>>>      >> donation, it already included key-value/SQL/transactional APIs,
>>> was used
>>>      >> as
>>>      >> a distributed cache, and significantly outgrew the "in-memory
>>> computing
>>>      >> engine" use case. That's how the project transitioned to the
>>> product
>>>      >> category of in-memory caches and we started to name it as an
>>> "in-memory
>>>      >> data grid" or "in-memory computing platform" to differentiate from
>>>      >> classical caching products such as Memcached and Redis.
>>>      >>
>>>      >> Nowadays, the project outgrew its caching use case, and the
>>> classification
>>>      >> of Ignite as an "in-memory data grid" or "in-memory computing
>>> platform"
>>>      >> doesn't sound accurate. We rebuilt our storage engine by replacing
>>> a
>>>      >> typical key-value engine with a B-tree engine that spans across
>>> memory and
>>>      >> disk tiers. And it's not surprising to see more deployments of
>>> Ignite as a
>>>      >> database on its own. So, it feels like we need to reconsider Ignite
>>>      >> positioning again so that a) application developers can discover
>>> it easily
>>>      >> via search engines and b) the project can stand out from in-memory
>>>      >> projects
>>>      >> with intersecting capabilities.
>>>      >>
>>>      >> To the point, I'm suggesting to reposition Ignite in one of the
>>> following
>>>      >> ways:
>>>      >>
>>>      >>    1. Ignite is a "distributed X database". We are indeed a
>>> distributed
>>>      >>    partitioned database where X can be "multi-tiered" or
>>> "memory-first" to
>>>      >>    emphasize that we are more than an in-memory database.
>>>      >>    2. Keep defining Ignite as "an in-memory computing platform"
>>> but name
>>>      >>    our storage engine uniquely as "IgniteDB" to highlight that the
>>>      >> platform is
>>>      >>    powered by a "distributed multi-tiered/memory-first database".
>>>      >>
>>>      >> What is your thinking?
>>>      >>
>>>      >>
>>>      >> (Also, regardless of a selected name, Ignite still will be used as
>>> a cache
>>>      >> and grid, and we're not going to stop appealing to those use
>>> cases. But
>>>      >> those are just use cases while Ignite has to figure out its new
>>> identity
>>>      >> ... again).
>>>      >>
>>>      >>
>>>      >> -
>>>      >> Denis
>>>      >>
>>>      >
>>>      >
>>>      >
>>>
>>>
>

[dmagda]

Adam,

You defined GigaSpaces as a true in-memory computing platform. What is the
true platform for you?


-
Denis


On Fri, Sep 18, 2020 at 7:02 AM Carbone, Adam <[hidden email]>
wrote:

> So when I came across Ignite It was described as an In Memory Data Grid
>
> So one way to look at this is who do you fashion as Ignite competing
> against?
>
> Are competing against Redis, Aerospike - In Memory Databases
>
> Or are you more competing with
>
> Gigaspaces - True In memory Compute platform
>
> And then you have like of
>
> Hazelcast that started as a Distributed Hash and have gained some
> features...
>
> On thing that I think is a differentiator that isn't being highlighted but
> Is  unique feature to Ignited, and the primary reason we ended up here; The
> integration with spark and it's distributed/shared Datasets/Dataframes.
>
> I don't know for me the In Memory Data Grid I think fits what Ignite is...
>
> Regards
>
> ~Adam
>
> Adam Carbone | Director of Innovation – Intelligent Platform Team |
> Bottomline Technologies
> Office: 603-501-6446 | Mobile: [phone]
> www.bottomline.com
>
>
>
> On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]> wrote:
>
>     I agree with Stephen about "database" devaluing what Ignite can do
> (though
>     it probably hits the majority of existing use cases). I tend to go with
>     "massively distributed storage and compute platform"
>
>     I know, I didn't take sides, I just have both.
>
>     Cheers,
>       Glenn
>
>     On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
>     [hidden email]> wrote:
>
>     > I think this is a great question. Explaining what Ignite does is
> always a
>     > challenge, so having a useful “tag line” would be very valuable.
>     >
>     > I’m not sure what the answer is but I think calling it a “database”
>     > devalues all the compute facilities. "Computing platform” may be too
> vague
>     > but it at least says that we do more than “just” store data.
>     >
>     > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
>     > [hidden email]> wrote:
>     >
>     > My vote is for the "distributed memory-first database". It clearly
> states
>     > that Ignite is a database (which is true at this point), while still
>     > emphasizing the in-memory computing power endorsed by the platform.
>     >
>     > The "in-memory computing platform" is an ambiguous term and doesn't
> really
>     > reflect what Ignite is, especially in its current state.
>     >
>     > -Val
>     >
>     > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]>
> wrote:
>     >
>     >> Igniters,
>     >>
>     >> Throughout the history of our project, we could see how the
> addition of
>     >> certain features required us to reassess the project's name and
> category.
>     >>
>     >> Before Ignite joined the ASF, it supported only compute APIs
> resembling
>     >> the
>     >> MapReduce engine of Hadoop. Those days, it was fair to define
> Ignite as "a
>     >> distributed in-memory computing engine". Next, at the time of the
> project
>     >> donation, it already included key-value/SQL/transactional APIs, was
> used
>     >> as
>     >> a distributed cache, and significantly outgrew the "in-memory
> computing
>     >> engine" use case. That's how the project transitioned to the product
>     >> category of in-memory caches and we started to name it as an
> "in-memory
>     >> data grid" or "in-memory computing platform" to differentiate from
>     >> classical caching products such as Memcached and Redis.
>     >>
>     >> Nowadays, the project outgrew its caching use case, and the
> classification
>     >> of Ignite as an "in-memory data grid" or "in-memory computing
> platform"
>     >> doesn't sound accurate. We rebuilt our storage engine by replacing a
>     >> typical key-value engine with a B-tree engine that spans across
> memory and
>     >> disk tiers. And it's not surprising to see more deployments of
> Ignite as a
>     >> database on its own. So, it feels like we need to reconsider Ignite
>     >> positioning again so that a) application developers can discover it
> easily
>     >> via search engines and b) the project can stand out from in-memory
>     >> projects
>     >> with intersecting capabilities.
>     >>
>     >> To the point, I'm suggesting to reposition Ignite in one of the
> following
>     >> ways:
>     >>
>     >>    1. Ignite is a "distributed X database". We are indeed a
> distributed
>     >>    partitioned database where X can be "multi-tiered" or
> "memory-first" to
>     >>    emphasize that we are more than an in-memory database.
>     >>    2. Keep defining Ignite as "an in-memory computing platform" but
> name
>     >>    our storage engine uniquely as "IgniteDB" to highlight that the
>     >> platform is
>     >>    powered by a "distributed multi-tiered/memory-first database".
>     >>
>     >> What is your thinking?
>     >>
>     >>
>     >> (Also, regardless of a selected name, Ignite still will be used as
> a cache
>     >> and grid, and we're not going to stop appealing to those use cases.
> But
>     >> those are just use cases while Ignite has to figure out its new
> identity
>     >> ... again).
>     >>
>     >>
>     >> -
>     >> Denis
>     >>
>     >
>     >
>     >
>
>

[Carbone, Adam]

Good Evening Denis,

I’m sure there are more out there as well,  I would consider platforms that the entire applications but that all the execution of code happens exclusively on the platform, and most of the applications are written to run in, not connected to the platform.

Hmmm by this criteria k8s could possible fit the bill…

Spark might even be considered a compute grid as well but it is not a generic compute framework and people don’t usually run there whole applications inside.

What is the vision for the platform? That might help in this discussion, set your category with the direction you are heading, and what you are trying to achieve.

Regards

Adam Carbone | Director of Innovation – Intelligent Platform Team | Bottomline Technologies
Office: 603-501-6446 | Mobile: [phone]
www.bottomline.com



From: Denis Magda <[hidden email]>
Date: Wednesday, September 23, 2020 at 4:14 PM
To: dev <[hidden email]>, "Carbone, Adam" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: Re: [DISCUSSION] Renaming Ignite's product category

Adam,

You defined GigaSpaces as a true in-memory computing platform. What is the true platform for you?


-
Denis


On Fri, Sep 18, 2020 at 7:02 AM Carbone, Adam <[hidden email]<mailto:[hidden email]>> wrote:
So when I came across Ignite It was described as an In Memory Data Grid

So one way to look at this is who do you fashion as Ignite competing against?

Are competing against Redis, Aerospike - In Memory Databases

Or are you more competing with

Gigaspaces - True In memory Compute platform

And then you have like of

Hazelcast that started as a Distributed Hash and have gained some features...

On thing that I think is a differentiator that isn't being highlighted but Is  unique feature to Ignited, and the primary reason we ended up here; The integration with spark and it's distributed/shared Datasets/Dataframes.

I don't know for me the In Memory Data Grid I think fits what Ignite is...

Regards

~Adam

Adam Carbone | Director of Innovation – Intelligent Platform Team | Bottomline Technologies
Office: 603-501-6446 | Mobile: [phone]
www.bottomline.com<http://www.bottomline.com>



On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]<mailto:[hidden email]>> wrote:

    I agree with Stephen about "database" devaluing what Ignite can do (though
    it probably hits the majority of existing use cases). I tend to go with
    "massively distributed storage and compute platform"

    I know, I didn't take sides, I just have both.

    Cheers,
      Glenn

    On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
    [hidden email]<mailto:[hidden email]>> wrote:

    > I think this is a great question. Explaining what Ignite does is always a
    > challenge, so having a useful “tag line” would be very valuable.
    >
    > I’m not sure what the answer is but I think calling it a “database”
    > devalues all the compute facilities. "Computing platform” may be too vague
    > but it at least says that we do more than “just” store data.
    >
    > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
    > [hidden email]<mailto:[hidden email]>> wrote:
    >
    > My vote is for the "distributed memory-first database". It clearly states
    > that Ignite is a database (which is true at this point), while still
    > emphasizing the in-memory computing power endorsed by the platform.
    >
    > The "in-memory computing platform" is an ambiguous term and doesn't really
    > reflect what Ignite is, especially in its current state.
    >
    > -Val
    >
    > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]<mailto:[hidden email]>> wrote:
    >
    >> Igniters,
    >>
    >> Throughout the history of our project, we could see how the addition of
    >> certain features required us to reassess the project's name and category.
    >>
    >> Before Ignite joined the ASF, it supported only compute APIs resembling
    >> the
    >> MapReduce engine of Hadoop. Those days, it was fair to define Ignite as "a
    >> distributed in-memory computing engine". Next, at the time of the project
    >> donation, it already included key-value/SQL/transactional APIs, was used
    >> as
    >> a distributed cache, and significantly outgrew the "in-memory computing
    >> engine" use case. That's how the project transitioned to the product
    >> category of in-memory caches and we started to name it as an "in-memory
    >> data grid" or "in-memory computing platform" to differentiate from
    >> classical caching products such as Memcached and Redis.
    >>
    >> Nowadays, the project outgrew its caching use case, and the classification
    >> of Ignite as an "in-memory data grid" or "in-memory computing platform"
    >> doesn't sound accurate. We rebuilt our storage engine by replacing a
    >> typical key-value engine with a B-tree engine that spans across memory and
    >> disk tiers. And it's not surprising to see more deployments of Ignite as a
    >> database on its own. So, it feels like we need to reconsider Ignite
    >> positioning again so that a) application developers can discover it easily
    >> via search engines and b) the project can stand out from in-memory
    >> projects
    >> with intersecting capabilities.
    >>
    >> To the point, I'm suggesting to reposition Ignite in one of the following
    >> ways:
    >>
    >>    1. Ignite is a "distributed X database". We are indeed a distributed
    >>    partitioned database where X can be "multi-tiered" or "memory-first" to
    >>    emphasize that we are more than an in-memory database.
    >>    2. Keep defining Ignite as "an in-memory computing platform" but name
    >>    our storage engine uniquely as "IgniteDB" to highlight that the
    >> platform is
    >>    powered by a "distributed multi-tiered/memory-first database".
    >>
    >> What is your thinking?
    >>
    >>
    >> (Also, regardless of a selected name, Ignite still will be used as a cache
    >> and grid, and we're not going to stop appealing to those use cases. But
    >> those are just use cases while Ignite has to figure out its new identity
    >> ... again).
    >>
    >>
    >> -
    >> Denis
    >>
    >
    >
    >

[dmagda]

Nikita, Cos,

Agree, IgniteDB would be a much better option if the project would be
launched these days with the current set of capabilities. But, as of now,
the renaming won't be a benign move, it can do more bad than good. "Apache
Ignite" is already a brand and even a trademark, the organic traffic is
high and the word-of-mouth is ramping up. So, it doesn't make sense from a
marketing standpoint. Also, regardless of the name you still need to define
your database - whether it's columnar, in-memory, memory-X,
extraterrestrial, or interstellar, or whatever. Anyway, I believe that
Ignite can easily pivot without the name change.

-
Denis


On Tue, Sep 22, 2020 at 11:49 AM Konstantin Boudnik <[hidden email]> wrote:

> +1
>
> With regards,
>    Cos
>
> On 2020-09-21 20:35, Nikita Ivanov wrote:
> > My vote is to just call ignite "IgniteDB". That's it. No other additional
> > explanation is required as no amount of additional verbiage will help.
> > Every DB is different: from MongoDB, to RedisDB, to CockroachDB, to
> Oracle
> > - they all look & act completely different, and they don't go around
> trying
> > to explain in one line what they do and how they are different.
> >
> > "IgniteDB" is clear, concise and gives us the broadest initial acceptance
> > from the new user perspective.
> >
> > Thanks,
> > --
> > Nikita Ivanov
> >
> >
> >
> > On Sat, Sep 19, 2020 at 1:10 PM Saikat Maitra <[hidden email]>
> > wrote:
> >
> >> Hi,
> >>
> >> My thoughts are similar to as Denis and Val mentioned like Apache
> Ignite -
> >> "A Memory Centric Database".
> >>
> >> It aligns to current features of Apache Ignite as mentioned in the below
> >> post.
> >>
> >>
> >>
> https://thenewstack.io/memory-centric-architectures-whats-next-for-in-memory-computing
> >>
> >> Regards,
> >> Saikat
> >>
> >> On Fri, Sep 18, 2020 at 9:02 AM Carbone, Adam <
> [hidden email]>
> >> wrote:
> >>
> >>> So when I came across Ignite It was described as an In Memory Data Grid
> >>>
> >>> So one way to look at this is who do you fashion as Ignite competing
> >>> against?
> >>>
> >>> Are competing against Redis, Aerospike - In Memory Databases
> >>>
> >>> Or are you more competing with
> >>>
> >>> Gigaspaces - True In memory Compute platform
> >>>
> >>> And then you have like of
> >>>
> >>> Hazelcast that started as a Distributed Hash and have gained some
> >>> features...
> >>>
> >>> On thing that I think is a differentiator that isn't being highlighted
> >>> but Is  unique feature to Ignited, and the primary reason we ended up
> here;
> >>> The integration with spark and it's distributed/shared
> Datasets/Dataframes.
> >>>
> >>> I don't know for me the In Memory Data Grid I think fits what Ignite
> >>> is...
> >>>
> >>> Regards
> >>>
> >>> ~Adam
> >>>
> >>> Adam Carbone | Director of Innovation – Intelligent Platform Team |
> >>> Bottomline Technologies
> >>> Office: 603-501-6446 | Mobile: [phone]
> >>> www.bottomline.com
> >>>
> >>>
> >>>
> >>> On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]> wrote:
> >>>
> >>>      I agree with Stephen about "database" devaluing what Ignite can do
> >>> (though
> >>>      it probably hits the majority of existing use cases). I tend to go
> >>> with
> >>>      "massively distributed storage and compute platform"
> >>>
> >>>      I know, I didn't take sides, I just have both.
> >>>
> >>>      Cheers,
> >>>        Glenn
> >>>
> >>>      On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
> >>>      [hidden email]> wrote:
> >>>
> >>>      > I think this is a great question. Explaining what Ignite does is
> >>> always a
> >>>      > challenge, so having a useful “tag line” would be very valuable.
> >>>      >
> >>>      > I’m not sure what the answer is but I think calling it a
> “database”
> >>>      > devalues all the compute facilities. "Computing platform” may be
> >>> too vague
> >>>      > but it at least says that we do more than “just” store data.
> >>>      >
> >>>      > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
> >>>      > [hidden email]> wrote:
> >>>      >
> >>>      > My vote is for the "distributed memory-first database". It
> clearly
> >>> states
> >>>      > that Ignite is a database (which is true at this point), while
> still
> >>>      > emphasizing the in-memory computing power endorsed by the
> platform.
> >>>      >
> >>>      > The "in-memory computing platform" is an ambiguous term and
> doesn't
> >>> really
> >>>      > reflect what Ignite is, especially in its current state.
> >>>      >
> >>>      > -Val
> >>>      >
> >>>      > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]>
> >>> wrote:
> >>>      >
> >>>      >> Igniters,
> >>>      >>
> >>>      >> Throughout the history of our project, we could see how the
> >>> addition of
> >>>      >> certain features required us to reassess the project's name and
> >>> category.
> >>>      >>
> >>>      >> Before Ignite joined the ASF, it supported only compute APIs
> >>> resembling
> >>>      >> the
> >>>      >> MapReduce engine of Hadoop. Those days, it was fair to define
> >>> Ignite as "a
> >>>      >> distributed in-memory computing engine". Next, at the time of
> the
> >>> project
> >>>      >> donation, it already included key-value/SQL/transactional APIs,
> >>> was used
> >>>      >> as
> >>>      >> a distributed cache, and significantly outgrew the "in-memory
> >>> computing
> >>>      >> engine" use case. That's how the project transitioned to the
> >>> product
> >>>      >> category of in-memory caches and we started to name it as an
> >>> "in-memory
> >>>      >> data grid" or "in-memory computing platform" to differentiate
> from
> >>>      >> classical caching products such as Memcached and Redis.
> >>>      >>
> >>>      >> Nowadays, the project outgrew its caching use case, and the
> >>> classification
> >>>      >> of Ignite as an "in-memory data grid" or "in-memory computing
> >>> platform"
> >>>      >> doesn't sound accurate. We rebuilt our storage engine by
> replacing
> >>> a
> >>>      >> typical key-value engine with a B-tree engine that spans across
> >>> memory and
> >>>      >> disk tiers. And it's not surprising to see more deployments of
> >>> Ignite as a
> >>>      >> database on its own. So, it feels like we need to reconsider
> Ignite
> >>>      >> positioning again so that a) application developers can
> discover
> >>> it easily
> >>>      >> via search engines and b) the project can stand out from
> in-memory
> >>>      >> projects
> >>>      >> with intersecting capabilities.
> >>>      >>
> >>>      >> To the point, I'm suggesting to reposition Ignite in one of the
> >>> following
> >>>      >> ways:
> >>>      >>
> >>>      >>    1. Ignite is a "distributed X database". We are indeed a
> >>> distributed
> >>>      >>    partitioned database where X can be "multi-tiered" or
> >>> "memory-first" to
> >>>      >>    emphasize that we are more than an in-memory database.
> >>>      >>    2. Keep defining Ignite as "an in-memory computing platform"
> >>> but name
> >>>      >>    our storage engine uniquely as "IgniteDB" to highlight that
> the
> >>>      >> platform is
> >>>      >>    powered by a "distributed multi-tiered/memory-first
> database".
> >>>      >>
> >>>      >> What is your thinking?
> >>>      >>
> >>>      >>
> >>>      >> (Also, regardless of a selected name, Ignite still will be
> used as
> >>> a cache
> >>>      >> and grid, and we're not going to stop appealing to those use
> >>> cases. But
> >>>      >> those are just use cases while Ignite has to figure out its new
> >>> identity
> >>>      >> ... again).
> >>>      >>
> >>>      >>
> >>>      >> -
> >>>      >> Denis
> >>>      >>
> >>>      >
> >>>      >
> >>>      >
> >>>
> >>>
> >
>

[nivanov]

"Apache Ignite" will remain the same... We are just going to refer to it as
"IgniteDB" everywhere where it doesn't technically conflict with "Apache
Ignite". We are also not changing the package structure (i.e. the packaging
will remain 'org.apache.ignite.xxx').

Or... we can go and rename the project to "Apache IgniteDB" which is a
longer process but the community has plenty of time to do it in "ignite
3.0" timeframe. I'd love to hear other's opinions on that.

Thanks,
--
Nikita Ivanov



On Thu, Sep 24, 2020 at 11:44 AM Denis Magda <[hidden email]> wrote:

> Nikita, Cos,
>
> Agree, IgniteDB would be a much better option if the project would be
> launched these days with the current set of capabilities. But, as of now,
> the renaming won't be a benign move, it can do more bad than good. "Apache
> Ignite" is already a brand and even a trademark, the organic traffic is
> high and the word-of-mouth is ramping up. So, it doesn't make sense from a
> marketing standpoint. Also, regardless of the name you still need to define
> your database - whether it's columnar, in-memory, memory-X,
> extraterrestrial, or interstellar, or whatever. Anyway, I believe that
> Ignite can easily pivot without the name change.
>
> -
> Denis
>
>
> On Tue, Sep 22, 2020 at 11:49 AM Konstantin Boudnik <[hidden email]>
> wrote:
>
> > +1
> >
> > With regards,
> >    Cos
> >
> > On 2020-09-21 20:35, Nikita Ivanov wrote:
> > > My vote is to just call ignite "IgniteDB". That's it. No other
> additional
> > > explanation is required as no amount of additional verbiage will help.
> > > Every DB is different: from MongoDB, to RedisDB, to CockroachDB, to
> > Oracle
> > > - they all look & act completely different, and they don't go around
> > trying
> > > to explain in one line what they do and how they are different.
> > >
> > > "IgniteDB" is clear, concise and gives us the broadest initial
> acceptance
> > > from the new user perspective.
> > >
> > > Thanks,
> > > --
> > > Nikita Ivanov
> > >
> > >
> > >
> > > On Sat, Sep 19, 2020 at 1:10 PM Saikat Maitra <[hidden email]
> >
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> My thoughts are similar to as Denis and Val mentioned like Apache
> > Ignite -
> > >> "A Memory Centric Database".
> > >>
> > >> It aligns to current features of Apache Ignite as mentioned in the
> below
> > >> post.
> > >>
> > >>
> > >>
> >
> https://thenewstack.io/memory-centric-architectures-whats-next-for-in-memory-computing
> > >>
> > >> Regards,
> > >> Saikat
> > >>
> > >> On Fri, Sep 18, 2020 at 9:02 AM Carbone, Adam <
> > [hidden email]>
> > >> wrote:
> > >>
> > >>> So when I came across Ignite It was described as an In Memory Data
> Grid
> > >>>
> > >>> So one way to look at this is who do you fashion as Ignite competing
> > >>> against?
> > >>>
> > >>> Are competing against Redis, Aerospike - In Memory Databases
> > >>>
> > >>> Or are you more competing with
> > >>>
> > >>> Gigaspaces - True In memory Compute platform
> > >>>
> > >>> And then you have like of
> > >>>
> > >>> Hazelcast that started as a Distributed Hash and have gained some
> > >>> features...
> > >>>
> > >>> On thing that I think is a differentiator that isn't being
> highlighted
> > >>> but Is  unique feature to Ignited, and the primary reason we ended up
> > here;
> > >>> The integration with spark and it's distributed/shared
> > Datasets/Dataframes.
> > >>>
> > >>> I don't know for me the In Memory Data Grid I think fits what Ignite
> > >>> is...
> > >>>
> > >>> Regards
> > >>>
> > >>> ~Adam
> > >>>
> > >>> Adam Carbone | Director of Innovation – Intelligent Platform Team |
> > >>> Bottomline Technologies
> > >>> Office: 603-501-6446 | Mobile: [phone]
> > >>> www.bottomline.com
> > >>>
> > >>>
> > >>>
> > >>> On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]>
> wrote:
> > >>>
> > >>>      I agree with Stephen about "database" devaluing what Ignite can
> do
> > >>> (though
> > >>>      it probably hits the majority of existing use cases). I tend to
> go
> > >>> with
> > >>>      "massively distributed storage and compute platform"
> > >>>
> > >>>      I know, I didn't take sides, I just have both.
> > >>>
> > >>>      Cheers,
> > >>>        Glenn
> > >>>
> > >>>      On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
> > >>>      [hidden email]> wrote:
> > >>>
> > >>>      > I think this is a great question. Explaining what Ignite does
> is
> > >>> always a
> > >>>      > challenge, so having a useful “tag line” would be very
> valuable.
> > >>>      >
> > >>>      > I’m not sure what the answer is but I think calling it a
> > “database”
> > >>>      > devalues all the compute facilities. "Computing platform” may
> be
> > >>> too vague
> > >>>      > but it at least says that we do more than “just” store data.
> > >>>      >
> > >>>      > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
> > >>>      > [hidden email]> wrote:
> > >>>      >
> > >>>      > My vote is for the "distributed memory-first database". It
> > clearly
> > >>> states
> > >>>      > that Ignite is a database (which is true at this point), while
> > still
> > >>>      > emphasizing the in-memory computing power endorsed by the
> > platform.
> > >>>      >
> > >>>      > The "in-memory computing platform" is an ambiguous term and
> > doesn't
> > >>> really
> > >>>      > reflect what Ignite is, especially in its current state.
> > >>>      >
> > >>>      > -Val
> > >>>      >
> > >>>      > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <
> [hidden email]>
> > >>> wrote:
> > >>>      >
> > >>>      >> Igniters,
> > >>>      >>
> > >>>      >> Throughout the history of our project, we could see how the
> > >>> addition of
> > >>>      >> certain features required us to reassess the project's name
> and
> > >>> category.
> > >>>      >>
> > >>>      >> Before Ignite joined the ASF, it supported only compute APIs
> > >>> resembling
> > >>>      >> the
> > >>>      >> MapReduce engine of Hadoop. Those days, it was fair to define
> > >>> Ignite as "a
> > >>>      >> distributed in-memory computing engine". Next, at the time of
> > the
> > >>> project
> > >>>      >> donation, it already included key-value/SQL/transactional
> APIs,
> > >>> was used
> > >>>      >> as
> > >>>      >> a distributed cache, and significantly outgrew the "in-memory
> > >>> computing
> > >>>      >> engine" use case. That's how the project transitioned to the
> > >>> product
> > >>>      >> category of in-memory caches and we started to name it as an
> > >>> "in-memory
> > >>>      >> data grid" or "in-memory computing platform" to differentiate
> > from
> > >>>      >> classical caching products such as Memcached and Redis.
> > >>>      >>
> > >>>      >> Nowadays, the project outgrew its caching use case, and the
> > >>> classification
> > >>>      >> of Ignite as an "in-memory data grid" or "in-memory computing
> > >>> platform"
> > >>>      >> doesn't sound accurate. We rebuilt our storage engine by
> > replacing
> > >>> a
> > >>>      >> typical key-value engine with a B-tree engine that spans
> across
> > >>> memory and
> > >>>      >> disk tiers. And it's not surprising to see more deployments
> of
> > >>> Ignite as a
> > >>>      >> database on its own. So, it feels like we need to reconsider
> > Ignite
> > >>>      >> positioning again so that a) application developers can
> > discover
> > >>> it easily
> > >>>      >> via search engines and b) the project can stand out from
> > in-memory
> > >>>      >> projects
> > >>>      >> with intersecting capabilities.
> > >>>      >>
> > >>>      >> To the point, I'm suggesting to reposition Ignite in one of
> the
> > >>> following
> > >>>      >> ways:
> > >>>      >>
> > >>>      >>    1. Ignite is a "distributed X database". We are indeed a
> > >>> distributed
> > >>>      >>    partitioned database where X can be "multi-tiered" or
> > >>> "memory-first" to
> > >>>      >>    emphasize that we are more than an in-memory database.
> > >>>      >>    2. Keep defining Ignite as "an in-memory computing
> platform"
> > >>> but name
> > >>>      >>    our storage engine uniquely as "IgniteDB" to highlight
> that
> > the
> > >>>      >> platform is
> > >>>      >>    powered by a "distributed multi-tiered/memory-first
> > database".
> > >>>      >>
> > >>>      >> What is your thinking?
> > >>>      >>
> > >>>      >>
> > >>>      >> (Also, regardless of a selected name, Ignite still will be
> > used as
> > >>> a cache
> > >>>      >> and grid, and we're not going to stop appealing to those use
> > >>> cases. But
> > >>>      >> those are just use cases while Ignite has to figure out its
> new
> > >>> identity
> > >>>      >> ... again).
> > >>>      >>
> > >>>      >>
> > >>>      >> -
> > >>>      >> Denis
> > >>>      >>
> > >>>      >
> > >>>      >
> > >>>      >
> > >>>
> > >>>
> > >
> >
>

[dmagda]

Adam,

Like your way of thinking. It makes sense to me.

For me, a computing platform comprises two essential components - a storage
engine and compute APIs (not only compute grid, but also streaming, SQL,
etc.). Under this definition, Ignite fits the "compute platform" category
for sure, but the problem (and the reason why I started this discussion
thread) is that the "in-memory computing platform" is not a ubiquitous
product category. At the same time, we all know that Ignite is used to
speed things up by storing and executing in memory. And if you need to make
software faster, you usually search for something scalable or in-memory
(in-memory caches, in-memory, NoSQL, distributed databases). Basically,
most of the folks search for "caches" and "in-memory database" which is
related to Ignite and only the tip of the iceberg searches for "in-memory
computing platforms" and "data grids".

Btw, how has your story started with Ignite? How did you find out about it?

-
Denis


On Wed, Sep 23, 2020 at 1:24 PM Carbone, Adam <[hidden email]>
wrote:

> Good Evening Denis,
>
> I’m sure there are more out there as well,  I would consider platforms
> that the entire applications but that all the execution of code happens
> exclusively on the platform, and most of the applications are written to
> run in, not connected to the platform.
>
> Hmmm by this criteria k8s could possible fit the bill…
>
> Spark might even be considered a compute grid as well but it is not a
> generic compute framework and people don’t usually run there whole
> applications inside.
>
> What is the vision for the platform? That might help in this discussion,
> set your category with the direction you are heading, and what you are
> trying to achieve.
>
> Regards
>
>
>
> Adam Carbone | Director of Innovation – Intelligent Platform Team |
> Bottomline Technologies
> Office: 603-501-6446 | Mobile: [phone]
> www.bottomline.com
>
>
>
>
>
>
>
> *From: *Denis Magda <[hidden email]>
> *Date: *Wednesday, September 23, 2020 at 4:14 PM
> *To: *dev <[hidden email]>, "Carbone, Adam" <
> [hidden email]>
> *Cc: *"[hidden email]" <[hidden email]>
> *Subject: *Re: [DISCUSSION] Renaming Ignite's product category
>
>
>
> Adam,
>
>
>
> You defined GigaSpaces as a true in-memory computing platform. What is the
> true platform for you?
>
>
>
>
> -
>
> Denis
>
>
>
>
>
> On Fri, Sep 18, 2020 at 7:02 AM Carbone, Adam <[hidden email]>
> wrote:
>
> So when I came across Ignite It was described as an In Memory Data Grid
>
> So one way to look at this is who do you fashion as Ignite competing
> against?
>
> Are competing against Redis, Aerospike - In Memory Databases
>
> Or are you more competing with
>
> Gigaspaces - True In memory Compute platform
>
> And then you have like of
>
> Hazelcast that started as a Distributed Hash and have gained some
> features...
>
> On thing that I think is a differentiator that isn't being highlighted but
> Is  unique feature to Ignited, and the primary reason we ended up here; The
> integration with spark and it's distributed/shared Datasets/Dataframes.
>
> I don't know for me the In Memory Data Grid I think fits what Ignite is...
>
> Regards
>
> ~Adam
>
> Adam Carbone | Director of Innovation – Intelligent Platform Team |
> Bottomline Technologies
> Office: 603-501-6446 | Mobile: [phone]
> www.bottomline.com
>
>
>
> On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]> wrote:
>
>     I agree with Stephen about "database" devaluing what Ignite can do
> (though
>     it probably hits the majority of existing use cases). I tend to go with
>     "massively distributed storage and compute platform"
>
>     I know, I didn't take sides, I just have both.
>
>     Cheers,
>       Glenn
>
>     On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
>     [hidden email]> wrote:
>
>     > I think this is a great question. Explaining what Ignite does is
> always a
>     > challenge, so having a useful “tag line” would be very valuable.
>     >
>     > I’m not sure what the answer is but I think calling it a “database”
>     > devalues all the compute facilities. "Computing platform” may be too
> vague
>     > but it at least says that we do more than “just” store data.
>     >
>     > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
>     > [hidden email]> wrote:
>     >
>     > My vote is for the "distributed memory-first database". It clearly
> states
>     > that Ignite is a database (which is true at this point), while still
>     > emphasizing the in-memory computing power endorsed by the platform.
>     >
>     > The "in-memory computing platform" is an ambiguous term and doesn't
> really
>     > reflect what Ignite is, especially in its current state.
>     >
>     > -Val
>     >
>     > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]>
> wrote:
>     >
>     >> Igniters,
>     >>
>     >> Throughout the history of our project, we could see how the
> addition of
>     >> certain features required us to reassess the project's name and
> category.
>     >>
>     >> Before Ignite joined the ASF, it supported only compute APIs
> resembling
>     >> the
>     >> MapReduce engine of Hadoop. Those days, it was fair to define
> Ignite as "a
>     >> distributed in-memory computing engine". Next, at the time of the
> project
>     >> donation, it already included key-value/SQL/transactional APIs, was
> used
>     >> as
>     >> a distributed cache, and significantly outgrew the "in-memory
> computing
>     >> engine" use case. That's how the project transitioned to the product
>     >> category of in-memory caches and we started to name it as an
> "in-memory
>     >> data grid" or "in-memory computing platform" to differentiate from
>     >> classical caching products such as Memcached and Redis.
>     >>
>     >> Nowadays, the project outgrew its caching use case, and the
> classification
>     >> of Ignite as an "in-memory data grid" or "in-memory computing
> platform"
>     >> doesn't sound accurate. We rebuilt our storage engine by replacing a
>     >> typical key-value engine with a B-tree engine that spans across
> memory and
>     >> disk tiers. And it's not surprising to see more deployments of
> Ignite as a
>     >> database on its own. So, it feels like we need to reconsider Ignite
>     >> positioning again so that a) application developers can discover it
> easily
>     >> via search engines and b) the project can stand out from in-memory
>     >> projects
>     >> with intersecting capabilities.
>     >>
>     >> To the point, I'm suggesting to reposition Ignite in one of the
> following
>     >> ways:
>     >>
>     >>    1. Ignite is a "distributed X database". We are indeed a
> distributed
>     >>    partitioned database where X can be "multi-tiered" or
> "memory-first" to
>     >>    emphasize that we are more than an in-memory database.
>     >>    2. Keep defining Ignite as "an in-memory computing platform" but
> name
>     >>    our storage engine uniquely as "IgniteDB" to highlight that the
>     >> platform is
>     >>    powered by a "distributed multi-tiered/memory-first database".
>     >>
>     >> What is your thinking?
>     >>
>     >>
>     >> (Also, regardless of a selected name, Ignite still will be used as
> a cache
>     >> and grid, and we're not going to stop appealing to those use cases.
> But
>     >> those are just use cases while Ignite has to figure out its new
> identity
>     >> ... again).
>     >>
>     >>
>     >> -
>     >> Denis
>     >>
>     >
>     >
>     >
>
>

[dmagda]

If "Apache Ignite" remains then another option is to keep defining Ignite
as an in-memory computing platform that is shaped by two essential
components:

   - IgniteDB - unique storage engine
   - compute layer which is basically our APIs.

Also, check Mongo that titled its latest storage engine as WiredTiger to
highlight the uniqueness, that there is something special about it, urging
you to go ahead and look into (the same move should work for the Ignite
platform that is powered the IgniteDB database/storage engine):
https://docs.mongodb.com/manual/core/storage-engines/

Just another idea into this melting pot.


-
Denis


On Thu, Sep 24, 2020 at 11:51 AM Nikita Ivanov <[hidden email]> wrote:

> "Apache Ignite" will remain the same... We are just going to refer to it as
> "IgniteDB" everywhere where it doesn't technically conflict with "Apache
> Ignite". We are also not changing the package structure (i.e. the packaging
> will remain 'org.apache.ignite.xxx').
>
> Or... we can go and rename the project to "Apache IgniteDB" which is a
> longer process but the community has plenty of time to do it in "ignite
> 3.0" timeframe. I'd love to hear other's opinions on that.
>
> Thanks,
> --
> Nikita Ivanov
>
>
>
> On Thu, Sep 24, 2020 at 11:44 AM Denis Magda <[hidden email]> wrote:
>
> > Nikita, Cos,
> >
> > Agree, IgniteDB would be a much better option if the project would be
> > launched these days with the current set of capabilities. But, as of now,
> > the renaming won't be a benign move, it can do more bad than good.
> "Apache
> > Ignite" is already a brand and even a trademark, the organic traffic is
> > high and the word-of-mouth is ramping up. So, it doesn't make sense from
> a
> > marketing standpoint. Also, regardless of the name you still need to
> define
> > your database - whether it's columnar, in-memory, memory-X,
> > extraterrestrial, or interstellar, or whatever. Anyway, I believe that
> > Ignite can easily pivot without the name change.
> >
> > -
> > Denis
> >
> >
> > On Tue, Sep 22, 2020 at 11:49 AM Konstantin Boudnik <[hidden email]>
> > wrote:
> >
> > > +1
> > >
> > > With regards,
> > >    Cos
> > >
> > > On 2020-09-21 20:35, Nikita Ivanov wrote:
> > > > My vote is to just call ignite "IgniteDB". That's it. No other
> > additional
> > > > explanation is required as no amount of additional verbiage will
> help.
> > > > Every DB is different: from MongoDB, to RedisDB, to CockroachDB, to
> > > Oracle
> > > > - they all look & act completely different, and they don't go around
> > > trying
> > > > to explain in one line what they do and how they are different.
> > > >
> > > > "IgniteDB" is clear, concise and gives us the broadest initial
> > acceptance
> > > > from the new user perspective.
> > > >
> > > > Thanks,
> > > > --
> > > > Nikita Ivanov
> > > >
> > > >
> > > >
> > > > On Sat, Sep 19, 2020 at 1:10 PM Saikat Maitra <
> [hidden email]
> > >
> > > > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> My thoughts are similar to as Denis and Val mentioned like Apache
> > > Ignite -
> > > >> "A Memory Centric Database".
> > > >>
> > > >> It aligns to current features of Apache Ignite as mentioned in the
> > below
> > > >> post.
> > > >>
> > > >>
> > > >>
> > >
> >
> https://thenewstack.io/memory-centric-architectures-whats-next-for-in-memory-computing
> > > >>
> > > >> Regards,
> > > >> Saikat
> > > >>
> > > >> On Fri, Sep 18, 2020 at 9:02 AM Carbone, Adam <
> > > [hidden email]>
> > > >> wrote:
> > > >>
> > > >>> So when I came across Ignite It was described as an In Memory Data
> > Grid
> > > >>>
> > > >>> So one way to look at this is who do you fashion as Ignite
> competing
> > > >>> against?
> > > >>>
> > > >>> Are competing against Redis, Aerospike - In Memory Databases
> > > >>>
> > > >>> Or are you more competing with
> > > >>>
> > > >>> Gigaspaces - True In memory Compute platform
> > > >>>
> > > >>> And then you have like of
> > > >>>
> > > >>> Hazelcast that started as a Distributed Hash and have gained some
> > > >>> features...
> > > >>>
> > > >>> On thing that I think is a differentiator that isn't being
> > highlighted
> > > >>> but Is  unique feature to Ignited, and the primary reason we ended
> up
> > > here;
> > > >>> The integration with spark and it's distributed/shared
> > > Datasets/Dataframes.
> > > >>>
> > > >>> I don't know for me the In Memory Data Grid I think fits what
> Ignite
> > > >>> is...
> > > >>>
> > > >>> Regards
> > > >>>
> > > >>> ~Adam
> > > >>>
> > > >>> Adam Carbone | Director of Innovation – Intelligent Platform Team |
> > > >>> Bottomline Technologies
> > > >>> Office: 603-501-6446 | Mobile: [phone]
> > > >>> www.bottomline.com
> > > >>>
> > > >>>
> > > >>>
> > > >>> On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]>
> > wrote:
> > > >>>
> > > >>>      I agree with Stephen about "database" devaluing what Ignite
> can
> > do
> > > >>> (though
> > > >>>      it probably hits the majority of existing use cases). I tend
> to
> > go
> > > >>> with
> > > >>>      "massively distributed storage and compute platform"
> > > >>>
> > > >>>      I know, I didn't take sides, I just have both.
> > > >>>
> > > >>>      Cheers,
> > > >>>        Glenn
> > > >>>
> > > >>>      On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
> > > >>>      [hidden email]> wrote:
> > > >>>
> > > >>>      > I think this is a great question. Explaining what Ignite
> does
> > is
> > > >>> always a
> > > >>>      > challenge, so having a useful “tag line” would be very
> > valuable.
> > > >>>      >
> > > >>>      > I’m not sure what the answer is but I think calling it a
> > > “database”
> > > >>>      > devalues all the compute facilities. "Computing platform”
> may
> > be
> > > >>> too vague
> > > >>>      > but it at least says that we do more than “just” store data.
> > > >>>      >
> > > >>>      > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
> > > >>>      > [hidden email]> wrote:
> > > >>>      >
> > > >>>      > My vote is for the "distributed memory-first database". It
> > > clearly
> > > >>> states
> > > >>>      > that Ignite is a database (which is true at this point),
> while
> > > still
> > > >>>      > emphasizing the in-memory computing power endorsed by the
> > > platform.
> > > >>>      >
> > > >>>      > The "in-memory computing platform" is an ambiguous term and
> > > doesn't
> > > >>> really
> > > >>>      > reflect what Ignite is, especially in its current state.
> > > >>>      >
> > > >>>      > -Val
> > > >>>      >
> > > >>>      > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <
> > [hidden email]>
> > > >>> wrote:
> > > >>>      >
> > > >>>      >> Igniters,
> > > >>>      >>
> > > >>>      >> Throughout the history of our project, we could see how the
> > > >>> addition of
> > > >>>      >> certain features required us to reassess the project's name
> > and
> > > >>> category.
> > > >>>      >>
> > > >>>      >> Before Ignite joined the ASF, it supported only compute
> APIs
> > > >>> resembling
> > > >>>      >> the
> > > >>>      >> MapReduce engine of Hadoop. Those days, it was fair to
> define
> > > >>> Ignite as "a
> > > >>>      >> distributed in-memory computing engine". Next, at the time
> of
> > > the
> > > >>> project
> > > >>>      >> donation, it already included key-value/SQL/transactional
> > APIs,
> > > >>> was used
> > > >>>      >> as
> > > >>>      >> a distributed cache, and significantly outgrew the
> "in-memory
> > > >>> computing
> > > >>>      >> engine" use case. That's how the project transitioned to
> the
> > > >>> product
> > > >>>      >> category of in-memory caches and we started to name it as
> an
> > > >>> "in-memory
> > > >>>      >> data grid" or "in-memory computing platform" to
> differentiate
> > > from
> > > >>>      >> classical caching products such as Memcached and Redis.
> > > >>>      >>
> > > >>>      >> Nowadays, the project outgrew its caching use case, and the
> > > >>> classification
> > > >>>      >> of Ignite as an "in-memory data grid" or "in-memory
> computing
> > > >>> platform"
> > > >>>      >> doesn't sound accurate. We rebuilt our storage engine by
> > > replacing
> > > >>> a
> > > >>>      >> typical key-value engine with a B-tree engine that spans
> > across
> > > >>> memory and
> > > >>>      >> disk tiers. And it's not surprising to see more deployments
> > of
> > > >>> Ignite as a
> > > >>>      >> database on its own. So, it feels like we need to
> reconsider
> > > Ignite
> > > >>>      >> positioning again so that a) application developers can
> > > discover
> > > >>> it easily
> > > >>>      >> via search engines and b) the project can stand out from
> > > in-memory
> > > >>>      >> projects
> > > >>>      >> with intersecting capabilities.
> > > >>>      >>
> > > >>>      >> To the point, I'm suggesting to reposition Ignite in one of
> > the
> > > >>> following
> > > >>>      >> ways:
> > > >>>      >>
> > > >>>      >>    1. Ignite is a "distributed X database". We are indeed a
> > > >>> distributed
> > > >>>      >>    partitioned database where X can be "multi-tiered" or
> > > >>> "memory-first" to
> > > >>>      >>    emphasize that we are more than an in-memory database.
> > > >>>      >>    2. Keep defining Ignite as "an in-memory computing
> > platform"
> > > >>> but name
> > > >>>      >>    our storage engine uniquely as "IgniteDB" to highlight
> > that
> > > the
> > > >>>      >> platform is
> > > >>>      >>    powered by a "distributed multi-tiered/memory-first
> > > database".
> > > >>>      >>
> > > >>>      >> What is your thinking?
> > > >>>      >>
> > > >>>      >>
> > > >>>      >> (Also, regardless of a selected name, Ignite still will be
> > > used as
> > > >>> a cache
> > > >>>      >> and grid, and we're not going to stop appealing to those
> use
> > > >>> cases. But
> > > >>>      >> those are just use cases while Ignite has to figure out its
> > new
> > > >>> identity
> > > >>>      >> ... again).
> > > >>>      >>
> > > >>>      >>
> > > >>>      >> -
> > > >>>      >> Denis
> > > >>>      >>
> > > >>>      >
> > > >>>      >
> > > >>>      >
> > > >>>
> > > >>>
> > > >
> > >
> >
>

[Carbone, Adam]

Good Afternoon Denis,

We came across ignite in very similar ways to everyone else. We had our existing application that we were looking to ramp up and scale inside Kubernetes. It is an internal ML Platform that was developed largely as a monolithic application, we wanted work on it to be more cloud native. In order to accomplish that we needed to be able to split the separate services, they make heavy use of Spark so we liked the Shared Dataframes that ignite provided, we also stumbled across some of the Job Scheduling, as well as the Distributed locking... So when we saw that we might get all of those from a single platform instead of having to build/integrate with multiple parts we were intrigued. So far we have done a basic integration, next steps will be to really work on the shared spark dataframes.

Regards
~Adam

Adam Carbone | Director of Innovation – Intelligent Platform Team | Bottomline Technologies
Office: 603-501-6446 | Mobile: [phone]
www.bottomline.com
 
 

On 9/24/20, 2:55 PM, "Denis Magda" <[hidden email]> wrote:

    Adam,

    Like your way of thinking. It makes sense to me.

    For me, a computing platform comprises two essential components - a storage
    engine and compute APIs (not only compute grid, but also streaming, SQL,
    etc.). Under this definition, Ignite fits the "compute platform" category
    for sure, but the problem (and the reason why I started this discussion
    thread) is that the "in-memory computing platform" is not a ubiquitous
    product category. At the same time, we all know that Ignite is used to
    speed things up by storing and executing in memory. And if you need to make
    software faster, you usually search for something scalable or in-memory
    (in-memory caches, in-memory, NoSQL, distributed databases). Basically,
    most of the folks search for "caches" and "in-memory database" which is
    related to Ignite and only the tip of the iceberg searches for "in-memory
    computing platforms" and "data grids".

    Btw, how has your story started with Ignite? How did you find out about it?

    -
    Denis


    On Wed, Sep 23, 2020 at 1:24 PM Carbone, Adam <[hidden email]>
    wrote:

    > Good Evening Denis,
    >
    > I’m sure there are more out there as well,  I would consider platforms
    > that the entire applications but that all the execution of code happens
    > exclusively on the platform, and most of the applications are written to
    > run in, not connected to the platform.
    >
    > Hmmm by this criteria k8s could possible fit the bill…
    >
    > Spark might even be considered a compute grid as well but it is not a
    > generic compute framework and people don’t usually run there whole
    > applications inside.
    >
    > What is the vision for the platform? That might help in this discussion,
    > set your category with the direction you are heading, and what you are
    > trying to achieve.
    >
    > Regards
    >
    >
    >
    > Adam Carbone | Director of Innovation – Intelligent Platform Team |
    > Bottomline Technologies
    > Office: 603-501-6446 | Mobile: [phone]
    > www.bottomline.com
    >
    >
    >
    >
    >
    >
    >
    > *From: *Denis Magda <[hidden email]>
    > *Date: *Wednesday, September 23, 2020 at 4:14 PM
    > *To: *dev <[hidden email]>, "Carbone, Adam" <
    > [hidden email]>
    > *Cc: *"[hidden email]" <[hidden email]>
    > *Subject: *Re: [DISCUSSION] Renaming Ignite's product category
    >
    >
    >
    > Adam,
    >
    >
    >
    > You defined GigaSpaces as a true in-memory computing platform. What is the
    > true platform for you?
    >
    >
    >
    >
    > -
    >
    > Denis
    >
    >
    >
    >
    >
    > On Fri, Sep 18, 2020 at 7:02 AM Carbone, Adam <[hidden email]>
    > wrote:
    >
    > So when I came across Ignite It was described as an In Memory Data Grid
    >
    > So one way to look at this is who do you fashion as Ignite competing
    > against?
    >
    > Are competing against Redis, Aerospike - In Memory Databases
    >
    > Or are you more competing with
    >
    > Gigaspaces - True In memory Compute platform
    >
    > And then you have like of
    >
    > Hazelcast that started as a Distributed Hash and have gained some
    > features...
    >
    > On thing that I think is a differentiator that isn't being highlighted but
    > Is  unique feature to Ignited, and the primary reason we ended up here; The
    > integration with spark and it's distributed/shared Datasets/Dataframes.
    >
    > I don't know for me the In Memory Data Grid I think fits what Ignite is...
    >
    > Regards
    >
    > ~Adam
    >
    > Adam Carbone | Director of Innovation – Intelligent Platform Team |
    > Bottomline Technologies
    > Office: 603-501-6446 | Mobile: [phone]
    > www.bottomline.com
    >
    >
    >
    > On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]> wrote:
    >
    >     I agree with Stephen about "database" devaluing what Ignite can do
    > (though
    >     it probably hits the majority of existing use cases). I tend to go with
    >     "massively distributed storage and compute platform"
    >
    >     I know, I didn't take sides, I just have both.
    >
    >     Cheers,
    >       Glenn
    >
    >     On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
    >     [hidden email]> wrote:
    >
    >     > I think this is a great question. Explaining what Ignite does is
    > always a
    >     > challenge, so having a useful “tag line” would be very valuable.
    >     >
    >     > I’m not sure what the answer is but I think calling it a “database”
    >     > devalues all the compute facilities. "Computing platform” may be too
    > vague
    >     > but it at least says that we do more than “just” store data.
    >     >
    >     > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
    >     > [hidden email]> wrote:
    >     >
    >     > My vote is for the "distributed memory-first database". It clearly
    > states
    >     > that Ignite is a database (which is true at this point), while still
    >     > emphasizing the in-memory computing power endorsed by the platform.
    >     >
    >     > The "in-memory computing platform" is an ambiguous term and doesn't
    > really
    >     > reflect what Ignite is, especially in its current state.
    >     >
    >     > -Val
    >     >
    >     > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]>
    > wrote:
    >     >
    >     >> Igniters,
    >     >>
    >     >> Throughout the history of our project, we could see how the
    > addition of
    >     >> certain features required us to reassess the project's name and
    > category.
    >     >>
    >     >> Before Ignite joined the ASF, it supported only compute APIs
    > resembling
    >     >> the
    >     >> MapReduce engine of Hadoop. Those days, it was fair to define
    > Ignite as "a
    >     >> distributed in-memory computing engine". Next, at the time of the
    > project
    >     >> donation, it already included key-value/SQL/transactional APIs, was
    > used
    >     >> as
    >     >> a distributed cache, and significantly outgrew the "in-memory
    > computing
    >     >> engine" use case. That's how the project transitioned to the product
    >     >> category of in-memory caches and we started to name it as an
    > "in-memory
    >     >> data grid" or "in-memory computing platform" to differentiate from
    >     >> classical caching products such as Memcached and Redis.
    >     >>
    >     >> Nowadays, the project outgrew its caching use case, and the
    > classification
    >     >> of Ignite as an "in-memory data grid" or "in-memory computing
    > platform"
    >     >> doesn't sound accurate. We rebuilt our storage engine by replacing a
    >     >> typical key-value engine with a B-tree engine that spans across
    > memory and
    >     >> disk tiers. And it's not surprising to see more deployments of
    > Ignite as a
    >     >> database on its own. So, it feels like we need to reconsider Ignite
    >     >> positioning again so that a) application developers can discover it
    > easily
    >     >> via search engines and b) the project can stand out from in-memory
    >     >> projects
    >     >> with intersecting capabilities.
    >     >>
    >     >> To the point, I'm suggesting to reposition Ignite in one of the
    > following
    >     >> ways:
    >     >>
    >     >>    1. Ignite is a "distributed X database". We are indeed a
    > distributed
    >     >>    partitioned database where X can be "multi-tiered" or
    > "memory-first" to
    >     >>    emphasize that we are more than an in-memory database.
    >     >>    2. Keep defining Ignite as "an in-memory computing platform" but
    > name
    >     >>    our storage engine uniquely as "IgniteDB" to highlight that the
    >     >> platform is
    >     >>    powered by a "distributed multi-tiered/memory-first database".
    >     >>
    >     >> What is your thinking?
    >     >>
    >     >>
    >     >> (Also, regardless of a selected name, Ignite still will be used as
    > a cache
    >     >> and grid, and we're not going to stop appealing to those use cases.
    > But
    >     >> those are just use cases while Ignite has to figure out its new
    > identity
    >     >> ... again).
    >     >>
    >     >>
    >     >> -
    >     >> Denis
    >     >>
    >     >
    >     >
    >     >
    >
    >

[nivanov]

Let's try to simplify the project's messaging - not introduce new
sub-component naming or synthetic shelving to it :-)
--
Nikita Ivanov



On Thu, Sep 24, 2020 at 12:01 PM Denis Magda <[hidden email]> wrote:

> If "Apache Ignite" remains then another option is to keep defining Ignite
> as an in-memory computing platform that is shaped by two essential
> components:
>
>    - IgniteDB - unique storage engine
>    - compute layer which is basically our APIs.
>
> Also, check Mongo that titled its latest storage engine as WiredTiger to
> highlight the uniqueness, that there is something special about it, urging
> you to go ahead and look into (the same move should work for the Ignite
> platform that is powered the IgniteDB database/storage engine):
> https://docs.mongodb.com/manual/core/storage-engines/
>
> Just another idea into this melting pot.
>
>
> -
> Denis
>
>
> On Thu, Sep 24, 2020 at 11:51 AM Nikita Ivanov <[hidden email]>
> wrote:
>
> > "Apache Ignite" will remain the same... We are just going to refer to it
> as
> > "IgniteDB" everywhere where it doesn't technically conflict with "Apache
> > Ignite". We are also not changing the package structure (i.e. the
> packaging
> > will remain 'org.apache.ignite.xxx').
> >
> > Or... we can go and rename the project to "Apache IgniteDB" which is a
> > longer process but the community has plenty of time to do it in "ignite
> > 3.0" timeframe. I'd love to hear other's opinions on that.
> >
> > Thanks,
> > --
> > Nikita Ivanov
> >
> >
> >
> > On Thu, Sep 24, 2020 at 11:44 AM Denis Magda <[hidden email]> wrote:
> >
> > > Nikita, Cos,
> > >
> > > Agree, IgniteDB would be a much better option if the project would be
> > > launched these days with the current set of capabilities. But, as of
> now,
> > > the renaming won't be a benign move, it can do more bad than good.
> > "Apache
> > > Ignite" is already a brand and even a trademark, the organic traffic is
> > > high and the word-of-mouth is ramping up. So, it doesn't make sense
> from
> > a
> > > marketing standpoint. Also, regardless of the name you still need to
> > define
> > > your database - whether it's columnar, in-memory, memory-X,
> > > extraterrestrial, or interstellar, or whatever. Anyway, I believe that
> > > Ignite can easily pivot without the name change.
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Tue, Sep 22, 2020 at 11:49 AM Konstantin Boudnik <[hidden email]>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > With regards,
> > > >    Cos
> > > >
> > > > On 2020-09-21 20:35, Nikita Ivanov wrote:
> > > > > My vote is to just call ignite "IgniteDB". That's it. No other
> > > additional
> > > > > explanation is required as no amount of additional verbiage will
> > help.
> > > > > Every DB is different: from MongoDB, to RedisDB, to CockroachDB, to
> > > > Oracle
> > > > > - they all look & act completely different, and they don't go
> around
> > > > trying
> > > > > to explain in one line what they do and how they are different.
> > > > >
> > > > > "IgniteDB" is clear, concise and gives us the broadest initial
> > > acceptance
> > > > > from the new user perspective.
> > > > >
> > > > > Thanks,
> > > > > --
> > > > > Nikita Ivanov
> > > > >
> > > > >
> > > > >
> > > > > On Sat, Sep 19, 2020 at 1:10 PM Saikat Maitra <
> > [hidden email]
> > > >
> > > > > wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> My thoughts are similar to as Denis and Val mentioned like Apache
> > > > Ignite -
> > > > >> "A Memory Centric Database".
> > > > >>
> > > > >> It aligns to current features of Apache Ignite as mentioned in the
> > > below
> > > > >> post.
> > > > >>
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://thenewstack.io/memory-centric-architectures-whats-next-for-in-memory-computing
> > > > >>
> > > > >> Regards,
> > > > >> Saikat
> > > > >>
> > > > >> On Fri, Sep 18, 2020 at 9:02 AM Carbone, Adam <
> > > > [hidden email]>
> > > > >> wrote:
> > > > >>
> > > > >>> So when I came across Ignite It was described as an In Memory
> Data
> > > Grid
> > > > >>>
> > > > >>> So one way to look at this is who do you fashion as Ignite
> > competing
> > > > >>> against?
> > > > >>>
> > > > >>> Are competing against Redis, Aerospike - In Memory Databases
> > > > >>>
> > > > >>> Or are you more competing with
> > > > >>>
> > > > >>> Gigaspaces - True In memory Compute platform
> > > > >>>
> > > > >>> And then you have like of
> > > > >>>
> > > > >>> Hazelcast that started as a Distributed Hash and have gained some
> > > > >>> features...
> > > > >>>
> > > > >>> On thing that I think is a differentiator that isn't being
> > > highlighted
> > > > >>> but Is  unique feature to Ignited, and the primary reason we
> ended
> > up
> > > > here;
> > > > >>> The integration with spark and it's distributed/shared
> > > > Datasets/Dataframes.
> > > > >>>
> > > > >>> I don't know for me the In Memory Data Grid I think fits what
> > Ignite
> > > > >>> is...
> > > > >>>
> > > > >>> Regards
> > > > >>>
> > > > >>> ~Adam
> > > > >>>
> > > > >>> Adam Carbone | Director of Innovation – Intelligent Platform
> Team |
> > > > >>> Bottomline Technologies
> > > > >>> Office: 603-501-6446 | Mobile: [phone]
> > > > >>> www.bottomline.com
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]>
> > > wrote:
> > > > >>>
> > > > >>>      I agree with Stephen about "database" devaluing what Ignite
> > can
> > > do
> > > > >>> (though
> > > > >>>      it probably hits the majority of existing use cases). I tend
> > to
> > > go
> > > > >>> with
> > > > >>>      "massively distributed storage and compute platform"
> > > > >>>
> > > > >>>      I know, I didn't take sides, I just have both.
> > > > >>>
> > > > >>>      Cheers,
> > > > >>>        Glenn
> > > > >>>
> > > > >>>      On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
> > > > >>>      [hidden email]> wrote:
> > > > >>>
> > > > >>>      > I think this is a great question. Explaining what Ignite
> > does
> > > is
> > > > >>> always a
> > > > >>>      > challenge, so having a useful “tag line” would be very
> > > valuable.
> > > > >>>      >
> > > > >>>      > I’m not sure what the answer is but I think calling it a
> > > > “database”
> > > > >>>      > devalues all the compute facilities. "Computing platform”
> > may
> > > be
> > > > >>> too vague
> > > > >>>      > but it at least says that we do more than “just” store
> data.
> > > > >>>      >
> > > > >>>      > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
> > > > >>>      > [hidden email]> wrote:
> > > > >>>      >
> > > > >>>      > My vote is for the "distributed memory-first database". It
> > > > clearly
> > > > >>> states
> > > > >>>      > that Ignite is a database (which is true at this point),
> > while
> > > > still
> > > > >>>      > emphasizing the in-memory computing power endorsed by the
> > > > platform.
> > > > >>>      >
> > > > >>>      > The "in-memory computing platform" is an ambiguous term
> and
> > > > doesn't
> > > > >>> really
> > > > >>>      > reflect what Ignite is, especially in its current state.
> > > > >>>      >
> > > > >>>      > -Val
> > > > >>>      >
> > > > >>>      > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <
> > > [hidden email]>
> > > > >>> wrote:
> > > > >>>      >
> > > > >>>      >> Igniters,
> > > > >>>      >>
> > > > >>>      >> Throughout the history of our project, we could see how
> the
> > > > >>> addition of
> > > > >>>      >> certain features required us to reassess the project's
> name
> > > and
> > > > >>> category.
> > > > >>>      >>
> > > > >>>      >> Before Ignite joined the ASF, it supported only compute
> > APIs
> > > > >>> resembling
> > > > >>>      >> the
> > > > >>>      >> MapReduce engine of Hadoop. Those days, it was fair to
> > define
> > > > >>> Ignite as "a
> > > > >>>      >> distributed in-memory computing engine". Next, at the
> time
> > of
> > > > the
> > > > >>> project
> > > > >>>      >> donation, it already included key-value/SQL/transactional
> > > APIs,
> > > > >>> was used
> > > > >>>      >> as
> > > > >>>      >> a distributed cache, and significantly outgrew the
> > "in-memory
> > > > >>> computing
> > > > >>>      >> engine" use case. That's how the project transitioned to
> > the
> > > > >>> product
> > > > >>>      >> category of in-memory caches and we started to name it as
> > an
> > > > >>> "in-memory
> > > > >>>      >> data grid" or "in-memory computing platform" to
> > differentiate
> > > > from
> > > > >>>      >> classical caching products such as Memcached and Redis.
> > > > >>>      >>
> > > > >>>      >> Nowadays, the project outgrew its caching use case, and
> the
> > > > >>> classification
> > > > >>>      >> of Ignite as an "in-memory data grid" or "in-memory
> > computing
> > > > >>> platform"
> > > > >>>      >> doesn't sound accurate. We rebuilt our storage engine by
> > > > replacing
> > > > >>> a
> > > > >>>      >> typical key-value engine with a B-tree engine that spans
> > > across
> > > > >>> memory and
> > > > >>>      >> disk tiers. And it's not surprising to see more
> deployments
> > > of
> > > > >>> Ignite as a
> > > > >>>      >> database on its own. So, it feels like we need to
> > reconsider
> > > > Ignite
> > > > >>>      >> positioning again so that a) application developers can
> > > > discover
> > > > >>> it easily
> > > > >>>      >> via search engines and b) the project can stand out from
> > > > in-memory
> > > > >>>      >> projects
> > > > >>>      >> with intersecting capabilities.
> > > > >>>      >>
> > > > >>>      >> To the point, I'm suggesting to reposition Ignite in one
> of
> > > the
> > > > >>> following
> > > > >>>      >> ways:
> > > > >>>      >>
> > > > >>>      >>    1. Ignite is a "distributed X database". We are
> indeed a
> > > > >>> distributed
> > > > >>>      >>    partitioned database where X can be "multi-tiered" or
> > > > >>> "memory-first" to
> > > > >>>      >>    emphasize that we are more than an in-memory database.
> > > > >>>      >>    2. Keep defining Ignite as "an in-memory computing
> > > platform"
> > > > >>> but name
> > > > >>>      >>    our storage engine uniquely as "IgniteDB" to highlight
> > > that
> > > > the
> > > > >>>      >> platform is
> > > > >>>      >>    powered by a "distributed multi-tiered/memory-first
> > > > database".
> > > > >>>      >>
> > > > >>>      >> What is your thinking?
> > > > >>>      >>
> > > > >>>      >>
> > > > >>>      >> (Also, regardless of a selected name, Ignite still will
> be
> > > > used as
> > > > >>> a cache
> > > > >>>      >> and grid, and we're not going to stop appealing to those
> > use
> > > > >>> cases. But
> > > > >>>      >> those are just use cases while Ignite has to figure out
> its
> > > new
> > > > >>> identity
> > > > >>>      >> ... again).
> > > > >>>      >>
> > > > >>>      >>
> > > > >>>      >> -
> > > > >>>      >> Denis
> > > > >>>      >>
> > > > >>>      >
> > > > >>>      >
> > > > >>>      >
> > > > >>>
> > > > >>>
> > > > >
> > > >
> > >
> >
>