【总结】亿级数据的访问和储存，实现和优化

末蓝、 2022-02-16 12:08 221阅读 0赞

是否你也遇到了类似的问题：如何处理海量数据

> 比如订单数据越来越多（亿级），查询越来越慢，如何处理？  
> 分库分表会带来哪些副作用？可能的解决方式有哪些？

## 问题 ##

目前经常使用的关系型数据库如MySQL、SQL Server等，都是以“行”为单位进行存储，为了快速检索，也都采用了B树或其他索引技术。

从原理上来讲，**表中的数据越多，索引树的范围越大，磁盘读取也越多，性能也就越低。**

## 实践 ##

从实践角度来看，一般以百万到千万作为一个表的存储量级，超出该范围之后，性能就会下降，需要采用其他技术手段解决。

首先想到的就是**能否将读和写分离**，主数据库用于写入，读数据库（多个）用于对外提供查询，通过数据复制的方式将主数据库的数据同步到读库。**该架构提升了数据库的读写能力，但对于主数据库的写入能力依然没法扩展。**

其次，**依据数据库分区的思路，可以将不同的数据分散到不同的库中，每个库存储的数据都不同。**

这样就可以将单一库的压力分散到多个库中，从而提升整个数据库的服务能力，这就是所说的分库分表技术。

针对分库分表的技术方案，目前我们自己采用了自研的技术解决方案，然而你也可以使用[Sharding-JDBC][]方案。

> 若按照“字段（列）”分区，每个库/表存储不同的的字段，即schema不同，就是“垂直拆分”；
> 
> 若按“数据记录（行）”分区，每个库/表的schema一致，但存储的数据不同，就是“水平拆分”。

垂直拆分

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlbWluMTAwMw_size_16_color_FFFFFF_t_70][]

水平拆分

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlbWluMTAwMw_size_16_color_FFFFFF_t_70 1][]

这样做的好处就是解决了数据存储容量的问题，但也带来了诸多弊端。

## 解决方案 ##

这里以“水平拆分”为例来分析。

**1.如何能做到数据的平均拆分，防止某一库压力过大？**

系统开发者要结合业务特点来确定分库分表键，比如以userID为分库分表键，采用hash取模的方式将数据散列到不同的库中。

但并不是所有场景都适合用userID作为分库分表键的，若存在“大卖家”，则该userID可能有很多条记录，若简单的按照上述方法进行拆分，则可能打爆其中一个数据库。

一般来说，会将一段时间以前的**数据归档**（比如某个userID三个月之前的数据），存放到类似HBase这种非关系型数据库中，以此来解决上述问题。

**2.分库分表之后就要求每个查询的where子句中必须携带分库分表键，但并非每个查询都能携带分库分表键的。**

比如订单库按照订单号hash取模之后存储，此时分库分表键为订单号，那么想查询某位买家所有的订单，查询时就没有了分库分表键，就会出现“全表扫描”的情况。

一般在实践中解决这种问题的方法是**建立“异构索引表”**，即采用异步机制将原表内的每次一创建或更新，都换一个维度保存一份完整的数据表或索引表，拿空间换时间。

在上面说到，订单库按照订单号hash取模之后存储，同时也按照userID维度进行hash取模，再存储一份数据，那么想要获取某一userID的全部订单时，就将userID作为分库分表键传进去即可，避免了全表扫描。

上面这些是在海量数据处理过程中出现问题的解决思路，技术的突破需要依赖业务场景的需求和自身刻意的规划学习，二者缺一不可。

\------------------------------------------------------

[关于我][Link 1]（个人域名）

[我的开源项目集Github][Github]

期望和大家一起学习，共同进步，共勉，O(∩\_∩)O谢谢

欢迎交流问题，可加个人QQ 469580884，

或者，加我的群号 **751925591**，一起探讨交流问题

不讲虚的，只做实干家

Talk is cheap，show me the code

![20180411181545874][]

如果觉得内容赞，您可以请我喝杯咖啡：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9oZW1pbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70][]        ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9oZW1pbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 1][]

[Sharding-JDBC]: https://www.oschina.net/p/sharding-jdbc
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlbWluMTAwMw_size_16_color_FFFFFF_t_70]: /images/20220216/db8eb7efcadd4b3ebb515256a80376e4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlbWluMTAwMw_size_16_color_FFFFFF_t_70 1]: /images/20220216/b296243bb7414f0181c9acdbb58aca65.png
[Link 1]: http://heminit.com/about/
[Github]: https://github.com/hemin1003
[20180411181545874]: /images/20220216/f1c8c2c116cb4eda9634139585b9d045.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9oZW1pbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20190816110426562.jpeg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9oZW1pbi5ibG9nLmNzZG4ubmV0,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9oZW1pbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20190816110923699.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9oZW1pbi5ibG9nLmNzZG4ubmV0,size_16,color_FFFFFF,t_70