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 <kondako...@mail.ru.invalid>:

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