新一代HTAP数据库崛起,MySQL生态的最佳归宿?

CVAT实战:从零搭建高效数据标注流水线 本文详细介绍了如何使用CVAT搭建高效的数据标注流水线,从环境部署到团队协作,再到数据流转和质量把控,全面覆盖了数据标注的各个环节。CVAT作为一款开源的数据标注工具,支持多人协作和丰富的标注类型,特别适合遥感图像等复杂场景的标注需求。通过实战案例和技巧分享,帮助读者快速掌握CVAT的核心功能,提升标注效率。 阅读详情

俗话说,天下大势,合久必分、分久必合。

数据库领域同样如此。过去五十余年,数据库经历OLTP和OLAP两种需求漫长的融合-分离-再融合的过程。究其原因,数据库的发展始终与用户场景需求变迁紧密相关。如今,随着云计算和大数据的兴起,业务场景正在经历前所未有的变革,数据库领域也掀起了一股HTAP浪潮。

Gartner在多次报告中强调,HTAP是数据库领域最重要的发展趋势之一,也是用户数字化转型中重要的数据平台。业界甚至认为,HTAP的兴起代表着数据库大融合时代的开启。

那么,为什么数据库大厂和云服务巨头们均纷纷押宝HTAP?开源+多云为何是HTAP普及的助推剂?面对新一代HTAP数据的崛起,多年积累形成的MySQL生态终于找到最佳归宿?

HTAP数据库是新瓶装旧酒?

放在几年前,HTAP可能还会被认为是数据库领域的小众产品,是否成气候还有待观察。

而随着数据资源、数据消费习惯和数据驱动型场景发生巨大变化,用户需求与传统数据库之间的供需矛盾日渐突出,使得HTAP这种具备“同时支持OLTP和OLAP、创新计算存储框架、去ETL”等特征的新时代数据库成为不可阻挡的趋势。

如今,几乎所有数据库大厂和云服务巨头都在布局HTAP。例如,OceanBase去年推出的 3.0版本中就正式宣布向HTAP数据库进军;今年5月,Google Cloud发布HTAP云端数据库AlloyDB,为PG用户提供了HTAP数据库服务;再加上Oracle MySQL Heatwave,甚至连SnowFlake也发布Unistore来“蹭”HTAP的热点。

如果细数近一年以来的HTAP新品,会发现几乎全部都建立在云端之上。新一代HTAP+云正在成为数据库市场重要的潮流。例如,PingCAP近日发布的TiDB 6.0,也是与云端紧密联系的新一代HTAP数据库。

事实上,PingCAP是HTAP数据库领域非常重要的一个引领者。早在TiDB 3.0起,PingCAP就正式转向HTAP,从OLTP主引擎+OLAP辅助能力,到OLTP引擎+外接分析引擎,再到OLTP引擎+融合分析引擎,PingCAP在HTAP领域稳打稳扎,一个版本上一个台阶。

如今,随着TiDB 6.0的发布,针对HTAP进行了更多成熟性改进,TPC-C 性能也较 5.0 版本提升达到 76.32%,TiDB 6.0还增强了多个企业级特性,以更好适合云时代用户对于HTAP数据库的需求。

固然,有人质疑当前HTAP是新瓶装旧酒,并无太多新意。但业界普遍形成共识:新一代HTAP与过去完全不同,开源+云孕育而出,很多都有AI加持,而且是为数据敏捷而生,拥有过去前所未有的创新活力与迭代速度,并逐渐形成数据库技术变革的新潮流。

PingCAP CTO 黄东旭也直言:“TiDB近年来的快速进化与迭代,得益于开源和云的助力。”

开源+云,数据敏捷的助推剂

HTAP之所受到用户青睐,某种程度是因为用户对于数据敏捷性的极度渴求。

“在数字化时代,客户最为在乎的是如何快速走向市场。这需要数据敏捷性,而HTAP恰恰是数据敏捷的核心能力。”黄东旭如是说。

最近几年,“海量、实时、在线”的需求越来越广泛,大量采用 MySQL 和 PostgreSQL 开源数据库的新一代企业需要提升对于热数据的实时在线分析能力,这类需求遍布几乎所有的互联网企业以及从事线上业务的数字化转型企业。对于新鲜数据的实时分析能力直接决定了这些业务的生死存亡,传统的 OLTP+OLAP+ETL 的数据架构已经严重阻碍了消费者体验,这种诉求催生了 HTAP 的技术变革。

而真正帮助HTAP与用户需求完成对接的则是开源+云。众所周知,开源近年来在数据库领域的流行和影响力与日俱增,DB-Engines数据显示,全球383款数据库中开源数据库占据51.7%,六款开源数据库进入到前十,开源正在成为像HTAP这种新时代数据库的创新源泉。

以PingCAP的TiDB为例,其产品研发体系建立在开源体系和开源社区的基础上,实现了一年一个大版本、一个月一个小版本的迭代速度。黄东旭透露道:“开源是TiDB的第一个增长引擎,通过开源体系,开发者、贡献者、布道者和用户能够很好串联起来,形成飞轮效应,让产品能够走向加速迭代和创新的正向循环。”

据悉,TiDB每年会有超过 40% 的代码更新,而这些代码有很大一部分由外部贡献者所共享。TiDB开源项目一直在全球和中国开源项目活跃度中名列前茅。

如果说开源改变了HTAP产品的开发模式和迭代速度,那么云则能够为HTAP产品提供用户最为直接的需求反馈。众所周知,云数据库一改以往传统数据库部署、运维、扩展等难题,以云服务的方式让数据库使用更加简单;更加关键的是,随着云计算的普及,云上用户群体持续增加,来自云上用户群体的需求反馈无时无刻都在发生,对于数据库产品的进化与迭代至关重要。

“真正的产品迭代是如何缩短用户问题/需求的反馈时间。云无疑为数据库等基础软件提供了这样的价值,让产品可以更好地迭代。”黄东旭如是说。以TiDB为例,自去年五月全托管的数据库即服务(DBaaS)产品 TiDB Cloud 公测版发布以来,已经陆续登陆亚马逊云科技、谷歌云等全球知名云服务商的Marketplace,并在今年5月份正式全球商用;今年 6 月与阿里云合作上线阿里云云市场,成为为数不多的跨全球三朵云的数据库服务。

新一代HTAP数据库:MySQL生态的最佳归宿?

在众多数据库产品之中,MySQL凭借着开源、免费、适合互联网场景等优势,常年位居全球最受欢迎数据库的前三。根据Slintel网站的统计数据,在全球关系型数据库市场中,MySQL市场份额最高,达到43.04%。

过去二十年里,开源MySQL数据库对于各行各业影响至深,捕获了来自互联网、金融、零售、交通等多个行业用户的心,堪称“万人迷”。例如,在中国就有超过9成的金融机构都应用了MySQL数据库。

但任何数据库潮流都是“需求变化+技术变革+架构创新”融合的产物,MySQL是如此,HTAP亦不例外。如今,场景的数据规模、业务并发量、处理速度要求跟以往相比早已不是一个数量级。此时,MySQL数据库的局限性愈发突出,扩展性很难满足用户需求,想继续获得增长的企业不得不使用分库分表方案,但这又会造成数据架构的复杂性。

新一代HTAP数据库无需分库分表,且具备实时海量规模的OLTP和实时数据分析能力,还拥有极为出色的扩展性,与很多业务场景的海量交易实时数据展现、平稳运行的需求高度契合,HTAP凭借技术架构优势崛起已成必然。

“用户需求侧最大的变化就是很多用户需要借助热数据实现运营级别的实时分析,获得实时洞察以支持决策,这极大推动了新一代HTAP数据库的需求。”PingCAP副总裁刘松补充道。

虽然MySQL已经增加列存引擎Heatwave来获得HTAP能力,但主要解决规模化查询的问题,系统本身架构并未产生革命性变化,扩展能力、OLTP吞吐量依然有着很大局限。“智能新能源汽车跟传统燃油车在外表看几乎没区别。数据库也类似,像TiDB这种新一代HTAP数据库,从架构设计、应对场景和使用体验等角度,都与传统数据库有着极大的区别。”刘松形象比喻道。

事实上,与过去SAP HANA这种小众、昂贵的HTAP不同,新一代HTAP拥有极强的兼容性,像Google Cloud、PingCAP这些数据库厂商都借助新一代HTAP架构为采用 MySQL或者PG开源数据库的企业拓展 OLTP和OLAP的能力范围。

例如,Google Cloud发布的HTAP云端数据库AlloyDB,为单机版PG生态用户提供了最好选择,TiDB则成为MySQL生态的最佳归宿。PingCAP大量用户中有很多TiDB与MySQL混合部署的成功案例;得益于 TiDB 的开放性,TiDB 也可通过和其他数据服务产品“混搭”形成新的数据服务解决方案, 如通过同样是开源的大数据计算引擎 Flink 混搭形成实时数仓解决方案,扩展 HTAP 数据库的能力边界。

图:早期TiDB与MySQL并存

黄东旭则直言,HTAP数据库除了产品、技术之外,尤为需要关心用户体验,“HTAP应该让用户觉得好用,屏蔽掉数据库的复杂性。”据悉,PingCAP是2022 Gartner Peer Insights“Voice of the Customer” 云数据库领域唯一入选的中国数据库公司,客户总体评分达到 4.7 分(满分 5 分),在所有入选企业中位列第一。在参与Gartner Peer Insights评分的PingCAP用户中,像互联网、金融等重点行业用户均高度认可HTAP现代数据库理念。

总体来看,今年是HTAP的大年,各大厂商纷纷在市场中上新。随着新一代HTAP数据库产品的增多,整个市场对于HTAP数据库理念和产品的接受与采用将会提速。而随着新一代HTAP数据库持续完善,让广大MySQL生态用户群真正看到了大数据时代一条绝佳的迁移路径。

Nacos启动报错No DataSource set?5分钟搞定standalone模式配置 本文针对Nacos启动时常见的“No DataSource set”报错,深入解析了其根源在于默认集群模式与外部数据库依赖。提供了两种快速解决方案:通过命令行参数“-m standalone”启动,或直接修改启动脚本配置文件,从而在5分钟内以单机模式成功启动Nacos,无需配置MySQL数据库 阅读详情

相关推荐

7 series FPGAs Transceiver Wizard IP核使用和测试

学习FPGA一段时间了,前面一直没有系统的总结,这学期把在项目中用到的IP核和一些调试过程中遇到的问题总结一下发出来,坚持下去,一起进步! 今天总结一下的GTH核的使用和测试。 软件版本:Vivado 2017.4 IP核版本:7 Series FPGAs Transceivers Wizard (3.6) FPGA:xc7vx690tfft1927 实现功能: 四路光纤数据接收,由于GTX IP...

qq_39921762的博客 1万+

新一代HTAP数据库崛起MySQL生态最佳归宿?

新一代HTAP数据库:开启数据库融合的大时代!

大数据在线 802

OpenClaw进阶实战(二十三):微信公众号接入——被动回复、客服消息、素材管理

本文介绍了将OpenClaw接入微信公众号的完整方案,重点包含以下内容: 接入方案选型:对比官方插件、三方服务和自建中转三种方式,选择自建Node.js中转服务实现灵活控制 核心原理:通过中转服务器完成微信消息协议转换,处理5秒超时限制和异步回复机制 实战开发: 搭建Express中转服务 实现Token管理和消息处理 采用内存缓存对话历史 通过客服接口异步回复 官方插件方案:介绍2026年发布的ClawBot插件,支持文本/图片/文件收发 进阶功能:包括素材管理接口调用示例 该方案适用于需要深度定制公众号

PeterPan的博客 113

泛微E10动作流定时更新数据库表单全量数据

以上就是两个动作流的基本配置第一个动作流对外定时发送页数,第二个动作流来监听第一个动作流发送的参数并且对数据库表单进行更新,这样一个简单的定时更新数据库表单的定时任务就处理好了。

月与清酒的博客 256

Go 后端常见权限问题完整整理

后端常见权限问题完整整理

weixin_51380508的博客 398

redis的持久化

机制一句话概括RDB定时拍内存快照,恢复快、文件小,但可能丢数据AOF记录每条写命令,数据安全、可实时持久化,但文件大、恢复慢混合AOF 重写时前半段用 RDB、后半段用 AOF,兼顾两者优点核心选择逻辑能丢数据 → RDB不能丢数据 → AOF(everysec)又要快又要安全 → RDB + AOF 混合。

qq_31532983的博客 332

PostgreSQL 生产环境迁移与冷启动优化:利用 pg_prewarm(dump) 与 OS Page Cache 实现双层缓存无感预热

未命中的大范围查询直接穿透到底层磁盘,需要在操作系统层面将核心表及索引文件直接读入 Linux Page Cache。代表成功导出了约 393 万个 8KB 数据块(对应约 30GB 的缓存状态)。该文件默认生成在源库的数据目录。在数据库日常运维与大型变更中,最让 DBA 和基础架构团队头疼的问题之一就是。PostgreSQL 的读写架构并非只依赖自身的数据库内存,而是深度依赖。或网络同步工具将文件复制到目标库对应的。重启数据库后,后台守护进程。在目标库宿主机终端(使用。在 Linux 终端执行。

情深深几许 392

一条 SQL 顶一条 Flink 链路?Doris Streaming Job 持续导入全景解析

Streaming Job 的意义不在于"又多了导数方式",而在于 Doris 把**数据接入**这件事的默认形态从"搭一条外部管道"变成了"发一条 SQL"。对于大量只需要镜像同步 + 轻量加工的实时数仓场景,架构里可以直接少掉 Kafka 和 Flink 两层。

一入大数据深似海?别怕!“数据极客圈”就是你的救生圈,走对圈子跟对人,趣析数据、畅聊趋势,快进圈子! 247

IoC 实战:从控制反转到依赖注入容器

当一个长生命周期的服务依赖了一个短生命周期的服务,短生命周期服务被"俘虏"在长生命周期的作用域中,无法及时释放——这就是 Captive Dependency(俘虏依赖)。// ❌ 经典错误:Singleton 依赖 Scoped// ❌ 经典错误:Singleton 依赖 Scoped builder . Services . AddSingleton < ICacheWarmer , CacheWarmer >();

a15242316443的博客 210

MySQL 5.7 在 CentOS 7 环境安装:从清理 MariaDB 到初始化与完善配置

MySQL 官方提供了适用于 Linux 系统的 Yum 存储库,这些存储库包含了预编译的 MySQL 软件包及其所有依赖项 为什么要使用 Yum 安装 MySQL? 自动解决依赖关系:Yum 会自动解析并安装 MySQL 运行所需的所有依赖库 版本管理便捷:可以直接通过 Yum 命令升级或降级 MySQL 版本 标准化配置:官方 Yum 源中的 MySQL 包已经针对特定 Linux 发行版进行了优化 2.2 下载 MySQL 官方 Yum 源 访问 MySQL 官方 Yum 存储库页面 MySQL 官方

枫亭湖区的博客 286

MySQL 慢查询排查实战】列表接口逐渐变慢时,怎样从请求链路定位原因

本文以可复现的订单列表查询为例,从请求分段计时、实际 SQL、EXPLAIN、联合索引、查询字段和深分页逐步定位性能问题,并严格区分 MVCC 一致性读、锁定读与元数据锁等待。

2402_87731470的博客 1208

Selenium | Edge 手动驱动完整版教学

适用场景:网络不佳,Selenium自动下载驱动失败,搭配 Edge 浏览器运行。

qq_51372804的博客 271

Python 3.9 · Flask 火灾监测识别系统 与 钉钉告警机器人 集成说明文档

本文介绍如何将钉钉群机器人告警功能集成到基于Python 3.9和Flask的火灾监测系统中。主要内容包括:系统架构设计(YOLOv11检测火灾/烟雾后触发钉钉告警)、环境配置说明、钉钉机器人创建与安全设置(推荐使用加签验证)、钉钉推送模块代码实现(支持重试机制)、Flask后端集成改造方法,以及告警去重与冷却控制机制。文档提供了完整的实施步骤,从环境准备到测试验证,并包含常见问题解答和进阶功能建议(如图片告警)。该方案实现了火灾检测的实时预警功能,同时避免了消息刷屏问题。

isoft888的专栏,致力于C#/python分享物联网、大数据,神经网络的等领域,欢迎讨论交流! 271

Redis 性能优化基本设置

(Jedis 默认)时,低峰或刚启动后池内无连接,请求需现场建连,首包延迟高。超过时,归还的多余连接会被销毁。在 borrow 不做检测的前提下,由后台线程周期性清理死连接。(无限等待)会导致线程在池满时长时间阻塞,级联拖垮业务线程池。的超时(connect timeout),与命令读写超时分开。创建频率低,一次 PING 可尽早发现连到坏节点,成本可接受。设为相同值(如均为 64),池规模稳定,行为可预期。:连接空闲超过该时长后,才可能被驱逐线程检测并回收。:连接池耗尽时,调用方等待获取连接的最长时间(

X-Dragon的博客 226

家政派单系统开发实战:架构设计与派单算法指南

家政派单系统是连接用户需求与上门服务人员的核心调度平台,其开发难点并不在于简单的CRUD,而是在于如何设计一套能支撑“多角色、多任务类型、高并发抢单”的架构,以及一套能让订单和师傅效率化的派单算法。一旦师傅手动拒绝系统派单,近1小时的接单权重下降50%,防止师傅只接高价单而忽略普通单,导致用户体验受损。建议优先搭建一个可配置化的规则引擎,将派单距离、服务类目、师傅等级做成后台可调整的配置项,这样后期运营调整策略时,无需修改代码。师傅接单后的轨迹追踪,是提升用户体验的关键,也是开发的难点。

zww8949111的博客 321

Helm Chart依赖管理实战

在kind: Podmetadata:spec:关键注解说明:标记为测试 Hook:测试成功后自动删除 Pod。

m0_52572472的博客 223

dify4: test-doc

摘要 本文档包含两部分内容:1) MySQL数据库表结构定义,用于学校管理系统,包括教师表(teachers)和学生表(students),其中学生表通过外键关联教师表;2) 一个数据库查询助手的角色定义和操作规范,要求严格基于知识库内容回答,禁止推测或虚构信息,仅生成SELECT查询语句,并提供结构化回答格式。助手需遵循"绝对忠于知识库"等核心原则,对未知内容需明确回复无相关说明。

arno1988的专栏 239

PostgreSQL笔记11:安装部署阶段常见问题排查与解决方案

PostgreSQL数据库启动常见问题及解决方案摘要: 权限问题:数据目录权限需严格为0700,避免安全风险。 端口冲突:默认5432端口被占用时需修改配置或终止冲突进程。 监听配置:listen_addresses需调整以允许远程连接,配合pg_hba.conf使用。 内存不足:合理设置shared_buffers(建议25%内存)和max_connections,避免共享内存超限。 系统索引损坏:通过ignore_system_indexes启动并执行REINDEX修复损坏的系统表索引。 日志分析:优先

Wang的专栏 565

Mysql数据库3

DBA 用来定位性能瓶颈:监控 SQL 耗时、锁等待、IO 消耗、线程状态、内存占用,排查慢查询、锁冲突、资源竞争问题,做数据库性能调优。系统表空间保存 InnoDB 数据字典、double‑write buffer、change buffer、undo 日志(旧版本),还可以存放用户表数据。:多个表共用同一个表空间文件;适合大多数业务表,表数量多、需要单独迁移表、删除大表释放磁盘空间的场景。同一个文件内部,靠后的组配置覆盖前面组的相同选项,后加载配置优先级更高。数据文件,多张表可以存放在这同一个文件内。

2401_87749679的博客 170

内网渗透横向移动实战:从初始 foothold 到域控的完整路径

在企业安全建设与红蓝对抗日益激烈的今天,内网渗透已经成为安全研究人员必须掌握的核心技能。攻击者在外网拿到一个初始立足点(foothold)之后,真正的挑战才刚刚开始:如何在复杂的内网环境中横向移动、逐步提权、最终拿下域控,是衡量一名渗透测试工程师水平的关键指标。横向移动(Lateral Movement)是指攻击者在内网中从一台主机移动到另一台主机,从普通权限提升到高权限,从单个工作组环境扩展到整个 Active Directory 域环境的过程。

2601_96636382的博客 179

AI算法系列(3)| 实时数据管道:CDC+Flink实现库存异动秒级响应

本文从架构、实施、优化等方面介绍了CDC+Flink构建库存实时数据管道的方法。该方案将数据库变更日志直接转化为流数据,结合Flink的实时计算能力,为企业提供了低延迟、高可靠的库存异动响应能力。相比传统轮询,它实现了从“秒级延迟”到“毫秒级捕获”的跨越,同时具备完整变更语义和Exactly-Once保障。随着企业AI化转型的深入,实时数据管道将成为智能决策的基础设施。未来,结合机器学习预测库存需求、自动补货、智能风控等AI能力,有望进一步提升供应链效率。

CIO_Alliance的博客 243

零停机数据库演进:Spring Boot 集成 Flyway 与平滑DDL变更策略

线上数据库变更最怕DDL操作引发连接池打满、主从延迟飙升等问题。本文拆解了Spring Boot+Flyway的平滑DDL变更方案,指出MySQL DDL本质是物理页重构,分析了COPY/INPLACE/INSTANT三种算法的适用场景。生产环境的关键在于采用"扩-迁-收"的并行变更策略:先兼容性扩展结构,再双写迁移数据,最后清理冗余字段。同时强调Flyway脚本需与应用发布解耦,通过独立Job执行,并配置严格的发布检查清单和熔断机制。文中还总结了典型故障案例,如大表加索引阻塞连接池、主从延迟导致字段不可见

专注分享原创技术干货。大厂资深架构师,多年技术架构与技术管理经验,多年面试官经验。一对一技术指导培训,带你从小白到入门到架构设计到技术管理。关注我,免费领取学习资料。一对一免费面试指导,快速拿offer。 343

基于LabVIEW和S7-300 PLC的液压机监测系统设计.pdf

#资源达人分享计划#

sqlmap图形化界面工具

sqlmap图形化界面工具

上一篇: 面试官:完全背包都不会,是你自己走还是我送你?
下一篇: 这么卷吗?公司新来的00后工作没两年,跳槽到我们公司起薪18K,都快接近我了
java界泥石流
博客等级 码龄5年 53粉丝 · 40原创
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值