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



Reply via email to