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