分库分表,可能真的要退出历史舞台了!

这篇具有很好参考价值的文章主要介绍了分库分表,可能真的要退出历史舞台了!。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

即使是不懂编程的玩家,在对比 NAS 的时候,也会两眼放光,考虑很多因素,比如 RAID 级别、速度、易用程度等。作为时时刻刻与代码打交道的我们,更需要关注数据的存取问题。

一开始,开箱即用的 MySQL,一定是企业的首选。不仅仅因为用的人多,更重要的是生态成熟。要工具有工具,要人有人。对于老板来说,员工看着不爽,可以随时辞退,是一个非常理想的状态。

但是,没有胸怀的老板,干的一定不会长久,因为如果商务会吹、老板会忽悠,业务会飞速发展(虽然现在这种机会比较少了)。对于 MySQL 来说,很快就会遇到问题。

这个时候,就需要一些比只会用 MySQL 级别高一些的人才,来配合老板圆梦。

是时候了,由单机 MySQL 向分布式发展了。

单机 MySQL 面临很多问题。

  1. 单表太大,比如超过 500w,查询就非常吃力

  2. 单库太大,各种资源告急

  3. 读请求太高,严重影响写请求

对此,一堆概念也是腾空而出,比如分库分表、读写分离等。

很长时间以来,国内互联网的做法普遍是采用加入一个中间件的方式来解决,但随着分布式数据库的技术越来越成熟,这些魔法逐渐下沉到它本应该解决的层面--数据库实现层。

留给分库分表技术的时间,已经不多了,它的存量市场越来越少了。分库分表技术,退出历史舞台,也是迟早的事情了。

解决上面三个单机 MySQL 问题,有很多种切入层面。比如,你简单的在 MyBatis 或者 JPA 之上使用 AOP 或者拦截器封装一层,也可以实现,这也是最傻的方式。

再进一步,就可以采用在 JDBC 之上的驱动层来实现,把分库分表的路由维护在内存里,通过重写的 DataSource、Connection、Statment、ResultSet等,对业务进行无侵入的改进。但可惜的是,我们还必须要维护与逻辑表相对应的物理表,而且功能也是阉割的,不确定性依然不小。更要命的是,JDBC 只支持 Java,对于某些公司来说,就非常的不适用。

再就是中间件的传统模式,Proxy。把自己伪装成一个MySQL Server,接受 Client 的请求。至于它后面怎么去操作真实的数据库,你都不需要知道。但 Proxy 本身也是一套服务,你有运维成本在里面,同时功能依然是阉割的。

框架层,驱动层,代理层,在过去很长一段时间里,有无数的互联网公司前赴后继的试水,从 TDDL、Cobar,到 MyCat、ShardingSphere,各种层面的中间件也是层出不穷。但最近几年,这种争相斗艳的场面逐渐不再,到最后剩下来的,也就ShardingSphere这一枝独秀了。

是问题不存在了么?不,正好相反,问题越来越严重。并不是问题消失了,而是它被转化成其他解决方式了。

抛开关系型数据库不说,很久之前,类似于 ElasticSearch、Cassandra这样的 NoSQL 存储,分片和副本的概念,就已经非常成熟了,而且它们是内置的,并不需要 DBA 去人工维护它们的物理位置。

对于关系型数据库来说,走向分布式也终将成为必然。随着 Raft 等协议应用越来越广泛,分布式数据库的可靠性也逐渐得到了保证。如果你以前因为事务问题而拒绝采用某些 NoSQL 产品,那么如今完全兼容 MySQL 的分布式数据库,你没有理由再说 No。

云厂商,直接提供了像Aurora、PolarDB之类的MySQL增强,更有类似 TiDB、OceanBase 这样纯粹的分布式数据库,越来越多的业务走向了这个终途。当你的团队加班加点验证着分库分表中间件的时候,却发现其实换个兼容的存储就能玩得转,你会怎么选,简直不用再多说。

当然,一旦你选用了分布式数据库,以前的 DBA 经验可能就不管用了,比如说索引及其二级索引。你的团队不得不学习新的知识,来应对分布式环境。

但这些都是阵痛,长远看来,分布式数据库是趋势,而分库分表中间件只能吃存量。

当你的业务有了常年累积的复杂数据,你可能会采用复杂的分库分表组件,但如果你的业务比较新,可预见的未来会有大量数据,那一个分布式数据库可能是最合适的。

分库分表中间件并不是消失了。它摇身一变,变成了分布式数据库的一部分。

你可能会听到很多切到分布式数据库,又从分布式数据库切回到 MySQL 的案例,这属于想吃螃蟹但并没有吃到。目前来看,分布式数据库越来越稳定,生态建设也越来越好。而分库分表,则属于存量业务,终将会退出历史的舞台。文章来源地址https://www.toymoban.com/news/detail-589869.html

到了这里,关于分库分表,可能真的要退出历史舞台了!的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • RIP动态路由协议 (已过时,逐渐退出舞台)

    RIP 路由更新:RIP1/2 每30秒钟广播(255.255.255.255)/组播 (224.0.0.9)一次超时:180秒未收到更新,即标记为不可用(跳数16),240秒收不到,即从路由表中删除 ;跳数:最大为15 协议:使用UDP协议,端口号520 水平分割:即从一个接口收到路由更新,不会在从这个接口将收到的路由

    2024年02月14日
    浏览(35)
  • 什么是分库分表?为什么需要分表?什么时候分库分表

    不急于上手实战  ShardingSphere  框架,先来复习下分库分表的基础概念,技术名词大多晦涩难懂,不要死记硬背理解最重要,当你捅破那层窗户纸,发现其实它也就那么回事。 分库分表是在海量数据下,由于单库、表数据量过大,导致数据库性能持续下降的问题,演变出的技

    2023年04月26日
    浏览(146)
  • 分库分表介绍以及shardingjdbc实现分库分表

    分库分表概念 一、什么是分库分表 分库分表是在海量数据下,由于单库、表数据量过大,导致数据库性能持续下降的问题,演变出的技术方案。 分库分表是由分库和分表这两个独立概念组成的,只不过通常分库与分表的操作会同时进行,以至于我们习惯性的将它们合在一起

    2023年04月13日
    浏览(37)
  • 【分库分表】基于mysql+shardingSphere的分库分表技术

    目录 1.什么是分库分表 2.分片方法 3.测试数据 4.shardingSphere 4.1.介绍 4.2.sharding jdbc 4.3.sharding proxy 4.4.两者之间的对比 5.留个尾巴 分库分表是一种场景解决方案,它的出现是为了解决一些场景问题的,哪些场景喃? 单表过大的话,读请求进来,查数据需要的时间会过长 读请求过

    2024年03月12日
    浏览(48)
  • 分表?分库?分库分表?实践详谈 ShardingSphere-JDBC

    如果有不是很了解ShardingSphere的可以先看一下这个文章: 《ShardingSphere JDBC?Sharding JDBC?》基本小白脱坑问题         在很多开发场景下面,很多的技术难题都是出自于,大数据量级或者并发的场景下面的。这里就出现了我们要解决的。本文章重点讨论一下在java的spirng开发场

    2024年04月12日
    浏览(38)
  • 掌握MySQL分库分表(一)数据库性能优化思路、分库分表优缺点

    不能⼀上来就说分库分表! 根据实际情况分析,两个角度思考:不分库分表、分库分表 软优化 数据库参数调优 分析慢查询SQL语句,分析执行计划,进行sql改写和程序改写 优化数据库索引结构 优化数据表结构优化 引入NOSQL和程序架构调整 硬优化 提升系统硬件(更快的IO、更

    2023年04月19日
    浏览(59)
  • MySQL运维6-Mycat分库分表之垂直分库

    场景:在业务系统中,涉及一下表结构,但是由于用户与订单每天都会产生大量的数据,单台服务器的数据存储以及处理能力是有限的,可以对数据库表进行拆分,原有数据库如下 说明1:整个业务系统中的表,大致分为四个,商品信息类的表,订单相关的表,用户相关表及

    2024年02月04日
    浏览(48)
  • presto插件机制揭秘:探索无限可能的数据处理舞台

    :Presto Plugin 本文源码环境: presto: prestoDb 0.275版本 在Presto框架中插件机制设计是一种非常常见和强大的扩展方式。它可以使软件系统更加灵活和可扩展,允许用户根据自己的需求和偏好自定义和扩展系统功能。在 Presto 这样的分布式 SQL 查询引擎中,插件机制发挥着重

    2024年02月05日
    浏览(73)
  • 对分库分表进行批量操作

    对ShardingJDBC基础了解:https://blog.csdn.net/m0_63297646/article/details/131894472 对批量操作案例:https://blog.csdn.net/m0_63297646/article/details/131843517 分为db0和db1两个库,每个库都有三张订单表,分表键根据年份【year】,分库键根据店铺id【store_id】 在db0中存在两张学生信息表,分表键根据年

    2024年02月10日
    浏览(37)
  • django分库分表的优化

    方案一:轮询方式分表 当系统数据越来越多的时候,查询变得缓慢,即使加了索引,由于表数据的增加,索引的维护也会成为数据库性能的限制问题,所以此时可以通过分表,将数据通过某种准则分别存储到不同的表中,以实现缓解单表的压力。 分表的方法大部分都是通过

    2024年01月18日
    浏览(40)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包