分表(只能解决数据量过大带来查询效率下降的问题,无法解决并发问题)
对于访问极为频繁且数据量巨大的单表来说,我们首先要做的,就是减少单表的记录条数,以便减少数据查询所需要的时间,提高数据库的吞吐,这就是所谓的分表。(减少数据库的吞吐,就是减少数据库容量。)
首先需要选择适当的分表策略,使得数据能够较为均衡的分布到多张表中,并且,不影响正常的查询。
案例:
对于互联网企业来说,大部分数据都是与用户进行关联的,因此,用户id是最常用的分表字段,因为大部分查询都需要带上用户id,这样既不影响查询,又能够使数据较为均衡的分布到各个表中。
(当数据量达到一定数量时定时跑批拆分记录,通过单个表分成256个表)
订单表:拆分记录根据ueerid%256,取得每个订单存的是哪个表,前端根据userid%256来找对应的表来进行访问,这样的话userid就成了一个必须的查询条件,因为如果没有带用户id,就不知道在那张表去查他的数据。如果userid为257,那就%256,那么就知道去第一张表去查数据。
分库(给数据库处理并发问题来质的提升)
面对高并发的读写访问,当数据库master服务器无法承载写操作压力时,不管如何扩展slave服务器,此时都没有意义了。因此,我们必须换一种思路,对数据库进行拆分,从而提高数据库写入能力,这就是所谓的分库。
通过单个库分成256个库。
分库分表
数据库可能即面临着高并发访问的压力,又需要面对海量数据的存储问题,这时候,需要对数据库即采用分库策略,又采用分表策略,以便同时扩展系统的并发处理能力,以及提升单表的查询性
能,这就是所谓的 分库分表。
公式:被分库和被分表的数量更换。
中间变量=user_id%(库数量*每个库的表数量)
库=取整(中间变量/每个库的表数量)
表=中间变量%每个库的表数量
分库分表策略(先分库在分表)
假设将原来的单库单表order拆分成256个库,每个库包含1024个表,
那么,按照前面所提到的路由策略,对于userid=262145的访问,
路由的计算过程如下:
中间变量=262145%(256*1024)=1
库=取整(1/1024)=0
表=1%1024=1
这意味着,对于userid=262145的订单记录的查询和修改,将被路
由到第0个库的第1个表中执行。
拉主从而不进行读写分离的公司:主要是想利用从库做数据库的备份。
分库分表带来的限制
1.条件查询、分页查询受到限制,查询必须带上分库分表所带上的id。
2.事务可能跨多个库,数据一致性无法通过本地事务实现,无法使用外键(要使用分布式事务)。
3.分库分表规则确定以后,扩展变更规则需要迁移数据
4.如果是海量重要的数据,就要是分库分表,如果数据只是针对当前这段时间比较重要,但数据增长的又快,如有上千万,那可以每隔一段时间将这些数据清理掉,如客户的预约数据。