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