Lets move on with SQL schema == Ignite cache. It worked always like this, I
see no reasons to change this.

Sergi

2017-01-13 11:20 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>:

> "Tablespace" (Oracle, PostgreSQL) is what maps better than "schema" to our
> cache. But not ideally still.
>
> On Fri, Jan 13, 2017 at 11:10 AM, Vladimir Ozerov <voze...@gridgain.com>
> wrote:
>
> > Alex,
> >
> > Currently Ignite is not used as database. It is used as search engine -
> > several types, several tables, several joins. This is why having "SCHEMA
> ==
> > cache" was never a problem. Users have never build complex SQL
> applications
> > on top of Ignite. But we are going towards database. And my question
> stands
> > still - suppose it is Y2019, how is user going to migrate his database
> > containing 20-30-50-100 tables in a single schema in Oracle to Ignite?
> >
> > Single cache for all tables? Doens't work - not flexible. Users will
> > definitely require different cache modes, different co-location rules,
> > different number of backups, etc..
> > Schema per table? Doesn't work either - unmanageable and not convenient
> > for users even for relatively small databases.
> >
> > From user perspective schema is logical grouping of database objects,
> > nothing more.
> >
> > For Ignite schema could be a logical group of resources (nodes, memory
> > pools, caches, etc.). And multiple tables over multiple caches should
> > reside in it. To the contrast, table definition governs how data is
> stored.
> > This is similar to, for example, MySQL approach, where you define how you
> > store data on per-table level, and on schema level you define only minor
> > things like collation.
> >
> > Vladimir.
> >
> >
> > On Fri, Jan 13, 2017 at 10:33 AM, Alexander Paschenko <
> > alexander.a.pasche...@gmail.com> wrote:
> >
> >> Vova,
> >>
> >> 2017-01-13 4:56 GMT+08:00 Vladimir Ozerov <voze...@gridgain.com>:
> >> > I am not quite sure I understand the idea of "SCHEMA == cache".
> Consider
> >> > some small database with, say, ~30 tables. And user wants to migrate
> to
> >> > Ignite. How is he supposed to do so? 30 schemas leading to rewrite of
> >> all
> >> > his SQL scripts? Or 30 key-value pairs in a single cache leading to
> >> lack of
> >> > flexibility and performance problems?
> >>
> >> But currently schema *is* semantically equal to cache while table is
> >> equal to type descriptor (i.e. type of stored entities), nothing new
> >> here.
> >>
> >> Say, in single cache we may have entities of types Person and
> >> Organization, those map to two tables with same names, and can be
> >> accessed within the same cache (i.e. schema).
> >>
> >> If we want to limit the user with having single type descriptor per
> >> cache (i.e. cache has only one type of stored entities - BTW, where we
> >> are with this 2.0-wise?), then this notion could change. But currently
> >> what has been suggested already fits quite good with what we do have
> >> at the moment regarding semantic of SQL objects.
> >>
> >> - Alex
> >>
> >> > Another example is how to deal with referene tables? Lots database has
> >> > small reference tables which is best to fit REPLICATED cache, while
> >> others
> >> > are usually bound to PARTITIONED mode. "SCHEMA == cache" will force
> >> users
> >> > to split them into separate schemes leading to poor user experience.
> >> >
> >> > I understand that we may have some implementation details around it at
> >> the
> >> > moment. But from user perspective "SCHEMA == cache" doesn't make
> sense.
> >> As
> >> > we are going towards AI 2.0 we'd better to rethink this approach.
> >> >
> >> > On Thu, Jan 12, 2017 at 11:46 PM, Denis Magda <dma...@apache.org>
> >> wrote:
> >> >
> >> >>
> >> >> > On Jan 12, 2017, at 12:35 PM, Dmitriy Setrakyan <
> >> dsetrak...@apache.org>
> >> >> wrote:
> >> >> >
> >> >> > On Thu, Jan 12, 2017 at 9:47 AM, Sergi Vladykin <
> >> >> sergi.vlady...@gmail.com>
> >> >> > wrote:
> >> >> >
> >> >> >> The xml config was only for example. We can put in this
> >> configuration
> >> >> >> string cache config parameters directly like this:
> >> >> >>
> >> >> >> CREATE SCHEMA "MyCacheName" WITH
> >> >> >> "cacheMode=REPLICATED;atomicityMode=ATOMIC"
> >> >> >>
> >> >> >
> >> >> > This approach makes sense, if it can be easily supported with H2.
> >> >>
> >> >> What’s for affinity keys? Can we make an exception for them by
> >> defining in
> >> >> this part of the statement
> >> >>
> >> >> CREATE TABLE employee (
> >> >>    id BIGINT PRIMARY KEY,
> >> >>    dept_id BIGINT AFFINITY KEY,
> >> >>    name VARCHAR(128),
> >> >> );
> >> >>
> >> >> or that l
> >> >>
> >> >> CREATE TABLE employee (
> >> >>    id BIGINT PRIMARY KEY,
> >> >>    dept_id BIGINT,
> >> >>    name VARCHAR(128),
> >> >>    CONSTRAINT affKey AFFINITY KEY(dept_id)
> >> >> );
> >> >>
> >> >> ?
> >> >>
> >> >> —
> >> >> Denis
> >> >>
> >> >>
> >>
> >
> >
>

Reply via email to