"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