Re: [DISCUSSION] Renaming Ignite's product category

[Denis Magda]

Apache Ignite is a trademark in the U.S. and we're still working to get it
registered in China. It's a long process that can span years. It took us
years. Not to say about all the content that is published and indexed for
the "Apache Ignite" term. These are the two primary reasons why I don't
support the idea of renaming the project into "IgniteDB" or anything else.
Plus, I don't believe that it will be a game-changer. Kafka, Hadoop, Redis,
Spark don't have any special additions in their name and that didn't bar
them from climbing to the mountain peak.

-
Denis


On Fri, Oct 2, 2020 at 3:49 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Hi Denis,
>
> Correct me if I'm wrong, but it sounds like you interpret the term
> "database" as just storage, separating it from processing capabilities. I
> would disagree with that. *Any* database provides such capabilities. Even
> traditional relational databases, which are based on SQL, allow you to do
> filtering, aggregations, and other stuff on the server side. Not to mention
> that there are also triggers, stored procedures, and other features.
>
> On its own, the fact that Apache Ignite has computational APIs doesn't make
> the product unique. The uniqueness comes from specific APIs and features it
> provides.
>
> That said, calling Ignite a database seems absolutely fair to me. As a
> matter of fact, when I talk about Ignite, I usually describe it as "a
> database that allows you to ...", where I typically fill the
> blanks depending on who I talk to, what the use case might be, etc.
>
> I'm OK with calling the product "Ignite Database" or "IgniteDB". If we
> follow this route, what are the changes we will need to make? Will it only
> affect the website and documentation? I can't think of any code changes
> that might be required.
>
> -Val
>
> On Thu, Sep 24, 2020 at 12:01 PM Denis Magda  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 
> > 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 
> 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 
> > > > 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,
> > > > > > --
> > > 

Re: [DISCUSSION] Renaming Ignite's product category

[Valentin Kulichenko]

Hi Denis,

Correct me if I'm wrong, but it sounds like you interpret the term
"database" as just storage, separating it from processing capabilities. I
would disagree with that. *Any* database provides such capabilities. Even
traditional relational databases, which are based on SQL, allow you to do
filtering, aggregations, and other stuff on the server side. Not to mention
that there are also triggers, stored procedures, and other features.

On its own, the fact that Apache Ignite has computational APIs doesn't make
the product unique. The uniqueness comes from specific APIs and features it
provides.

That said, calling Ignite a database seems absolutely fair to me. As a
matter of fact, when I talk about Ignite, I usually describe it as "a
database that allows you to ...", where I typically fill the
blanks depending on who I talk to, what the use case might be, etc.

I'm OK with calling the product "Ignite Database" or "IgniteDB". If we
follow this route, what are the changes we will need to make? Will it only
affect the website and documentation? I can't think of any code changes
that might be required.

-Val

On Thu, Sep 24, 2020 at 12:01 PM Denis Magda  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 
> 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  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 
> > > 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 <
> > saikat.mai...@gmail.com
> > > >
> > > > > 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 <
> > > > adam.carb...@bottomline.com>
> > > > >> wrote:
> > > > >>
> > > > >>> So when I came across Ignite It was described as an In Memory
> Data
> > > Grid
> > > > >>>
> > > > >>> So one way 

Re: [DISCUSSION] Renaming Ignite's product category

[Nikita Ivanov]

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  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 
> 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  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 
> > > 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 <
> > saikat.mai...@gmail.com
> > > >
> > > > > 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 <
> > > > adam.carb...@bottomline.com>
> > > > >> 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 

Re: [DISCUSSION] Renaming Ignite's product category

[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: 603-570-8418
www.bottomline.com
 
 

On 9/24/20, 2:55 PM, "Denis Magda"  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 
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: 603-570-8418
> www.bottomline.com
>
>
>
>
>
>
>
> *From: *Denis Magda 
> *Date: *Wednesday, September 23, 2020 at 4:14 PM
> *To: *dev , "Carbone, Adam" <
> adam.carb...@bottomline.com>
> *Cc: *"u...@ignite.apache.org" 
> *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 

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

Re: [DISCUSSION] Renaming Ignite's product category

[Denis Magda]

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 
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: 603-570-8418
> www.bottomline.com
>
>
>
>
>
>
>
> *From: *Denis Magda 
> *Date: *Wednesday, September 23, 2020 at 4:14 PM
> *To: *dev , "Carbone, Adam" <
> adam.carb...@bottomline.com>
> *Cc: *"u...@ignite.apache.org" 
> *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 
> 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: 603-570-8418
> www.bottomline.com
>
>
>
> On 9/17/20, 11:45 AM, "Glenn Wiebe"  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, <
> stephen.darling...@gridgain.com> 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 <
> > valentin.kuliche...@gmail.com> 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
>  

Re: [DISCUSSION] Renaming Ignite's product category

[Nikita Ivanov]

"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  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 
> 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  >
> > > 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 <
> > adam.carb...@bottomline.com>
> > >> 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: 603-570-8418
> > >>> www.bottomline.com
> > >>>
> > >>>
> > >>>
> > >>> On 9/17/20, 11:45 AM, "Glenn Wiebe" 
> 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, <
> > >>>  stephen.darling...@gridgain.com> 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 <
> > >>>  > valentin.kuliche...@gmail.com> wrote:
> > >>>  >
> > >>>  > My vote is for the "distributed memory-first database". It
> > clearly
> > >>> states
> > >>>  > 

Re: [DISCUSSION] Renaming Ignite's product category

[Denis Magda]

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  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 
> > 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 <
> adam.carb...@bottomline.com>
> >> 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: 603-570-8418
> >>> www.bottomline.com
> >>>
> >>>
> >>>
> >>> On 9/17/20, 11:45 AM, "Glenn Wiebe"  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, <
> >>>  stephen.darling...@gridgain.com> 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 <
> >>>  > valentin.kuliche...@gmail.com> 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 
> >>> 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 

Re: [DISCUSSION] Renaming Ignite's product category

[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: 603-570-8418
www.bottomline.com



From: Denis Magda 
Date: Wednesday, September 23, 2020 at 4:14 PM
To: dev , "Carbone, Adam" 
Cc: "u...@ignite.apache.org" 
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 
mailto:adam.carb...@bottomline.com>> 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: 603-570-8418
www.bottomline.com<http://www.bottomline.com>



On 9/17/20, 11:45 AM, "Glenn Wiebe" 
mailto:glenn.wi...@gridgain.com>> 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, <
stephen.darling...@gridgain.com<mailto:stephen.darling...@gridgain.com>> 
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 <
> valentin.kuliche...@gmail.com<mailto:valentin.kuliche...@gmail.com>> 
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 
mailto:dma...@apache.org>> 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
  

Re: [DISCUSSION] Renaming Ignite's product category

[Denis Magda]

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 
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: 603-570-8418
> www.bottomline.com
>
>
>
> On 9/17/20, 11:45 AM, "Glenn Wiebe"  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, <
> stephen.darling...@gridgain.com> 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 <
> > valentin.kuliche...@gmail.com> 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 
> 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 

Re: [DISCUSSION] Renaming Ignite's product category

[Konstantin Boudnik]

+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 
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 
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: 603-570-8418
www.bottomline.com



On 9/17/20, 11:45 AM, "Glenn Wiebe"  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, <
 stephen.darling...@gridgain.com> 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 <
 > valentin.kuliche...@gmail.com> 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 
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:

Re: [DISCUSSION] Renaming Ignite's product category

[Nikita Ivanov]

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 
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 
> 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: 603-570-8418
>> www.bottomline.com
>>
>>
>>
>> On 9/17/20, 11:45 AM, "Glenn Wiebe"  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, <
>> stephen.darling...@gridgain.com> 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 <
>> > valentin.kuliche...@gmail.com> 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 
>> 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
>> 

Re: [DISCUSSION] Renaming Ignite's product category

[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 
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: 603-570-8418
> www.bottomline.com
>
>
>
> On 9/17/20, 11:45 AM, "Glenn Wiebe"  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, <
> stephen.darling...@gridgain.com> 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 <
> > valentin.kuliche...@gmail.com> 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 
> 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 

Re: [DISCUSSION] Renaming Ignite's product category

[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: 603-570-8418
www.bottomline.com
 
 

On 9/17/20, 11:45 AM, "Glenn Wiebe"  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, <
stephen.darling...@gridgain.com> 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 <
> valentin.kuliche...@gmail.com> 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  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
>>
>
>
>

Re: [DISCUSSION] Renaming Ignite's product category

[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,

Re: [DISCUSSION] Renaming Ignite's product category

[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 :

> 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 <
> > valentin.kuliche...@gmail.com> 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  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
> >>>
> >>
> >
>

Re: [DISCUSSION] Renaming Ignite's product category

[Stephen Darlington]

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

Re: [DISCUSSION] Renaming Ignite's product category

[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 <
valentin.kuliche...@gmail.com> 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  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

Re: [DISCUSSION] Renaming Ignite's product category

[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 <
valentin.kuliche...@gmail.com> 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  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
> >
>

Re: [DISCUSSION] Renaming Ignite's product category

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

[DISCUSSION] Renaming Ignite's product category

[Denis Magda]

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