Derby for multi-tenancy environment

[Yi Fan <he...@gmail.com>]

Hi,

I am Yifan. I am a member of a database research group in TUM
(Technical University of Munich, Germany).
What we are interested in is how database performance in a
multi-tenancy environment. We have chose Derby
as our database and want to add or modify features for Derby to fit
our research.

What I am now focus on is how new schema and tables are created and
kept on the hard disk and how Derby load them into
memory when the database boots up.

I have the source on my hand, but it is hard to have a start.
Can someone give me a hint?

Thanks!
Yifan

Re: 答复: Derby for multi-tenancy environment

[Bryan Pendleton <bp...@amberpoint.com>]

Yifan Wang wrote:
> 	Generally, Multi-tenancy means "many customers reside on one
> database".
> They can share the same database instance or even share the same table.

Hi Yifan, thanks for sending the links on Multi-Tenant architecture.

>From what I read, Derby is an excellent candidate for this type
of usage:
 - the Derby engine can support multiple databases simultaneously,
   so if you want to place each tenant in its own DB, no problem.
 - the Derby engine fully supports schemas, so if you want to
   place each tenant in its own schema, no problem
 - you can include a tenant id in each table, if you choose that
   design, should be no problem
 - you can dynamically alter table definitions, so as tenants
   choose different features, you can change the table definition.
   Some ALTER TABLE features were present in 10.1, more were added
   in 10.2, and more still have been added to the trunk.

Overall, it seems that Derby would be a fine choice.

Please let us know your experiences with Derby in this area.

thanks,

bryan

答复: Derby for multi-tenancy environment

[Yifan Wang <he...@gmail.com>]

Hi,
	Generally, Multi-tenancy means "many customers reside on one
database".
They can share the same database instance or even share the same table.
Here are some links to this topic:

Multi-tenant database design:
http://discuss.joelonsoftware.com/default.asp?design.4.319460.16

Multi-Tenant Data Architecture:
http://msdn2.microsoft.com/en-us/library/aa479086.aspx

Thanks
Yifan

-----邮件原件-----
发件人: Bryan Pendleton [mailto:bpendleton@amberpoint.com] 
发送时间: 2007年1月29日 16:30
收件人: derby-dev@db.apache.org
主题: Re: Derby for multi-tenancy environment

> What we are interested in is how database performance in a
> multi-tenancy environment.

What is a multi-tenancy environment? Can you give some background
pointers?

> What I am now focus on is how new schema and tables are created and
> kept on the hard disk and how Derby load them into
> memory when the database boots up.

Each table is a separate operating system file, called a "conglomerate"
in the Derby internals. Indexes are also separate conglomerates.

Information about the schema is kept in a master set of system
catalogs, which are documented in the derby docs.

Tables and indexes are created with CREATE TABLE and CREATE INDEX
statements.

Tables are not loaded into memory when the database boots, but rather
are opened on demand when referenced by a user's SQL (excepting the
special case of database recovery, which does access the tables at boot).

thanks,

bryan

Re: Derby for multi-tenancy environment

[Bryan Pendleton <bp...@amberpoint.com>]

> What we are interested in is how database performance in a
> multi-tenancy environment.

What is a multi-tenancy environment? Can you give some background
pointers?

> What I am now focus on is how new schema and tables are created and
> kept on the hard disk and how Derby load them into
> memory when the database boots up.

Each table is a separate operating system file, called a "conglomerate"
in the Derby internals. Indexes are also separate conglomerates.

Information about the schema is kept in a master set of system
catalogs, which are documented in the derby docs.

Tables and indexes are created with CREATE TABLE and CREATE INDEX statements.

Tables are not loaded into memory when the database boots, but rather
are opened on demand when referenced by a user's SQL (excepting the
special case of database recovery, which does access the tables at boot).

thanks,

bryan