数据库拆分原则:
1.优先考虑缓存降低对数据库的读操作。
2.再考虑读写分离,降低数据库写操作。
3.最后开始数据拆分,切分模式: 首先垂直(纵向)拆分、再次水平拆分。
4.首先考虑按照业务垂直拆分。
5.再考虑水平拆分:先分库(设置数据路由规则,把数据分配到不同的库中)
6.最后再考虑分表,单表拆分到数据1000万以内。
垂直拆分:
专库专用:一个数据库由很多表的构成,每个表对应不同的业务,垂直拆分是指按照业务将表进行分类,分布到不同的数据库上面,这样也就将数据或者说压力分担到不同的库上面;
优点:
1.拆分后业务清晰,拆分规则明确。
2.系统之间整合或者扩展容易。
3.数据维护简单。
缺点:
1.部分业务表无法join。只能通过接口方式解决,提高了系统复杂度。
2.受每种业务不同的限制存在单库性能瓶颈,不易数据扩展跟性能提高。
3.事务处理复杂。
水平拆分:
垂直拆分后遇到单机瓶颈,相对于垂直拆分的区别是:
垂直拆分是把不同的表拆到不同的数据库中,而水平拆分是把同一张表拆到不同的数据库中。
我们可以将数据的水平切分理解为:我们将数据的水平切分理解为按照数据行的切分,
就是讲表中的某些行切分到一个数据库,而另外的某些行后切分到其他的数据库中,主要有
分表,分库两种模式;
优点:
1.不存在单库大数据,高并发的性能瓶颈;
2.对应用透明,应用端改造较少。
3.按照合理拆分规则拆分,join操作基本避免跨库。
4.提高了系统的稳定性跟负载能力。
缺点:
1.拆分规则难以抽象。
2.分片事务一致性难以解决。
3.数据多次扩展难度跟维护量极大。
4.跨库join性能较差。
拆分的处理难点:
两种方式的共同缺点:
1.引入分布式事物的问题。
2.跨节点join的问题。
3.跨节点合并排序分页问题。
针对数据源管理,目前主要有两种思路:
A:客户端模式,在每个应用程序模块中配置管理自己需要的一个(或者多个)数据源,
直接访问各个数据库,在模块内完成数据的整合。
优点:相对简单,无性能损耗。
缺点:不够通用,数据库连接的处理复杂,对业务不够透明,处理复杂。
B:通过中间代理层来统一管理所有的数据源,后端数据库集群对前端应用程序透明;
优点:通用,对应用透明,改造少。
缺点::实现难度大,有二次转发性能损失:
拆分原则:
1.尽量不拆分 ,架构师进化而来,不是一蹴而就。(SOA)
2.最大可能的找到合适的切分维度。
3.由于数据库中间件对数据join实现的优劣难以把握,而且实现高性能难度极大,
业务读取尽量少使用多表的Join-尽量通过数据冗余,分组避免数据跨库多表Join。
4.尽量避免分布式事物。
5.单表拆分到数据1000万以内。
切分方案
范围,枚举,时间,取模,哈希,制定等。