基于.Net + SqlServer的分库分表设计方案

在说分库分表之前,先简单介绍下网站架构,这样有助于理解为何需要分库分表这种技术。因为所有的技术,大多都是因为业务的需要而产生的.

1、网站发展的第一阶段

大致架构如下,因为没有多少用户访问,所以单台服务器都搞定所有的事情,上面跑着数据库、资源站点、以及所有的业务站点.

2、网站发展的第二阶段

这个时候访问量开始增加,发现服务器的资源不够用了,用户体验越来越差,所以,第一想法,升级服务器配置.ok,暂时解决了问题,站点又能提供稳定且高效的服务.

3、网站发展的第三阶段

访问量持续增加,这个时候升级服务器的配置所产生的代价太大,而且,就算继续升级也无法解决本质的问题,所以开始考虑其它的方案!

很简单,将业务和数据分离,将业务站点和数据库和资源站点分开,如下架构:

这里需要注意:业务站点需要处理大量的业务逻辑,所以CPU的性能一定要高,文件服务器则需要大一点的硬盘,数据库服务器则需要更快的硬盘和更大的内存.

ok,问题又解决了,站点又能提供稳定且高效的服务.

4、网站发展的第四阶段

访问量持续增加,单台应用服务器的IIS线程并发连接有限,而且随着用户的上升开始出现超时,异常,直至站点崩溃.所以必须解决这个问题.

ok,增加应用服务器,实现小集群(每次加一台),上nginx(关于nginx不了解请参考Nginx),做反向代理,分发用户的请求到不同的应用服务器,如果涉及登陆做下Ip_Hash.

ok,问题又解决了,站点又能提供稳定且高效的服务.

5、网站发展的第五阶段

访问量持续增加,应用服务器也越来越多,数据库的压力越来越大,而且数据随着用户的上升爆发时的增加,数据库面临了性能瓶颈,因为单表数据的上升,所以必须分表,提升查询的速度.所以必须开始动数据库了.

第一步:实现数据库的读写分离,主要是配置,网商有很多文章,自行参考

第二步:分库分表,终于引出来了,哈哈

6、关于分库分表常用的设计思路

按时间、按地区(IP)、按业务进行划分,无外乎这三种方式.下面简单的介绍个例子,假设站点是个登陆站点,主要分为QQ登陆和微信登陆,站点需要记录每次用户的登陆的一些信息.

假设每天有10万用户登陆.做过单表10万数据查询的知道,不加索引的情况下,还是有点慢的.所以我们需要对这个登陆记录表进行拆分.第一步按QQ登陆和微信登陆进行分库,将通过QQ登陆的用户登陆信息存储到QQ登陆库,微信同理,这样每个库每天承担5万的写操作.

但是单表5万记录查询还是有点慢,这个时候还可以进行细分,比如按用户Id,进行拆封按用户Id拆分一般有两种(用户Id算法):

(1)、如果Id是int整数(如SqlServer的自增Id),可以采用Id%10取余算法,找到目标表。采用这种算法,那么原先的单表被拆封成0~9十个表,每个表承担5000的写操作,这样压力瞬间就下来了

(2)、如果Id是Guid(长度固定,全大写),获取最后1个字母,找到目标表,采用这种算法,那么原先的单表被拆封成A-Z36个表,每个表承担写压力就更小了.

上面两个都可取,但是可以根据具体的业务酌情选择.

目前为止,解决了单天的性能瓶颈,但是每天都有10万数据进来,肯定是不行的,所以按照上面的思路每天的数据必须在当前被清空,因为不清空,随着数据每天加10000万的操作,查询到最后还是受不了.

所以必须写个定时服务,每天在业务低峰期清除QQ登陆信息库和微信登陆信息库的数据,清楚的同时将它们迁移到对应QQ登陆信息历史库和微信登陆历史库中,关于历史库的构建就需要仔细考虑了.

考虑了几种方案:

(1)、就两个历史库(微信登陆历史库和QQ登陆历史库),直接Pass,每天10万数据的递增,不用一年就直接崩了.

(2)、按年分库 月+日+用户Id 进行分表 直接Pass,这个方案会产生大概3600个表

(3)、权衡考虑采用按年分库 月+用户Id 进行分表 如果用户Id采用用户Id算法的第一种,那么会产生大概120个表.

确定好历史库设计方案之后,将每天的登陆信息记录同步到对应的历史库中.

原文地址:https://www.cnblogs.com/GreenLeaves/p/10053935.html

时间: 2024-11-04 14:50:34

基于.Net + SqlServer的分库分表设计方案的相关文章

架构组件:基于Shard-Jdbc分库分表,数据库扩容方案

一.数据库扩容 1.业务场景 互联网项目中有很多"数据量大,业务复杂度高,需要分库分表"的业务场景. 这样分层的架构 (1)上层是业务层biz,实现业务逻辑封装: (2)中间是服务层service,封装数据访问: (3)下层是数据层db,存储业务数据: 2.扩容场景和问题 当数据量持续新增,面临着这样一些需求,两台数据库无法容纳,需要数据库扩容,这里选择2台-扩容到3台的模式,如下图: 这样扩容的问题 (1)分库分表的策略导致数据迁移量大: (2)影响数据的持续服务性: (3)指定时间

基于Shard-Jdbc分库分表模式下,数据库扩容方案

本文源码:GitHub·点这里 || GitEE·点这里 一.数据库扩容 1.业务场景 互联网项目中有很多"数据量大,业务复杂度高,需要分库分表"的业务场景. 这样分层的架构(1)上层是业务层biz,实现业务逻辑封装:(2)中间是服务层service,封装数据访问:(3)下层是数据层db,存储业务数据: 2.扩容场景和问题 当数据量持续新增,面临着这样一些需求,两台数据库无法容纳,需要数据库扩容,这里选择2台-扩容到3台的模式,如下图: 这样扩容的问题(1)分库分表的策略导致数据迁移量

透明的分库分表方案——转自:OSChina 悠悠然然

转自:OSChina 悠悠然然 问题提出 随着应用规模的不断扩大,单机数据库就慢慢无法满足应用的需要了,这主要表现在如下方面: 存量数据越来越大,查询速度越来越慢 访问并发越来越大,磁盘IO.网络IO.CPU都慢慢成为瓶颈 事务数越来越多,事务冲突越来越严重,导致TPS越来越少 这个时候,有的人采用了换商用数据库的方案比如Oracle,然后用Oracle 的RAC方式进行水平扩展.但是带来的缺点也比较明显,第一是成本太高,一般人吃不消:第二,管理复杂度较单节点有非常大的提升,风险及管理成本也相应

数据库(分库分表)中间件对比

转自:http://www.cnblogs.com/cangqiongbingchen/p/7094822.html 分区:对业务透明,分区只不过把存放数据的文件分成了许多小块,例如mysql中的一张表对应三个文件.MYD,MYI,frm. 根据一定的规则把数据文件(MYD)和索引文件(MYI)进行了分割,分区后的表呢,还是一张表.分区可以把表分到不同的硬盘上,但不能分配到不同服务器上. 优点:数据不存在多个副本,不必进行数据复制,性能更高. 缺点:分区策略必须经过充分考虑,避免多个分区之间的数

透明的分库分表方案

问题提出 随着应用规模的不断扩大,单机数据库就慢慢无法满足应用的需要了,这主要表现在如下方面: 存量数据越来越大,查询速度越来越慢 访问并发越来越大,磁盘IO.网络IO.CPU都慢慢成为瓶颈 事务数越来越多,事务冲突越来越严重,导致TPS越来越少 这个时候,有的人采用了换商用数据库的方案比如Oracle,然后用Oracle的RAC方式进行水平扩展.但是带来的缺点也比较明显,第一是成本太高,一般人吃不消:第二,管理复杂度较单节点有非常大的提升,风险及管理成本也相应增加:第三,对人员的水平要求更高,

[转]一种可以避免数据迁移的分库分表scale-out扩容方式

原文地址:http://jm-blog.aliapp.com/?p=590 目前绝大多数应用采取的两种分库分表规则 mod方式 dayofweek系列日期方式(所有星期1的数据在一个库/表,或所有?月份的数据在一个库表) 这两种方式有个本质的特点,就是离散性加周期性. 例如以一个表的主键对3取余数的方式分库或分表: 那么随着数据量的增大,每个表或库的数据量都是各自增长.当一个表或库的数据量增长到了一个极限,要加库或加表的时候, 介于这种分库分表算法的离散性,必需要做数据迁移才能完成.例如从3个扩

如何设计动态扩容缩容的分库分表方案?

面试官:如何来设计动态扩容的分库分表方案?面试官心理剖析:这个问题主要是看看你们公司设计的分库分表设计方案怎么样的?你知不知道动态扩容的方案? 回答: 背景说明:如果你们公司之前已经做了分库分表,你们当时分了 4 个库,每个库 4 张表:公司业务发展的很好,现在的数据库已经开始吃力了,不能满足快速发展的业务量了,需要进行扩容. 1)停机扩容 这个方案跟单库迁移方案是一样的,就是停服进行数据迁移,不过现在的数据迁移比之前的单库迁移要复杂的多,还有数据量也是之前的好几倍,单库的数据量可能就几千万,但

SQLSERVER分库分表

单库单表 单库单表是最常见的数据库设计,例如,有一张用户(user)表放在数据库db中,所有的用户都可以在db库中的user表中查到. 单库多表 随着用户数量的增加,user表的数据量会越来越大,当数据量达到一定程度的时候对user表的查询会渐渐的变慢,从而影响整个DB的性能.如果使用mysql, 还有一个更严重的问题是,当需要添加一列的时候,mysql会锁表,期间所有的读写操作只能等待. 可以通过某种方式将user进行水平的切分,产生两个表结构完全一样的user_0000,user_0001等

Mycat读写分离和分库分表配置

Mycat是一个开源的分布式数据库系统,不同于oracle和mysql,Mycat并没有存储引擎,但是Mycat实现了mysql协议,前段用户可以把它当做一个Proxy.其核心功能是分表分库,即将一个大表水平分割为N个小表,存储在后端mysql存储引擎里面.最新版本的Mycat不仅支持mysql,还可以支持MS SqlServer,Oracle,DB2等关系型数据库,而且还支持MongoDB这种NoSQL.Mycat对调用者屏蔽了后端存储具体实现. Mycat的原理是先拦截用户的SQL语句并做分