[分布式数据库]数据分片

学生阶段,但凡要做个“系统”,总绕不开的就是数据库。项目中的一些关键数据,通过持久化到数据库,保障系统的可靠性。我们接触最多的就是类似于Oracle、Mysql等数据库。
其实上了班,依旧还是没能绕过数据库,只不过不再单一的将数据存储在关系型数据库,更多的通过其他形式,例如NoSQL,以减少数据库的访问,但是NoSQL依旧无法对关系型数据库致命一击以完全替代关系型数据库,关键的数据持久化依旧还是要存放在数据库。随着国家号召自主可控,Oracle也需要渐渐从主流中剔除(成本和历史的必然)。但是这里还是要说一句,Oracle依旧是关系型数据库中的大佬,别的数据库都只能通过调优的形式去接近Oracle的处理能力却难以超越它。

文章目录

  • 背景介绍
  • 数据分片
    • 垂直分片
    • 水平分片
  • 存在的问题

背景介绍

传统的将数据集中存储至单一数据节点的解决方案,在性能可用性运维成本这三方面已经难于满足互联网的海量数据场景。
性能方面,由于关系型数据库大多采用B+树模型,导致数据量超过阈值的情况下,索引深度的增加导致磁盘IO访问次数增加,导致查询性能下降;同时高并发的访问请求也使得集中式数据库成为系统最大的瓶颈。
可用性方面,服务化的无状态能达到较小成本的随意扩容,但是导致所有压力都落在数据库,单一架构甚至简单的主从模式已经无力支撑。
运维成本方面考虑,当数据库达到单一数据库的阈值,对于DBA的运维压力就会增大,数据备份时间、恢复时间都会随着数据量增大变大,单一数据库应把数据量控制在1TB范围内。

数据分片

数据分片指按照某个维度将存放在单一数据库中的数据分散地存放至多个数据库或表中以达到提升性能瓶颈以及可用性的效果。
数据分片的有效手段有两个:分表分库
分库可以有效的分散对于单节点数据库的访问量,分表随无法分散数据库压力,却能够避免分布式事务。
通过分表分库,可以对数据拆分,使各个表的数据量维持在阈值以下,以及对流量进行疏导应对高访问量,是应对高并发和海量数据系统的有效手段。
数据分片的拆分方式有垂直分片水平分片

垂直分片

按照业务拆分的方式称为垂直分片。它的核心理念是专库专用。拆分前,一个数据库由多个数据表构成,拆分后将这些不同的表按照业务划分到不同数据库,将压力分散到不同数据库。
但是垂直分片需要对架构和设计做相应调整,垂直拆分无法真正解决单点问题,当数据量达到一定阈值后依旧需要水平拆分来解决。

水平分片

不再按照业务拆分,而是根据表中的一个或几个字段,按照规则分散至多个库或者多个表中,每个分片包含数据的一部分。
这种拆分解决了单点数据量处理的瓶颈,扩展自由,是分表分库的标准解决方案。

存在的问题

1.对数据库操作变得繁重,需要知道数据从哪个库中获取;
2.单点能正常运行的sql,跨节点后不一定能正确运行
3.跨库事务问题。原则是尽量使用本地事务,但是有些不得不跨库的场景下,有些业务需要用XA分布式事务或者最终一致性的柔性事务。而基于XA的分布式事务由于在并发度高的场景中性能无法满足需要,并未被互联网巨头大规模使用,他们大多采用最终一致性的柔性事务代替强一致事务。

你可能感兴趣的:(数据库,分布式)