The Force.com Multitenant Architecture

最近为了解决一技术问题，使用了Force.com Multitenant Architecture，在此详细说明下Force.com 的架构，具体的白皮书可以从下面的URL获取：(http://wiki.developerforce.com/index.php/Multi_Tenant_Architecture)。
   
Force.com Multitenant 架构的最大亮点在于，将数据索引化,一个存储数据的表，一个用于索引数据的表，再加上一系列存储元数据的表；每次的业务数据的查询首先查找元数据表，然后再改写成具体的查询语句到具体的数据表和索引中进行联合查询，这样SQL语句的执行计划固定，它一定是一个数据表加上一个索引表的join操作，非常适合于OLTP系统，具体的表ER图如下：

上面的说明比较抽象，下面举个具体事例来说明相关技术。假设我们需要根据用户的firstname和lastname来获取某个用户的详细信息，通过Force.com Multitenant 架构，我们如何去做呢？

首先，我们定义元数据信息使用的表。
create table mt_tables
(
 tabid        int(9) not null,
 orgid        int(9) not null,
 tabname      varchar(30) not null,
 primary key(tabid)
) ENGINE=InnoDB  CHARSET=utf8;

create table mt_fields
(
 fieldid      int(9)  not null,
 orgid        int(9)  not null,
 tabid        int(9)  not null,
 fieldname    varchar(128) not null,
 fieldtype    varchar(128) not null,
 fieldnum     smallint     not null,
 indextype    char(1)      not null, -- u:unique or primary index,i-index,n-no index
 primary key(fieldid)
) ENGINE=InnoDB  CHARSET=utf8;
create index ind_to_mt_fields
on mt_fields
(tabid,orgid);
create unique index ind_uname_mt_tables
on mt_tables
(tabname,orgid);

其次，我们定义存储具体数据需要的表、建立查询索引需要的表和建立数据关系表。

create table mt_data
(
 guid         varchar(36)  not null, -- yyyymmdd+0000000001-9999999999
 orgid        int(9)       not null,
 tabid        int(9)       not null,
 name         varchar(128) not null,
 IsDeleted    char(1)      not null,
 value0       varchar(1000),
 ...
 value20      varchar(1000),
 primary key(guid,orgid)
) ENGINE=InnoDB  CHARSET=utf8;

create table mt_clobs
(
 guid         varchar(36)  not null, -- yyyymmdd+0000000001-9999999999,refer to mt_data.guid
 orgid        int(9)       not null,
 tabid        int(9)       not null,
 value0       text,
 ...
 value10      text,
 primary key(guid,orgid)
)ENGINE=InnoDB  CHARSET=utf8;

create table mt_indexes
(
   guid         varchar(36)  not null, -- yyyymmdd+0000000001-9999999999,refer to mt_data.guid
   orgid        int(9)       not null,
   tabid        int(9)       not null,
   fieldnum     smallint     not null,
   stringvalue  varchar(250),
   numvalue     varchar(40),
   datevalue    varchar(40),
   primary key(guid,orgid,tabid,fieldnum)
)ENGINE=InnoDB  CHARSET=utf8;
create index  ind_string_mt_indexes
on mt_indexes
(stringvalue,tabid,fieldnum);
create index  ind_date_mt_indexes
on mt_indexes
(datevalue,tabid,fieldnum);
create index  ind_num_mt_indexes
on mt_indexes
(numvalue,tabid,fieldnum);

create table  mt_unique_indexes
(
   guid         varchar(36)  not null, -- yyyymmdd+0000000001-9999999999,refer to mt_data.guid
   orgid        int(9)       not null,
   tabid        int(9)       not null,
   fieldnum     smallint     not null,
   stringvalue  varchar(224),
   numvalue     varchar(40),
   datevalue    varchar(40),
   primary key(guid,orgid,tabid,fieldnum)
)ENGINE=InnoDB  CHARSET=utf8;

create unique index uk_string_mt_unique_indexes
on mt_unique_indexes
(stringvalue,tabid,fieldnum);

create unique index uk_date_mt_unique_indexes
on mt_unique_indexes
(datevalue,tabid,fieldnum);

create unique index ind_num_mt_unique_indexes
on mt_unique_indexes
(numvalue,tabid,fieldnum);

create table  mt_relationships
(
   relationid   varchar(36)  not null, -- yyyymmdd+0000000001-9999999999 
   guid         varchar(36)  not null, -- yyyymmdd+0000000001-9999999999,refer to mt_data.guid
   orgid        int(9)       not null,
   tabid        int(9)       not null,
   targetTabid  int(9)       not null,
   primary key(relationid,orgid,tabid,targetTabid)
)ENGINE=InnoDB  CHARSET=utf8;

第三步，我们开始建立元数据与存储数据的关系，插入的数据为用户表数据，此时的用户表是一个逻辑上的表，存在于mt_tables中。

insert into mt_tables(tabid,orgid,tabname,createtime,modifytime)
values(1,1,'USER',sysdate(),sysdate());
commit;
set @tablid=1;
insert into mt_fields(fieldid,orgid,tabid,fieldname,fieldtype,fieldnum,indextype,createtime,modifytime)
values
(1,1,@tablid,'USERID','VARCHAR',0,'u',sysdate(),sysdate());

insert into mt_fields(fieldid,orgid,tabid,fieldname,fieldtype,fieldnum,indextype,createtime,modifytime)
values
(2,1,@tablid,'USERNAME','VARCHAR',1,'i',sysdate(),sysdate());
....
insert into mt_fields(fieldid,orgid,tabid,fieldname,fieldtype,fieldnum,indextype,createtime,modifytime)
values
(5,1,@tablid,'FIRST_NAME','VARCHAR',4,'n',sysdate(),sysdate());
...
insert into mt_fields(fieldid,orgid,tabid,fieldname,fieldtype,fieldnum,indextype,createtime,modifytime)
values
(7,1,@tablid,'LAST_NAME','VARCHAR',6,'n',sysdate(),sysdate());
commit;

第四步，在应用程序创建用户数据的时候根据元数据表信息，建立mt_data，mt_clobs，mt_indexes等相关表的关系数据。


最后，我们看下如何根据firstname和lastname获取用户的信息，SQL语句如下:

SELECT b.value0,value1,value2,value3,value4,value5,value6
           FROM mt_data b,
                (SELECT guid, orgid
                   FROM mt_indexes a
                  WHERE a.stringvalue = 'philip'
                    AND a.tabid = 1
                    AND a.fieldnum = 4
     ) c
          WHERE c.guid = b.guid
            AND c.orgid = b.orgid
            AND value6 = 'zhong'

整套架构的优点：

类似与oracle的数据字典+索引的机制，实现了一套通用的数据查询体制，与类似的行存储列方式的通用解决方案，数据的冗余程度很小，数据量也不会成倍增加，加上上层orgid的sharding，单个schema存储的数据量将不会很大，也能满足web应用的可扩展性，适用于MYSQL数据库，SQL执行计划非常固定。

缺点：
所有的SQL查询将是固定模式的join查询，但如果本身应用涉及的表join过多，那么查询的速度将下降，可以通过表的冗余措施降低表的jion复杂度。此外唯一性数据的查询速度有所降低。

下面是针对该架构在mysql5.1.55上进行的一些性能测试数据：
Case 1:
      MYSQL------ mt_data records= 9000415 ,
                              mt_index records =9000415,
Case 2:
      MYSQL------ mt_data records= 5000415,
                              mt_index records =5000415
Case 3:
      MYSQL------ mt_data records= 1000305,
                              mt_index1 records =1000305
Case 4:
      MYSQL------ mt_data records= 36630,
                              mt_index1 records =36630

Case name	MYSQL force.com SQL query
Case 1	55 ms
Case 2	40 ms
Case 3	42 ms
Case 4	38 ms