PolarDB 存算分离

背景 随着互联网业务规模不断扩大,传统关系型数据库架构逐渐暴露出一些瓶颈,例如扩展能力不足、存储成本高、读写压力集中等问题。为了应对这些挑战,云厂商开始设计一种新的数据库架构模式:存算分离(Storage-Compute Decoupling)。 PolarDB 是阿里云推出的一款云原生数据库,其核心设计理念之一就是 计算层与存储层解耦。这种架构使数据库具备更强的弹性扩展能力和更高的资源利用率。 () 本文将从架构角度分析 PolarDB 的存算分离设计,并与 AWS Aurora 以及传统 MySQL 架构进行对比。 传统 MySQL 架构的问题 在传统 MySQL 架构中,数据库通常运行在单个服务器上: MySQL Server ├── CPU ├── Memory └── Local Disk 计算和存储都在同一台机器上。 这种架构在早期互联网时代已经足够,但随着业务规模扩大,会出现几个明显问题: 1 存储扩展困难 数据库数据通常存储在本地磁盘中,当数据量增长时,只能通过: * 升级磁盘 * 更换更大的机器 这种方式扩展
6 min read

Canal 组件

前言 Canal 是阿里巴巴开源的一款 基于 MySQL Binlog 的数据实时订阅与消费组件,常用于实现数据库变更数据捕获(CDC,Change Data Capture)。 在实际业务场景中,数据库中的数据变更往往不仅仅用于业务读写,还可能需要同步到其他系统,例如: * 实时数据同步(数据库 → 数据仓库) * 数据变更推送到 MQ(Kafka / RocketMQ) * 构建实时数据分析或监控系统 * 搜索引擎数据同步(如 Elasticsearch) 为了实现这些能力,Canal 通过 模拟 MySQL Slave 的方式订阅 Binlog 日志,解析出数据库的增删改操作,并将这些变更数据实时推送给下游消费系统,从而实现数据的准实时同步。 目前市面上常见的 CDC 组件主要包括: * Canal * Debezium * Flink CDC Canal 目前只支持MySQL数据库。5.x
2 min read

Neo4j 图形数据库

前言 Neo4j 是一款高性能的图数据库,它采用 图形数据模型(Graph Model) 来存储和处理数据。与传统的关系型数据库相比,Neo4j 更擅长处理复杂关系型数据,特别适用于 关系密集型数据场景。 在很多业务系统中,数据之间往往存在大量关联关系,例如: * 社交网络中的好友关系 * 推荐系统中的用户与商品关系 * 知识图谱中的实体关系 * 网络安全中的攻击路径分析 在这些场景下,如果使用传统关系型数据库进行查询,往往需要大量 Join 操作,查询复杂度和性能都会迅速下降。而图数据库可以直接通过关系进行遍历,因此在处理复杂关系时效率更高。 收费模式 Neo4j Graph Database & Analytics – The Leader in Graph DatabasesConnect data as it’s stored with Neo4j. Perform powerful, complex queries at
3 min read

数据库分类

数据库可以从多个维度进行分类,不同的分类方式反映了数据库在数据模型、处理能力、部署方式、存储介质以及应用场景等方面的差异。理解这些分类,有助于在实际系统架构设计中选择合适的数据库方案 按数据模型分类 关系型数据库(RDBMS) 关系型数据库以表(Table)作为核心数据结构,通过行和列组织数据,并使用 SQL(Structured Query Language) 进行数据查询和管理。 不同表之间通过**主键(Primary Key)和外键(Foreign Key)**建立关系,从而实现复杂的数据关联查询。 特点: * 数据结构清晰,强约束 * 支持复杂查询(Join、聚合等) * 支持事务和 ACID 特性 * 适合结构化数据存储 典型数据库: MySQL、PostgreSQL、Oracle、SQL Server 等。 非关系型数据库(NoSQL) NoSQL(Not
4 min read

Mysql 时间四舍五入

MySQL的DATETIME类型是精确到秒的,而Java的LocalDateTime类型是精确到纳秒的。因此,在将MySQL的DATETIME类型存入Java的LocalDateTime类型时,会发生四舍五入的情况。 例如,如果MySQL的DATETIME类型为2022-01-01 12:34:56.789,当它被存入Java的LocalDateTime类型时,会被四舍五入到2022-01-01 12:34:57。 为了避免这种情况,可以使用Java的java.sql.Timestamp类型来存储MySQL的DATETIME类型。这个类型也是精确到纳秒的,与LocalDateTime类型匹配,不会出现四舍五入的问题。
1 min read

InnoDB 之 BufferPool 详解

BufferPool官方文档: MySQL :: MySQL 8.0 Reference Manual :: 15.5.1 Buffer Pool 在InnoDB存储引擎中,为了提高MySQL服务性能,减少磁盘IO次数,故此所有的DML操作均是在内存中的 BufferPool 中完成。最后通过服务的异步刷盘策略把修改数据落盘到磁盘中。 为什么需要设计 BufferPool ?这里我想一般有计算机基础知识的人都知道,内存和硬盘的效率是天差地别的,对于CPU来说硬盘的传输以及响应时间性能太低下,故此 MySQL 设计出了 BufferPool 来映射磁盘中的真实数据,并在内存中进行数据的管理与操作,这样执行DML语句的效率不就起飞了吗?至于是如何保障内存中的 BufferPool 数据在宕机,掉电的场景不会出现丢失(物理打击除外😃,大力出奇迹,硬盘都给你扬了),之前我的文章中也有所讲解: MySQL 执行链路当客户端SQL语句提交给 MySQL 服务器时首先需要建立连接,连接器会与客户端进行连接,并校验用户身份信息,权限信息,如果权限通过,则通过SQL分析器对SQL语句进行语义分
17 min read

MySQL 执行链路

前言 当客户端SQL语句提交给 MySQL 服务器时首先需要建立连接,连接器会与客户端进行连接,并校验用户身份信息,权限信息,如果权限通过,则通过SQL分析器对SQL语句进行语义分析(检查SQL语句是否合法,能否解析通过),分析完成后将会对SQL的执行过程进行优化,例如剔除不必要的查询条件 1=1 ,以及选择最优的索引与Where条件的字段排序。 然后交给执行器执行此SQL语句,执行器将会根据数据库所使用的存储引擎执行SQL。MySQL在设计时是分为了两层,即Server层和存储引擎层。这样做的好处就是解藕,可以根据不同的数据库去选择合适的存储引擎。 常用的InnoDB存储引擎是以页(16KB)为单位来管理存储空间的,任何的增删改差操作最终都会操作完整的一个页,会将整个页加载到 BufferPool 中并且所有的数据操作都是在 BufferPool 中完成,BufferPool 通常设置为服务器70%-80%左右的内存占用,这样数据的操作直接在内存中执行,从而提高数据操作的效率(如果每一条DML语句都要进行 IO 操作那么数据库的磁盘很容易变成瓶颈,改一条数据需要先从磁盘中读取,
11 min read

分布式事务之 Seata

前言   在企业应用程序开发中,随着分布式框架发展,我们生产环境会有会很多数据库的实例,特别是在微服务领域中,我们会设计每个业务Service模块都会对应一个自身业务模块的DB存储节点。然后再对这个DB存储节点做高可用部署。 事务问题   那么我们在编写Service中的业务逻辑时,肯定会遇到一个业务操作会远程调用到其他不同的业务模块,那么对应的产生数据就会落盘到不同的存储节点中,为了保障多个数据库实例之间的事物ACID特性,就遇到了分布式事务的问题。 分布式事务 1、如果整个业务调用链路均成功,那么整个调用链路对应的数据库做事物提交。 2、如果调用链路中抛出了异常,那么整个调用链路对应的数据库做回滚操作。 Seata 在Seata分布式事务解决方案中,一般有以下这些角色: RM (Resource Manager) 管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚。 TC (Transaction Coordinator) - 事务协调者 TM (Transaction Manager) - 事务管理器,AP上
7 min read

HBase介绍以及对比MongoDB

HBase全称:Hadoop Database。 HBase是一种高可靠性,高性能,面向列的可扩展分布式存储系统,使用HBase技术在廉价的PC服务器上构建大规模结构化存储集群。 HBase的目标是存储和处理大量数据,特别是仅使用标准硬件配置即可处理包含数千行和列的大量数据,可处理PB级别数据存储,亿级QPS查询。 它适用于实时性要求不高的业务场景,HBase存储Byte数组,该数组不介意数据类型,从而允许动态,灵活的数据模型。 架构解析: HBase由HMaster和HRegionServer组成,并且遵循主从服务器体系结构。 HBase将逻辑表分为多个数据块HRegion,并将它们存储在HRegionServer中。 HMaster负责管理所有HRegionServer。 它本身不存储任何数据,而仅存储数据到HRegionServer的映射(元数据)。 群集中的所有节点均由Zookeeper协调,并处理HBase操作期间可能遇到的各种问题。 HBase的基本架构如下所示: 客户端:使用HBase的RPC机制与HMaster和HRegionServer通信,提交请求并获得
13 min read

MySQL 事物死锁解析

在使用mysql数据库中,随着我们业务与功能模块的增加、数据库的事物数量会随之上升。在开发业务功能的场景中我们会经常开启事物操作数据,或者开启分布式全局事物操作数据时、事物过多,在并发进行的场景中往往会有几率产生事物死锁问题。 那么我们来分析一下事物死锁产生的原因: 两个 session 连接:一个session持有T1事物,另外一个session持有T2事物。 1.T1事物修改rows1 2.T2事物修改rows2 3.T2事物修改rows1 4.T2等待T1释放rows1的x锁 5.T1事物修改Rows2 6.T1等待T2释放rows2的x锁 7.相互等待死锁 死锁在没有外力的干扰下,程序本身无力解决此问题。 必须借助人为或者另外的守护线程来解决此死锁问题。 解决死锁的方法也很简单:释放其中一个事物,让其回滚即可。 但回滚有一个问题,回滚哪个事物更合理,mysql采用的是根据undo log 中谁的条数更多,谁的权重越大,则舍弃权重更小的事物进行回滚,可以更好解决事物死锁。让其回滚的数据量尽量减少,以减少服务的性能牺牲。 系统中任何一个事务发生死锁的概率
3 min read

MySQL 亿级数据导出excel文档

前言 公司SaaS系统需要给用户提供列表数据导出 excel 文档的功能。 但有的公司的列表数据如财务流水已经高达千万,亿级别,对于这样的数据导出,我们需要提出一个解决方案。不然在月底几百家公司进行导出excel,将会导致mysql QPS急剧上升,服务器cpu,ram,瞬间到达报警阀门。大批量导出可能会导致服务器不可用甚至面临宕机(提示:对于财务等敏感数据,需要做文件加密或者临时文件授权下载操作)。 具体方案 方案的出发点:大批量导出,不能影响正常业务运行。 单独部署一个数据库从库节点进行查询压力分担,再单独部署多组服务器跑上Springboot项目作为MQ的消费者集群,所有的导出请求均请求至MQ队列中,Springboot会采用拉模式主动拉取MQ队列中的导出Excel任务消息进行执行,合理的使用了MQ的削峰填谷以及异步功能。并在SpringBoot项目中严格分配线程池资源。 具体的任务消费者通过亿级分页方案分批量查询mysql列表数据,并使用ali easy excel api进行数据硬盘落盘,完成输出后上传oss(也可以使用oss内网流传输,直接传到oss文件系统中
4 min read

MySQL 亿级数据分页

随着公司业务增大,数据量也是随之剧增。MySQL作为一款社区免费开源数据库。想要用它做几百万的数据分页。光靠limit是不靠谱的。当然不是诋毁mysql,mysql作为开源插拔式存储引擎数据库,已经是可以满足绝大部分的应用场景需求。使用mysql管理100tb也不是问题。但是使用方式却是一个问题。 limit接受一个或两个数字参数。参数必须是一个整数常量。如果给定两个参数,第一个参数指定第一个返回记录行的偏移量,第二个参数指定返回记录行的最大数目。 limit在偏移量小于10w时性能还勉强可以接受,但随着偏移量越来越大,性能急剧下降。 公司单表账务数据已经到达230w ,做分页limt  来查询最后一页的数据,怕是没有个20秒是查询不出来的。当然具体的时间也要根据是否有索引,字段数量,数据内容而定,查询条件而定。 为了解决分页效率问题,我采用方案是: select id from table limit 100000,20 (带上where条件作为子查询) 由于主键id原本就是主键索引,所以limit的速度效率很高。并把条件字段加入复合索引,效率才会有质量的提升 。 但如
3 min read

随心笔记

技术无止境 创新不停驻