标签：
首先，我们应该定义多租户系统中的两个条目：
这是最真实的多租户架构：我们只将具有单个数据库应用的单个实例部署到单个服务器上。在（RDBMS）每个表中，都存在一个TenantId（或相似）字段，该字段用于分离每个租户之间的数据。
这种方法安装和维护都很简单，但唯独创建这么一个应用很难，因为我们必须要阻止一个租户读取或写入其他租户的数据。我们可以为每个数据库的读取（select）操作添加一个TenantId过滤器。而且，我们可以在每次写入的时候检查一下该实体是否和当前的租户相关。这是乏味而易于出错的，但ABP通过使用自动的数据过滤帮助我们处理这个事情。
如果我们有很多具有大量数据的租户，那么这种方法可能会有性能问题。我们可以使用关系型数据库的表分割特征或者将租户按组分到不同的服务器上。
一．水平分割
什么是水平分割？打个比较形象的比喻，在 食堂吃饭的时候，只有一个窗口，排队打饭的队伍太长了，都排成S型了，这时容易让排队的人产生焦虑情绪，容易产生混乱，这时一个管理者站出来，增加多个打 饭窗口，把那条长长的队伍拦腰截断成几队。更形象一点的理解，你拿一把“手术刀”，把一个大表猛的切了几刀，结果这个大表，变成了几个小表.
水平分割根据某些条件将数据放到两个或多 个独立的表中。即按记录进分分割，不同的记录可以分开保存，每个子表的列数相同。水平切割将表分为多个表。每个表包含的列数相同，但是数据行更少。例如， 可以将一个包含十亿行的表水平分区成 12 个表，每个小表表示特定年份内一个月的数据。任何需要特定月份数据的查询只需引用相应月份的表。
通常用来水平分割表的条件有：日期时间维度、地区维度等，当然还有更多的业务维度。下面我举几个例子来解说一下
案例1：某个公司销售记录数据量太大了，我们可以对它按月进行水平分割，每个月的销售记录单独成一张表。
案例2：某个集团在各个地区都有分公司，该集团的订单数据表太大了，我们可以按分公司所在的地区进行水平切割。
案例3：某电信公司的话单按日期、地市水平切割后，发现数据量太大，然后他们又按品牌、号码段进行水平切割
水平分割通常在下面的情况下使用：
（1） 表数据量很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，加快了查询速度。
（2） 表中的数据本来就有独立性，例如表中分别记录各个地区的数据或不同时期的数据，特别是有些数据常用，而另外一些数据不常用。
（3） 需要把数据存放到多个介质上。
（4） 需要把历史数据和当前的数据拆分开。
优点：
1：降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，加快了查询速度。
缺点：
1：水平分割会给应用增加复杂度，它通常在查询时需要多个表名，查询所有数据需要union操作。在许多数据库应用中，这种复杂性会超过它带来的优点，因为只要索引关键字不大，则在索引用于查询时，表中增加两到三倍数据量，查询时也就增加读一个索引层的磁盘次数。
二．垂直分割
什么是垂直分割呢？打个形象的比喻，一个 小公司通过短短几年发展变成了一个跨国大企业，以前的部门架构明显不能满足现在的业务发展，CEO噼里啪啦的把公司分成了财务部、人事部、生产部、销售部 门.....，一下子成立了多个部门，各司其职。这个还算比较形象吧，有木有？呵呵
你垂直分割表（不破坏第三范式），把主码(主键)和一些列放到一个表，然后把主码(主键)和另外的一些列放到另一个表中。将原始表分成多个只包含较少列的表。如果一个表中某些列常用，而另外一些列不常用，则可以采用垂直分割。
优点：
1：垂直分割可以使得行数据变小，一个数据块(Block)就能存放更多的数据，在查询时就会减少I/O次数(每次查询时读取的Block 就少)。
2：垂直分割表可以达到最大化利用Cache的目的。
缺点：
1：表垂直分割后，主码(主键)出现冗余，需要管理冗余列
2：会引起表连接JOIN操作（增加CPU开销）需要从业务上规避
三. 库表散列
表散列与水平分割相似，但没有水平分割那样的明显分割界限，采用Hash算法把数据分散到各个分表中, 这样IO更加均衡。一般来说，我们会按照业务或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行 更小的数据库散列，比如用户表，按照用户ID进行表散列，散列128张表，则应就能够低成本的提升系统的性能并且有很好的扩展
标签：
原文地址：http://www.cnblogs.com/bqh10086/p/5860250.html
