分库分表-简单总结

前言

常用的数据有oracle和mysql;

oracle费用高,性能高,一个oracle相当于10到30个mysql;

但是面临海量数据,oracle仍不够,分库分表的难度大;

分库分表针对于mysql;

解决性能问题,需将数据或操作分离,mysql官方提供了读写分离的插件:proxyg;

读写分离,日志同步,解决了高并发问题,单没有解决高可用;

单库单表

单库单表是最常见的数据库设计,例如,有一张用户(user)表放在数据库db中,所有的用户都可以在db库中的user表中查到。

单库多表

随着用户数量的增加,user表的数据量会越来越大,当数据量达到一定程度的时候对user表的查询会渐渐的变慢,从而影响整个DB的性能。如果使用mysql, 还有一个更严重的问题是,当需要添加一列的时候,mysql会锁表,期间所有的读写操作只能等待。

可以通过某种方式将user进行水平的切分,产生两个表结构完全一样的user_0000,user_0001等表,user_0000 + user_0001 + …的数据刚好是一份完整的数据。

多库多表

随着数据量增加也许单台DB的存储空间不够,随着查询量的增加单台数据库服务器已经没办法支撑。这个时候可以再对数据库进行水平区分。

分库分表规则

设计表的时候需要确定此表按照什么样的规则进行分库分表。例如,当有新用户时,程序得确定将此用户信息添加到哪个表中;同理,当登录的时候我们得通过用户的账号找到数据库中对应的记录,所有的这些都需要按照某一规则进行。

路由

通过分库分表规则查找到对应的表和库的过程。如分库分表的规则是user_id mod 4的方式,当用户新注册了一个账号,账号id的123,我们可以通过id mod 4的方式确定此账号应该保存到User_0003表中。当用户123登录的时候,我们通过123 mod 4后确定记录在User_0003中。

分库分表产生的问题,及注意事项

1.   分库分表维度的问题

假如用户购买了商品,需要将交易记录保存取来,如果按照用户的纬度分表,则每个用户的交易记录都保存在同一表中,所以很快很方便的查找到某用户的购买情况,但是某商品被购买的情况则很有可能分布在多张表中,查找起来比较麻烦。反之,按照商品维度分表,可以很方便的查找到此商品的购买情况,但要查找到买人的交易记录比较麻烦。

所以常见的解决方式有:

a.通过扫表的方式解决,此方法基本不可能,效率太低了。

b.记录两份数据,一份按照用户纬度分表,一份按照商品维度分表。

c.通过搜索引擎解决,但如果实时性要求很高,又得关系到实时搜索。

2.   联合查询的问题

联合查询基本不可能,因为关联的表有可能不在同一数据库中。

3.   避免跨库事务

避免在一个事务中修改db0中的表的时候同时修改db1中的表,一个是操作起来更复杂,效率也会有一定影响。

4.   尽量把同一组数据放到同一DB服务器上

例如将卖家a的商品和交易信息都放到db0中,当db1挂了的时候,卖家a相关的东西可以正常使用。也就是说避免数据库中的数据依赖另一数据库中的数据。

一主多备

在实际的应用中,绝大部分情况都是读远大于写。Mysql提供了读写分离的机制,所有的写操作都必须对应到Master,读操作可以在Master和Slave机器上进行,Slave与Master的结构完全一样,一个Master可以有多个Slave,甚至Slave下还可以挂Slave,通过此方式可以有效的提高DB集群的QPS.

所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重。

此外,可以看出Master是集群的瓶颈,当写操作过多,会严重影响到Master的稳定性,如果Master挂掉,整个集群都将不能正常工作。

所以,1. 当读压力很大的时候,可以考虑添加Slave机器的分式解决,但是当Slave机器达到一定的数量就得考虑分库了。 2. 当写压力很大的时候,就必须得进行分库操作。

另外,可能会因为种种原因,集群中的数据库硬件配置等会不一样,某些性能高,某些性能低,这个时候可以通过程序控制每台机器读写的比重,达到负载均衡。

时间: 2024-10-27 12:30:22

分库分表-简单总结的相关文章

超简单理解分库分表

目录 一.为什么要做分库分表 二.如何进行数据分片 1.垂直切分 2.水平切分(重点) 三.数据切分后会出现的问题 数据源管理的问题 一.为什么要做分库分表 在数据爆炸的年代,单表数据达到千万级别,甚至过亿的量,都是很常见的情景.这时候再对数据库进行操作就是非常吃力的事情了,select个半天都出不来数据,这时候业务已经难以维系.不得已,分库分表提上日程,我们的目的很简单,减小数据库的压力,缩短表的操作时间. 二.如何进行数据分片 数据切分(Sharding),简单的来说,就是通过某种特定的条件

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

数据库分库分表

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-jdbc结合mybatis实现分库分表功能

最近忙于项目已经好久几天没写博客了,前2篇文章我给大家介绍了搭建基础springMvc+mybatis的maven工程,这个简单框架已经可以对付一般的小型项目.但是我们实际项目中会碰到很多复杂的场景,比如数据量很大的情况下如何保证性能.今天我就给大家介绍数据库分库分表的优化,本文介绍mybatis结合当当网的sharding-jdbc分库分表技术(原理这里不做介绍) 首先在pom文件中引入需要的依赖 <dependency> <groupId>com.dangdang</gr

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

前言 目前所在的的项目组,由于项目正在处于一个业务爆发期,每天数据的增长量已经给我们数据库乃至系统造成了很多不确定的因数,前期依靠优化业务和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确实很成熟很稳定,但是高昂的使用费用和高端的硬件支撑不是每一个公司能支付的起的.试想一下一年几千万的使用费用和动辄上千万元的小型机作为硬件支撑,这是一般公司能支付的起的吗?即使就是能支付的起,假如有更好的方案,有更廉价且水平扩展性能更好的方案,我们肯定会进行选择的. 平常我们会自觉的按照范式来设计我们的数据库,负载高点可能考虑使

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

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

大众点评订单系统分库分表实践

转载至:http://tech.meituan.com/dianping_order_db_sharding.html 背景 原大众点评的订单单表早就已经突破两百G,由于查询维度较多,即使加了两个从库,优化索引,仍然存在很多查询不理想的情况.去年大量抢购活动的开展,使数据库达到瓶颈,应用只能通过限速.异步队列等对其进行保护:业务需求层出不穷,原有的订单模型很难满足业务需求,但是基于原订单表的DDL又非常吃力,无法达到业务要求.随着这些问题越来越突出,订单数据库的切分就愈发急迫了. 这次切分,我们