Tablespace support

[rPraml]

Currently, there is no tablespace support available in ebean.

We want to put certain tables in tablespaces.

To solve this, we plan to add a @DbTablespace annotation, (draft here) so that you can use syntax like:

@DbTablespace("DATA_TBSP")
class MyEntity {
   ...
}
// or to separate also data / index / lobs
@DbTablespace(value = "DATA_TBSP", index="INDEX_TBSP", lob = "LOB_TBSP")
// or use migration-placeholders
@DbTablespace(value = "DATA_${myTenantId}", index="INDEX_${myTenantId}", lob = "LOB_${myTenantId}")

The information of @DbTablespace is stored in DeployBeanDescriptor and then in BeanDescriptor as TablespaceMeta.

When creating the DataModel, it is stored in the MTable. If a Table depends on an other table (e.g. for ElementCollection/Draft/Intersection table), the information from the origin table is transfered. You want to have these tables in the same table space.

The whole information will go in the "model.xml" - we have introduced a new type, the AlterTable - it should be used, if basic things like table space or even storage engine of a table will change.
@rbygrave What do you think about this? Should we add a model, that might be able to handle further migrations or should we focus on one task (=moving the table from one tablespace to an other) Note: it depends on the platform, if that change can be automatically migrated or not.

There's a draft PR https://github.com/FOCONIS/ebean/pull/59/files where we have made a prototype.
We will split up this in smaller ones, so that they are better to review.
We will add the Tablespace functionality first for DB2. Other platforms may follow

[rbygrave]

A couple of note. Way back in the day we used tablespaces to effectively spread IO. Fast forward 20 years and disks, disk controllers, storage, SSD etc ... it's changed and the last conversations I've had in the Oracle space is that tablespaces are not used much (because it is just less relevant wrt IO). I'll look to touch base with an Oracle DBA and see what he says now but yes ... I don't suspect it will get much use.

In terms of DB2, are you doubly sure that this is both good and desirable? ( to split data and indexes etc because it sounds very old school as far as I know).

[rbygrave]

Also, you will actually find some existing tablespace properties on MTable (and maybe the xml definitions too).

[rPraml]

@rbygrave To split indices and data was suggested as possible optimization from the DBAs of one of our customers.

The table spaces are backuped, so at least for me, it sounds like a good idea to have the option to spearate index and the rest of the data as the index data can be restored. In a normal use case, we will specify @Tablespace("${ts1}") and define a ddl.placeholder ts1=TS0007 for the migration run of tenant # 7

/edit: We have multiple tenants, each tenant has its own schema and each schema has it's own table space(s) that are backed up per tenant

[rbygrave]

Yup, that makes sense (regards of the desire to spread IO)

[rbygrave]

Ok @rPraml , I think we can close this one now right?