Could you please elaborate why it will not work this way? Sergi
2017-01-13 12:39 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > Correct, it worked, because Ignite has never had real database use case in > mind. Unfortunately, if our global plans go as expected, it will not work > for Ignite 2.x+. > > On Fri, Jan 13, 2017 at 11:53 AM, Sergi Vladykin <sergi.vlady...@gmail.com > > > wrote: > > > 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 > > > >> >> > > > >> >> > > > >> > > > > > > > > > > > > > >
