Hi Vladimir, How do you see a default tablespace configuration in the "bright" future? Is it going to be a single file for an Ignite instance? In what cases will be there benefits to explicitly configure additional tablespaces? By the way was the name "tablespace" hand-crafted or it was it borrowed somewhere? Also if it is TABLEspace should it be aligned with renaming IgniteCache to IgniteTable discussed in [1]?
[1] http://apache-ignite-developers.2346864.n4.nabble.com/Applicability-of-term-cache-to-Apache-Ignite-td36541.html вт, 20 нояб. 2018 г. в 10:57, Dmitriy Setrakyan <dsetrak...@apache.org>: > > I really like the idea. > > On Mon, Nov 19, 2018, 23:45 Vladimir Ozerov <voze...@gridgain.com wrote: > > > Igniters, > > > > We had several discussion about cache groups [1]. Our current consensus is > > that this is not that good design decision - bad scan performance, no API. > > A kind of shortcut to solve memory consumption problems. For this reason we > > try to avoid exposing "cache group" to API when possible. Also we > > understand that current file-per-partition approach is not ideal either - > > when there are too many partitions we have to fsync a lot of files. And as > > an idea for "bright future" we consider tablespaces - one or several files > > where all database objects are stored in dedicated "segments", which are > > allocated in smaller units called "extents". > > > > I was thinking on how to "legalize" cache groups on API on the one hand > > (product needs them currently), and to let real tablespaces to appear in > > future. Idea is simple - treat cache group as special kind of tablespace. > > We may say that current storage organization is one type of tablespace, and > > proposed "file-segment-extent" storage organization is another type of > > tablespace. > > > > With this in mind we can configure tablespaces in IgniteConfiguration, then > > assign each cache a tablespace. As advanced tasks we may allow dynamic > > table space create/alter/drop, I'll show SQL examples below. > > > > // Interface > > interface Tablespace { > > String name(); > > } > > > > // Current non-shared tablespace (aka "physical cache") > > class FilePerPartitionTablespace implements Tablespace { > > // ... > > } > > > > // Shared tablespace (aka "cache group") - note that now we have a legal > > place for cache group configuration: > > class FilePerPartitionSharedTablespace implements Tablespace { > > CacheMode cacheMode; > > CacheAtomicityMode cacheAtomicityMode; > > AffinityFunction affinityFunction; > > // + Other parameters from > > ClusterCachesInfo.validateCacheGroupConfiguration > > // + Some parameters from "DataRegionConfiguration" (e.g. paths) > > } > > > > // Future "real" tablespace > > class SegmentedTablespace implements Tablespace { > > // Whatever is needed. > > } > > > > // Cache configuration > > class CacheConfiguration { > > ... > > String tablespace; > > ... > > } > > > > // Managing tablespaces from SQL: > > CREATE TABLESPACE my_tbs ENGINE=FILE_PER_PARTITION_SHARED > > CACHE_MODE=PARTITIONED BACKUPS=1 > > ALTER TABLESPACE my_tbs ENCRYPTED=1 > > CREATE TABLE my_table (...) TABLESPACE my_tbs > > > > What do you think? > > > > Vladimir. > > > > [1] > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Remove-cache-groups-in-AI-3-0-td29184.html > > -- Best regards, Ivan Pavlukhin
