一文让你精通数据库优化方案之分库分表

分库分表概述

读写分离分散数据库读写操作压力,分库分表分散存储压力

适用场景

类似读写分离,分库分表也是确定没有其他优化空间之后才采取的优化方案。那如果业务真的发展很快岂不是很快要进行分库分表了?那为何不一开始就设计好呢?

按照架构设计的“三原则”(简单原则,合适原则,演化原则),简单分析一下:

首先,这里的“如果”事实上发生的概率比较低,做10个业务有一个业务能活下去就很不错了,更何况快速发展,和中彩票的概率差不多。如果我们每个业务上来就按照淘宝、微信的规模去做架构设计,不但会累死自己,还会害死业务。

其次,如果业务真的发展很快,后面进行分库分表也不迟。因为业务发展好,相应的资源投入就会加大,可以投入更多的人和更多的钱,那业务分库带来的代码和业务复杂问题就可以通过加人来解决,成本问题也可以通过增加资金来解决。

业务分库

业务分表概述

带来的问题:垂直分表、增加表操作的次数、水平分表

路由问题

数据库操作问题

实现方法

类似读写分离,具体实现也是“程序代码封装”和“中间件封装”,但具体实现复杂一些,因为还有要判断SQL中具体操作的表,具体操作(例如count、order by、group by等),根据具体操作做不同的处理。

最后

欢迎大家关注我新开通的公众号【风平浪静如码】,最新最全多家公司java面试题整理了1000多道400多页pdf文档,文章都会在里面更新,整理的资料也会放在里面。

喜欢文章记得关注我点个赞哟,感谢支持!

原文地址:https://blog.51cto.com/14570694/2470959

时间: 02-14

一文让你精通数据库优化方案之分库分表的相关文章

【转】MYSQL数据库数据拆分之分库分表总结

http://wentao365.iteye.com/blog/1740691 数据存储演进思路一:单库单表单库单表是最常见的数据库设计,例如,有一张用户(user)表放在数据库db中,所有的用户都可以在db库中的user表中查到.数据存储演进思路二:单库多表随着用户数量的增加,user表的数据量会越来越大,当数据量达到一定程度的时候对user表的查询会渐渐的变慢,从而影响整个DB的性能.如果使用MySQL, 还有一个更严重的问题是,当需要添加一列的时候,mysql会锁表,期间所有的读写操作只能

170123、数据库分库分表策略的具体实现方案

相关文章: 1. 使用Spring AOP实现MySQL数据库读写分离案例分析 2.MySQL5.6 数据库主从(Master/Slave)同步安装与配置详解 :http://blog.csdn.net/xlgen157387/article/details/51331244 3.MySQL主从复制的常见拓扑.原理分析以及如何提高主从复制的效率总结 :http://blog.csdn.net/xlgen157387/article/details/52451613 4.使用mysqlreplic

MySQL分库分表方案

1. MySQL分库分表方案 1.1. 问题: 1.2. 回答: 1.2.1. 最好的切分MySQL的方式就是:除非万不得已,否则不要去干它. 1.2.2. 你的SQL语句不再是声明式的(declarative) 1.2.3. 你招致了大量的网络延时 1.2.4. 你失去了SQL的许多强大能力 1.2.5. MySQL没有API保证异步查询返回顺序结果 1.2.6. 总结 MySQL分库分表方案 翻译一个stackoverflow上的问答,关于分库分表的缺点的,原文链接: MySQL shard

记录一次经历的数据库从单库到分库分表的过程

前言 目前所在的的项目组,由于项目正在处于一个业务爆发期,每天数据的增长量已经给我们数据库乃至系统造成了很多不确定的因数,前期依靠优化业务和SQL等方式暂时还能够支撑住.但是最近发现某些表数据达到500W+以后查询统计性能严重下降,高峰时段出现了很多SQL阻塞的情况例如: 这种阻塞带来的灾难是滚雪球的,由于越堆越多基本上把数据库已经拖死,所以我们就面临数据库切分的问题. 技术选型 既然要分库分表那数据库集群是少不了的,那我们的项目怎样和这些集群打交道呢?我调研了大概分为以下几种来完成这个功能(仅

关系型数据库分库分表解决方案

关系型数据库分库分表解决方案 关系型数据库单库或单表在数据达到一定量级后,单个节点的就会出现性能瓶颈.通常的做法就是考虑分库分表. 为什么要分? 分库降低了单点机器的负载:分表,提高了数据操作的效率,尤其是Write操作的效率. 如何分? 按号段分: (1) user_id为区分,1-1000的对应DB1,1001-2000的对应DB2,以此类推:优点:可部分迁移缺点:数据分布不均 (2)hash取模分: 对user_id进行hash(或者如果user_id是数值型的话直接使用user_id 的

数据库分库分表系统学习

一  为什么要进行数据切分 为什么需要数据切分呢?比如像Oracle这样成熟稳定的数据库,足以支撑海量数据的存储与查询了?为什么还需要数据切片呢?的确,Oracle的DB确实很成熟很稳定,但是高昂的使用费用和高端的硬件支撑不是每一个公司能支付的起的.试想一下一年几千万的使用费用和动辄上千万元的小型机作为硬件支撑,这是一般公司能支付的起的吗?即使就是能支付的起,假如有更好的方案,有更廉价且水平扩展性能更好的方案,我们肯定会进行选择的. 平常我们会自觉的按照范式来设计我们的数据库,负载高点可能考虑使

数据库分库分表

1. 数据库分库分表 1.1. 前言 1.1.1. 名词解释 1.2. 数据库架构演变 1.3. 分库分表前的问题 1.3.1. 用户请求量太大 1.3.2. 单库太大 1.3.3. 单表太大 1.4. 分库分表的方式方法 1.4.1. 垂直拆分 1.4.2. 水平拆分 1.5. 分库分表后面临的问题 1.5.1. 事务支持 1.5.2. 多库结果集合并(group by,order by) 1.5.3. 跨库join 1.6. 分库分表方案产品 1.7. 为什么不建议分库分表 1.8. 参考

数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示

本文原文连接: http://blog.csdn.net/bluishglc/article/details/7696085 ,转载请注明出处!本文着重介绍sharding切分策略,如果你对数据库sharding缺少基本的了解,请参考我另一篇从基础理论全面介绍sharding的文章:数据库Sharding的基本思想和切分策略 第一部分:实施策略 图1.数据库分库分表(sharding)实施策略图解(点击查看大图) 1.准备阶段 对数据库进行分库分表(Sharding化)前,需要开发人员充分了解系

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

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

16、MySQL数据库分库分表备份脚本

MySQL数据库分库分表备份脚本 ===================学员分享分库分表========================== 脚本单双引号的区别: 单引号是强引用,强制输出是所见即所得. 双引号是解析变量 和 多个字符串.数字等连接一个字符串 条件1  ||    条件2                      或   假真   真假 条件1 && 条件2                      并   真真    假假 !条件1  && 条件2