Account

wwwdb.inf.tu.dresden.de

Account

Webscale Data Management

11 Mul5-­‐tenancy

© Prof. Dr.-­‐Ing. Wolfgang Lehner |


Web-­‐scale Data Management

Big Data

PBs of data, 10 2 -­‐10 5 nodes

Opera7onal

High qps, a few rows/op

e.g., BigTable, Dynamo, PNUTS

Analy7c

Low qps, billions of rows/op

(MapReduce, Hadoop, Dryad)

Interac7ve Scripted

(Dremel) (PigLa5n, Sawzall)

Virtualiza7on

(Scalability)

Mul7-­‐Tenancy

Map N logical systems into 1

physical system

[S. Melnik: The Fron5ers of Data Programmability, BTW 2009]

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 2


What is Mul7-­‐tenancy

Mul$-­‐tenancy refers to the ability

§ To run mul7ple customers on a single soEware instance installed on mul5ple

servers

§ This is done to increase resource u7liza7on by allowing load balancing among

tenants, and to

§ Reduce opera7onal complexity and cost in managing the soYware to deliver the

service

From a customer’s perspec$ve

§ Mul5-­‐tenancy is transparent à customer seems to have an instance of the soYware

en5rely to themselves

§ Customiza7on can be employed to the degree the applica5on supports it without

regard to what other tenants are doing

Bob Warfield, SmoothSpan Blog 27th October 2007,

h]p://smoothspan.wordpress.com/2007/10/28/mul5tenancy-­‐can-­‐havea-­‐161-­‐cost-­‐advantage-­‐over-­‐single-­‐tenant/

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 3


What is Mul7-­‐tenancy (2)

Consolidate mul$ple businesses (tenants) onto the same opera$onal system

Pool resources to improve their u$liza$on

§ Avoid provisioning each tenant for their maximum load

§ Breaks down isola5on: weakens security, increases resource conten5on, interferes

with op5miza5ons

Provide a tenant-­‐aware administra$ve framework to improve management

efficiency

§ Manage farms of individual mul5-­‐tenant servers

§ Support bulk opera5ons such as rolling upgrade

§ Support tenant migra5on within and across farms

In this lecture: Focus on schemas and queries

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 4


Mul7-­‐tenancy – literally

Mul$ple clients hosted by one service provider

§ Mul5ple tenants hosted in one building complex

Code (to be executed)

§ U5li5es (gas, electric, water, waste)

Data (with services)

§ Storage space (furniture, basement, garage)

Four models…

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 5


Single homes

Different spaces, same 7me

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 6


Private Apartments

Different spaces, same 7me, shared services

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 7


Hotel Rooms

Same space, different 7mes

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 8


Youth Hostel

Same space, same 7me

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 9


Cost & Performance

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 10


Isola7on: Make other tenants invisible

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 11


Make other tenants invisible

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 12


Trust & Security

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 13


Reminder

Private Hardware Private VM/OS Private Instance Private DB Private Schema Mul5-­‐

tenancy

Schema

Layer

DB

Layer

DBS

Layer

VM

Layer

OS OS VM VM OS OS OS OS

HW

Layer

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 14


Reminder (2)

Private DB Private Schema Mul5-­‐

tenancy

Schema

Layer

DB

Layer

DBS

Layer

VM

Layer

OS OS OS

HW

Layer

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 15


Mul7tenancy Trade-­‐offs

Private Databases Private Schema Mul5-­‐tenancy

Simplicity simple simple (but need naming

and mapping schemes)

Customizability

(schema)

hard

high high low

Isola5on best moderate lowest

Resource Cost/

tenant

high low lowest

#Tenants low large largest

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 16


Mul7tenancy Trade-­‐offs (2)

Tools

DB

implementa5on

cost

Private Databases Private Schema Mul5-­‐tenancy

Tools to deal with

large number of DBs

Lowest (query rou5ng

and simple mapping

layer)

Tools to deal with large

number of tables

Low (query rou5ng,

simple mapping layer and

query mapping)

n/a

High (query rou5ng,

simple mapping layer,

query mapping, row-­‐level

isola5on)

Scalability Per tenant Need some data/load

balancing with dynamic

migra5on

Query

Op5miza5on

Per Tenant Query

Performance

Need some data/load

balancing with dynamic

migra5on

Less cri5cal Less cri5cal Cri5cal (wrong plan over

very large tables is

disastrous)

As usual Need query governance Need query governance

and tenant-­‐specific

sta5s5cs

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 17


Mul7-­‐Tenancy in Prac7ce

Aulbach et al.: Mul5-­‐Tenant Databases for SoYware as a Service:

Schema-­‐Mapping Techniques, SIGMOD 2008.

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 18


Shared Machine / Private database

§ Each customer gets his own database

§ Main-­‐Memory requirements for one database with one empty CRM schema

instance

PostgreSQL MaxDB System X System Y System Z

55 MB 80 MB 171 MB 74 MB 273 MB

§ Cannot scale beyond tens of tenants per server (à2007)

§ Appropriate for applica5ons with a smaller number of larger tenants, e.g., for

banking

Jacobs, Dean and Aulbach, Stefan: Rumina5ons on Mul5-­‐Tenant Databases, BTW 2007

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 19


Shared Process / Private schema

§ Each customer gets their own tables within the same instance

§ Main-­‐Memory requirements for one database with 10,000 empty CRM

schema instances

PostgreSQL MaxDB System X System Y System Z

79 MB 80 MB 616 MB 2061 MB 359 MB

55 MB 80 MB 171 MB 74 MB 273 MB

§ Should scale up to thousands of tenants

§ If each tenant gets their own table space, migra5on entails simply moving files

§ Connec5on pooling is possible, but then tenant iden5ty must be managed by

the applica5on

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 20


Shared Table / Mul7-­‐tenancy

Data from many tenants in the same tables

§ Add a tenant_id column

§ Tenant queries must fix the value for this column

§ By connec5on or by applica5on

Extend base schema using generic columns

§ May be VARCHAR or a mix of types

§ The database must compactly represent sparse tables

Advantage -­‐ everything is pooled

§ Processes, memory, connec5ons, prepared statements

§ Easy DML and DDL opera5ons across tenants

§ Add, remove, and extend tenants with DML (not DDL)

Disadvantage -­‐ Isola$on is very weak

§ Irrelevant data infects query processing

§ Op5miza5on sta5s5cs

§ Table scans

§ Data locality

§ No indexes or integrity constraints on generic columns

§ Migra5on requires querying the opera5onal system

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 21


Schema mappings

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 22


Schema Mapping Techniques

Database owns the schema, evolu$on of logical schemas requires on-­‐line DDL

1. Basic Tables

2. Private Tables

2. Extension Tables

4. Sparse Columns

Applica$on owns the schema, the applica$on controls evolu$on of logical

schemas

5. XML

6. Universal Tables

7. Pivot Tables

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 23


1. Basic Table Layout

One table for all tenants

§ Usage of a tenant id to iden5fy the data

§ Easy to implement

§ Low storage footprint

But

§ No tenant specific extensions possible!!

Tenant 17

SELECT Name

FROM Account

SELECT Name

FROM Account

WHERE Tenant = 17

Account

Tenant Aid Name

17 1 Acme

17 2 Gump

35 1 Ball

42 1 Big

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 24


2. Private Tables

Give each tenant their own private tables

§ Easy to extend

§ SQL transforma5on: Renaming only

Great performance un$l the number of tables gets too high

§ Schema overhead: 4 KB/table * 100,000 tables = 400 MB

§ Index pages are only partly full and are hard to keep in memory

Used if the schema is small and there are few tenants

Account 17

Aid Name Hospital Beds

1 Acme St. Mary 135

2 Gump State 1042

Healthcare Extension

Account_42

Aid Name Dealers

1 Big 65

Automo5ve Extension

Account_35

Aid

Name

1 Ball

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 25


2. Private Tables – Query

Transforma7on

Tenant 17

SELECT Beds FROM Account

WHERE Hospital = `State`

SELECT Beds FROM Account_17

WHERE Hospital = `State`

Account_17

Aid Name Hospital Beds

1 Acme St. Mary 135

2 Gump State 1042

Tenant 42

SELECT Name FROM Account

WHERE Dealers > 50

Account_42

Aid Name Dealers

1 Big 65

SELECT Name FROM Account_42

WHERE Dealers > 50

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 26


3. Extension Tables

Give each extension its own table

§ Add a row column and join to reassemble rows

§ Horizontal par55oning

§ Give all tables a tenant column and share tables

Addi$onal join at run$me

BeWer consolida$on than Private Table layout

§ But: Number of tables s5ll grows in propor5on to number of tenants

Healthcare

Account Account

Ext

Tenant Row Hospital Beds

Tenant Row Account Name

17 0 St Mary 135

17 0 1 Acme

17 1 State 1042

17 1 2 Gump

35 0 1 Ball Automo7vate Account

42 0 1 Big

Tenant Row Dealers

42 0 65

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 27


3. Extension Tables – Query Transforma7on

Tenant 17

SELECT Name, Beds

FROM Account

WHERE Hospital = `State`

SELECT A.Name, H.Beds

FROM Account A, Account_HealthCare H

WHERE A.Tenant = 17

AND H.Tenant = 17

AND A.Row = H.Row

AND H.Hospital = `State`

Account Ext

Tenant Row Account Name

17 0 1 Acme

17 1 2 Gump

35 0 1 Ball

42 0 1 Big

Healthcare Account

Tenant Row Hospital Beds

17 0 St Mary 135

17 1 State 1042

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 28


4. Sparse Columns

Designed to handle data such as parts catalogs where each item has only a few

out of thousands of possible aWributes

Interpreted storage format to handle null values

§ Fields in a row are stored along with their column iden5fiers

§ Only available in MicrosoY SQL Server (others)

§ Limited number of sparse columns per table are permi]ed

Extension fields added as sparse columns to each table

Database owns the schema: evolu$on requires on-­‐line DDL

Account

Tenant Account Name SPARSE

17 1 Acme 0:St Mary, 1:135

17 2 Gump 0:State, 1:1042

35 1 Ball

42 1 Big 0:65

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 29


4. Sparse Columns – Query Transforma7on

CREATE TABLE Account (

Tenant INT,

Account INT,

Name VARCHAR(100),

Hospital VARCHAR(100) SPARSE,

Beds INT SPARSE,

Dealer INT SPARSE )

Tenant 17

SELECT Name, Beds

FROM Account

WHERE Hospital = `State`

SELECT Name, Beds

FROM Account

WHERE Tenant = 17

AND Hospital = `State`

Account

Tenant Account Name SPARSE

17 1 Acme 0:St Mary, 1:135

17 2 Gump 0:State, 1:1042

35 1 Ball

42 1 Big 0:65

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 30


5. XML

Each base table is given an addi$onal column that stores all extension fields in

one (flat) XML document

§ Applica5on owns the schema for extension fields so they can be evolved without on-­line

DDL

§ E.g. IBM‘s pureXML

Tenant Account Name XMLData

17 1 Acme

St Mary

135


17 2 Gump

State

1024


35 1 Ball -­‐

42 1 Big 65

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 31


5. XML Tables – Query Transforma7on

Tenant 17

SELECT Name, Beds

FROM Account

WHERE Hospital = `State`

SELECT Name, xml…([data/bed])

FROM Account

WHERE Tenant = 17

AND xmlexists('$x[data/hospital=`State`]'

PASSING XMLData AS „x“ );

Tenant Account Name XMLData

17 1 Acme

St Mary

135


17 2 Gump

State

1024


35 1 Ball -­‐

42 1 Big 65

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 32


6. Universal Tables

Pack data into wide tables with generic VARCHAR columns

§ n-­‐th column of each logical source table for each tenant is mapped into the n-­‐th data

column of the Universal Table àno need to reconstruct source table

§ Not type-­‐safe à cas5ng necessary

§ Very wide rows à many NULL values

§ No index support

Used if the schema is large or there are many tenants

salesforce.com does this and makes it work (fast) by rebuilding indexing and

query op$miza$on

Universe

Tenant Table Col1 Col2 Col3 Col4 … Col500

17 0 1 Acme St Mary 135 -­‐

17 0 2 Gump State 1042 -­‐

35 1 1 Ball -­‐ -­‐ -­‐

42 2 1 Big 65 -­‐ -­‐

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 33


6. Universal Tables – Query Transforma7on

Tenant 17

SELECT Name, Beds

FROM Account

WHERE Hospital = `State`

SELECT Col2, Col4

FROM Universe

WHERE Tenant = 17

AND Table = 0

AND CAST(Col3 AS VARCHAR)= `State`

Universe

Tenant Table Col1 Col2 Col3 Col4 … Col500

17 0 1 Acme St Mary 135 -­‐

17 0 2 Gump State 1042 -­‐

35 1 1 Ball -­‐ -­‐ -­‐

42 2 1 Big 65 -­‐ -­‐

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 34


7. Pivot Tables

Pack data into 3-­‐ary tables with column_ids and values

§ Each field of a row in logical table is given its own row

§ Mul5ple pivot tables for each type (int, string, e.g.)

§ Eliminates handling many NULL values

§ Can solve the typing and indexing problem

But logical table with n columns necessitates (n-­‐1) joins

Pivot_Int

Tenant Table Row Col Int

17 0 0 0 1

17 0 0 3 135

17 0 1 0 2

17 0 1 3 1042

35 1 0 0 1

42 2 0 0 1

42 2 0 2 65

Pivot_String

Tenant Table Row Col String

17 0 0 1 Acme

17 0 0 2 St Mary

17 0 1 1 Gump

17 0 1 2 State

35 0 0 1 Ball

42 1 0 1 Big

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 35


7. Pivot Tables – Examples

Account 17

Aid Name Hospital Beds

1 Acme St. Mary 135

2 Gump State 1042

Pivot_Int

Tenant Table Row Col Int

17 0 0 0 1

17 0 0 3 135

17 0 1 0 2

17 0 1 3 1042

35 1 0 0 1

42 2 0 0 1

42 2 0 2 65

Account_42

Aid Name Dealers

1 Big 65

Account_35

Aid Name

1 Ball

Pivot_String

Tenant Table Row Col String

17 0 0 1 Acme

17 0 0 2 St Mary

17 0 1 1 Gump

17 0 1 2 State

35 1 0 1 Ball

42 2 0 1 Big

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 36


7. Pivot Tables – Query Transforma7on

Reminder: Mapper knows Tenant_Id,

Table_Id, and Column_Id

Tenant 17

SELECT Beds

FROM Account

WHERE Hospital = `State`

SELECT I.Int

FROM Pivot_Int I,

Pivot_String S

WHERE I.Tenant = 17

AND S.Tenant = 17

AND S.Table = 0

AND S.Col = 2

AND I.Table = 0

AND I.Col = 3

AND S.String = `State`

AND I.Row = S.Row

Tenant Table Row Col Int

17 0 0 0 1

17 0 0 3 135

17 0 1 0 2

17 0 1 3 1042

35 1 0 0 1

42 2 0 0 1

42 2 0 2 65

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 37

Pivot_Int

Pivot_String

Tenant Table Row Col String

17 0 0 1 Acme

17 0 0 2 St Mary

17 0 1 1 Gump

17 0 1 2 State

35 0 0 1 Ball

42 1 0 1 Big


7. Pivot Tables – Query Transforma7on (2)

Tenant 17

SELECT Name, Beds

FROM Account

WHERE Hospital = `State`

SELECT S1.String, I.Int

FROM Pivot_Int I,

Pivot_String S1,

Pivot_String S2

WHERE I.Tenant = 17

AND S1.Tenant = 17

AND S2.Tenant = 17

AND S1.Table = 0 AND S1.Col = 1

AND S2.Table = 0 AND S2.Col = 2

AND I.Table = 0 AND I.Col = 3

AND I.Row = S1.Row

AND I.Row = S2.Row

AND S2.String = `State`

Tenant Table Row Col Int

17 0 0 0 1

17 0 0 3 135

17 0 1 0 2

17 0 1 3 1042

35 1 0 0 1

42 2 0 0 1

42 2 0 2 65

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 38

Pivot_Int

Pivot_String

Tenant Table Row Col String

17 0 0 1 Acme

17 0 0 2 St Mary

17 0 1 1 Gump

17 0 1 2 State

35 0 0 1 Ball

42 1 0 1 Big


Google BigTable

Same basic idea as Pivot Tables

Columns are grouped into column families

Column families

§ Must be explicitly defined (owned by the database)

§ There should not be more than a few hundred in a table and they should rarely

change during opera5on

§ Each has an expected type (although all values are stored as strings)

Columns

§ May be created on-­‐the-­‐fly (owned by the applica5on)

§ May be an unbounded number of them

Data in a column family is compressed and stored together

§ Column family = Pivot Table

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 39


Google BigTable (2)

§ Data can be clustered together only

if it is in the same BigTable instance

§ All logical tables for a tenant must

be packed into the same BigTable

instance

§ Mapping here: One column family

per logical table

§ Here: Just one logical table

BigTable

Tenant Table Row Account

17 Acct 0 Id, 1

17 Acct 0 Name, Acme

17 Acct 0 Hospital, St Mary

17 Acct 0 Beds, 135

17 Acct 1 Id, 2

17 Acct 1 Name, Gump

17 Acct 1 Hospital, State

17 Acct 1 Beds, 1042

35 Acct 0 Id, 1

35 Acct 0 Name, Ball

42 Acct 0 Id, 1

42 Acct 0 Name, Big

42 Acct 0 Dealers, 65

Column Family

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 40


Chunk Tables

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 41


Reminder: Pivot Table

Generic type-­‐safe structure

§ Each field of a row in logical table is

given its own row

§ Mul5ple pivot tables for each type

(int, string, e.g.)

§ Eliminates handling many NULL

values

Performance

§ Depends on the column selec5vity

of the query (number of

reconstruc5ng joins)

Pivot_Int

Tenant Table Row Col Int

17 0 0 0 1

17 0 0 3 135

17 0 1 0 2

17 0 1 3 1042

35 1 0 0 1

42 2 0 0 1

42 2 0 2 65

Tenant Table Row Col String

17 0 0 1 Acme

Account 17

Aid Name Hospital Beds

1 Acme St. Mary 135

2 Gump State 1042

17 0 0 2 St Mary

17 0 1 1 Gump

17 0 1 2 State

35 0 0 1 Ball

42 1 0 1 Big

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 42

Pivot_String


Row Fragmenta7on

Possible solu$on for addressing table u$liza$on issues

§ Various storage techniques for individual fragments

§ Hunt for densely populated tables

Idea: Split rows according to their “popularity”

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 43


Chunk Table

Generic structure

§ Suitable if dataset can be par55oned

into dense subsets

§ Derived from Pivot table

§ Middle ground between Universal

table and Pivot table

Performance

§ Fewer joins for reconstruc5on if

densely populated subsets can be

extracted

§ Indexable

§ Reduced meta-­‐data/data ra5o

dependant on chunk size

Chunk Int|Str

Account_17

Aid Name Hospital Beds

1 Acme St. Mary 135

2 Gump State 1042

Tenant Table Chunk Row Int1 Str1

17 0 0 0 1 Acme

17 0 1 0 135 St Mary

17 0 0 1 2 Gump

17 0 1 1 1042 State

35 1 0 0 1 Ball

42 2 0 0 1 Big

42 2 1 0 65 -­‐

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 44


Further Enhancement: Chunk Folding

Combine different schema mappings

for best fit

§ Mixes Extension and Chunk Tables

§ Each fragment can be stored in an

op5mal schema layout

Op$mal chunk folding depends on

§ Workload

§ Data distribu5on

§ Data popularity

Account_17

Aid Name Hospital Beds

1 Acme St. Mary 135

2 Gump State 1042

Account_42

Account_35

Aid Name Dealers Aid Name

1 Big 65 1 Ball

Account Row Chunk Row

Tenant Row Aid Name Tenant Table Chunk Row Int1 Str1

17 0 1 Acme

17 1 2 Gump

35 0 1 Ball

42 0 1 Big

17 0 0 0 135 St

Mary

17 0 0 1 1042 State

42 2 0 0 65 -­‐

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 45


Querying Chunk Tables

Query Transforma$on

§ Row reconstruc5on needs many self-­‐ and equi-­‐joins

§ Can be automa5cally translated

Compila$on Scheme

1. Collect all table names and their corresponding columns from the logical source

query

2. For each table, obtain the Chunk Tables and the meta-­‐data iden5fiers

represen5ng the used columns

3. For each table, generate a query that filters the correct columns (based on the

meta-­‐data iden5fiers) and aligns the different chunk rela5ons on their ROW

column.

4. Each table reference in the logical source query is extended by its generated

table defini5on query

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 46


Example queries

Tenant 17

SELECT Beds

FROM Account

WHERE Hospital = `State`

Replace Account Table with sub-­‐

select with Chunk table

Luck: Both relevant aWributes

are in same chunk

Chunk Int|Str

Tenant Table Chunk Row Int1 Str1

17 0 0 0 1 Acme

17 0 1 0 135 St Mary

17 0 0 1 2 Gump

17 0 1 1 1042 State

35 1 0 0 1 Ball

42 2 0 0 1 Big

42 2 1 0 65 -­‐

SELECT Beds

FROM (

SELECT Str1 AS Hospital, Int1 AS Beds

FROM Chunkint|str

WHERE Tenant = 17 AND Table = 0 AND Chunk = 1

) AS Account

WHERE Hospital = `State`

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 47


Comparison of Schema Mapping Techniques

Isola7on Consolida7on Extensibility

Transfor-­ma7on

effort

Basic Tables + ++ -­‐-­‐ ++

Private Tables ++ -­‐-­‐ O ++

Extension Tables + ++ ++ O

Universal Tables O O O -­‐

Others

Not

extendable

High storage

footprint

High storage

footprint (*)

Many null

values, no

indexing, not

type-­‐safe

Pivot Tables O O ++ -­‐ Many joins

Chunk Tables O O ++ O Only one table

Chunk Folding O + ++ O Good mix

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 48


Problems so far…

Problems in Implemen$ng Mul$-­‐Tenancy

§ Resource conten5on among tenants

§ Resource governing to ensure fairness is difficult to implement

§ But malicious and inadvertently bad requests must be shut down

§ Common prac5ce is simply to forego opera5ons whose resource usage can’t be

bounded in advance SLAs

§ Access control among tenants

§ May have to rely on the applica5on or mapping algorithms rather than the

database

§ Moving data for an individual tenant

§ For archiving and load balancing

§ Tuple-­‐at-­‐a-­‐5me opera5ons are slow and resource intensive

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 49


Summary

§ Different forms of scaling: up, out, in

§ Economy of scale by re-­‐using processes: Mutliple tenants on single database

instance

§ Problem: Isola5on

§ Separate tenants by mapping many logical schemata to single physical

schema

§ Many schema mappings techniques

§ Problem: Query transforma5on

© Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 50

More magazines by this user
Similar magazines