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