惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

GbyAI
GbyAI
博客园_首页
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
阮一峰的网络日志
阮一峰的网络日志
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园 - 司徒正美
V
V2EX
Cloudbric
Cloudbric
Hugging Face - Blog
Hugging Face - Blog
腾讯CDC
量子位
博客园 - 三生石上(FineUI控件)
博客园 - 叶小钗
K
Kaspersky official blog
博客园 - 【当耐特】
T
Tenable Blog
L
Lohrmann on Cybersecurity
The Cloudflare Blog
S
Schneier on Security
A
Arctic Wolf
Latest news
Latest news
C
Cyber Attacks, Cyber Crime and Cyber Security
罗磊的独立博客
T
The Exploit Database - CXSecurity.com
Cisco Talos Blog
Cisco Talos Blog
小众软件
小众软件
P
Privacy & Cybersecurity Law Blog
WordPress大学
WordPress大学
Simon Willison's Weblog
Simon Willison's Weblog
雷峰网
雷峰网
NISL@THU
NISL@THU
人人都是产品经理
人人都是产品经理
月光博客
月光博客
J
Java Code Geeks
V
Visual Studio Blog
S
Security Affairs
博客园 - Franky
T
Tailwind CSS Blog
Apple Machine Learning Research
Apple Machine Learning Research
H
Heimdal Security Blog
有赞技术团队
有赞技术团队
V2EX - 技术
V2EX - 技术
AWS News Blog
AWS News Blog
G
GRAHAM CLULEY
T
Troy Hunt's Blog
SecWiki News
SecWiki News
Spread Privacy
Spread Privacy
宝玉的分享
宝玉的分享
www.infosecurity-magazine.com
www.infosecurity-magazine.com
博客园 - 聂微东

阮一峰的网络日志

科技爱好者周刊(第 396 期):互联网通信的替代方案 科技爱好者周刊(第 396 期):互联网通信的替代方案 - 阮一峰的网络日志 科技爱好者周刊(第 395 期):软件开发的第三种方式 科技爱好者周刊(第 395 期):软件开发的第三种方式 - 阮一峰的网络日志 科技爱好者周刊(第 393 期):脑腐状态 科技爱好者周刊(第 392 期):axios 投毒与好莱坞式骗术 科技爱好者周刊(第 391 期):AI 的贫富分化 科技爱好者周刊(第 390 期):没有语料,大模型就是智障 套壳中国大模型撑起500亿美元估值?扒一扒 Cursor 的"套壳"疑云 科技爱好者周刊(第 389 期):未来如何招聘程序员 科技爱好者周刊(第 388 期):测试是新的护城河 零安装的"云养虾":ArkClaw 使用指南 科技爱好者周刊(第 387 期):你是领先的 科技爱好者周刊(第 386 期):当外卖员接入 AI 字节全家桶 Seed 2.0 + TRAE 玩转 Skill 科技爱好者周刊(第 385 期):马斯克害怕中国车企吗? 智谱旗舰 GLM-5 实测:对比 Opus 4.6 和 GPT-5.3-Codex 科技爱好者周刊(第 384 期):为什么软件股下跌 科技爱好者周刊(第 383 期):你是第几级 AI 编程 Kimi 的一体化,Manus 的分层 科技爱好者周刊(第 382 期):独立软件的黄昏 AI native Workspace 也许是智能体的下一阶段 科技爱好者周刊(第 381 期):中国 AI 大模型领导者在想什么 科技爱好者周刊(第 380 期):为什么人们拥抱"不对称收益" 科技爱好者周刊(第 379 期):《硅谷钢铁侠》摘录 我如何用 AI 处理历史遗留代码:MiniMax M2.1 升级体验 科技爱好者周刊(第 378 期):预测是新的互联网热点 科技爱好者周刊(第 377 期):14万美元的贫困线 科技爱好者周刊(第 376 期):太空数据中心的争议 科技爱好者周刊(第 375 期):一扇门的 Bug 终于有人做了 Subagent,TRAE 国内版 SOLO 模式来了 科技爱好者周刊(第 374 期):6GHz 的问题 VS Code 使用国产大模型 MiniMax M2 教程 科技爱好者周刊(第 373 期):数据模型是新产品的核心 国产大模型接入 Claude Code 教程:以 Doubao-Seed-Code 为例 科技爱好者周刊(第 372 期):软件界面如何设计 大模型比拼:MiniMax M2 vs GLM 4.6 vs Claude Sonnet 4.5 科技爱好者周刊(第 371 期):一个乐观主义者的专访 科技爱好者周刊(第 370 期):正确的代码高亮 错误处理:异常好于状态码 科技爱好者周刊(第 369 期):Tim 与罗永浩的对谈 科技爱好者周刊(第 368 期):不要这样管理软件团队 一天之内,智谱和 Anthropic 都发了最强编程模型 科技爱好者周刊(第 367 期):Nano Banana 的几个妙用 科技爱好者周刊(第 366 期):旧金山疯狂的 AI 广告 科技爱好者周刊(第 365 期):流量变现正在崩塌 科技爱好者周刊(第 364 期):最难还原的魔方 科技爱好者周刊(第 363 期):最好懂的神经网络解释 科技爱好者周刊(第 362 期):GitHub 工程师谈系统设计 科技爱好者周刊(第 361 期):暗网 Tor 安全吗? 科技爱好者周刊(第 360 期):Dan Wang 的新书 科技爱好者周刊(第 359 期):Palantir 值得关注 科技爱好者周刊(第 358 期):如何拯救一家濒临倒闭的创业公司 扣子空间网页设计,是在挑战 V0 吗? 《唐纵日记》摘录 科技爱好者周刊(第 357 期):稳定币的博弈 科技爱好者周刊(第 356 期):公司强推 AI 编程,我该怎么办 科技爱好者周刊(第 355 期):两本《芯片战争》 科技爱好者周刊(第 354 期):8000mAh 手机电池,说明了什么? 科技爱好者周刊(第 353 期):苹果的"液态玻璃"是为了 AR 科技爱好者周刊(第 352 期):Bug 追踪系统的正确样子 科技爱好者周刊(第 351 期):GitHub Issues(几乎)是最好的笔记应用 科技爱好者周刊(第 350 期):Java 三十周年 科技爱好者周刊(第 349 期):神经网络算法的发明者 科技爱好者周刊(第 348 期):李飞飞,从移民到 AI 明星 科技爱好者周刊(第 347 期):冷启动的破解之道 科技爱好者周刊(第 346 期):未来就是永恒感的丧失 科技爱好者周刊(第 345 期):HDMI 2.2 影音可能到头了 科技爱好者周刊(第 344 期):制造业正在"零工化" 科技爱好者周刊(第 343 期):如何阻止 AI 爬虫 科技爱好者周刊(第 342 期):面试的 AI 作弊----用数字人去面试 科技爱好者周刊(第 341 期):低代码编程,恐怕不会成功 科技爱好者周刊(第 340 期):技术炒作三十年 科技爱好者周刊(第 339 期):代币是什么 科技爱好者周刊(第 338 期):重新思考 6G 科技爱好者周刊(第 337 期):互联网创业几乎没了 科技爱好者周刊(第 336 期):面对 AI,互联网正在衰落 科技爱好者周刊(第 335 期):年底的未来已来 科技爱好者周刊(第 334 期):年终笔记四则 科技爱好者周刊(第 333 期):一切都要支付两次 科技爱好者周刊(第 332 期):西蒙·威利森的年终总结,梁文锋的访谈 科技爱好者周刊(第 331 期):你可能是一个 NPC 科技爱好者周刊(第 330 期):李开复梳理人工智能 科技爱好者周刊(第 329 期):示意图利器 D2 科技爱好者周刊(第 328 期):AI 模型不是一门好生意 科技爱好者周刊(第 327 期):没有链接的互联网 科技爱好者周刊(第 326 期):世界没有那么多财富 科技爱好者周刊(第 325 期):VS Code 编辑器的下一站是 Zed? 科技爱好者周刊(第 324 期):人类已知的最大质数 科技爱好者周刊(第 323 期):技术公司的口号比拼 科技爱好者周刊(第 322 期):内容行业的内幕 科技爱好者周刊(第 321 期):傅盛回忆录 科技爱好者周刊(第 320 期):乒乓仓 科技爱好者周刊(第 319 期):如何拍出爆款视频 科技爱好者周刊(第 318 期):创业咖啡馆的记忆 科技爱好者周刊(第 317 期):驴子、老虎和狮子的寓言 科技爱好者周刊(第 316 期):你一生的故事 科技爱好者周刊(第 315 期):一份谷歌离职报告 科技爱好者周刊(第 314 期):《黑神话:悟空》可以产业化吗? 科技爱好者周刊(第 313 期):如果新加坡没有空调
分布式数据库入门:以国产数据库 TDSQL 为例
阮一峰 · 2024-05-29 · via 阮一峰的网络日志

一、简介

今天,跟大家分享一些企业级的互联网技术。

我要介绍的就是分布式数据库(distributed database)。我尽量用通俗的语言,说清楚它的概念、产品和用法,文末还会提供学习资料下载。

分布式数据库堪称最重要的数据库,几乎所有你知道的大型互联网服务,都运行在它之上。

平时,我们自己开发,接触的都是单机数据库(又称集中式数据库),就是数据库只运行在一台服务器上。

(图片说明:左侧的单个数据库服务器,支撑着整个应用。)

分布式数据库指的是,数据库系统分布在多台服务器。

(图片说明:单个数据库分布在多台服务器上,共同支撑应用。)

在宏观层面,金融、电信、航空、物流、电商等国民经济的重要产业,都离不开分布式数据库。

如果没有它,我们很难想象生活会变成什么样,比如12306那样的购票网站,就没法提供服务了。

在个人层面,当你从初级开发者成长为大型项目的架构师,就多多少少会遇到分布式数据库。

设计架构时,除非只用一台服务器,否则就免不了要考虑,数据在多台服务器之间如何拆分和保存。

总之,产品做大以后,分布式数据库是避不开的。对于个人来说,这也意味着事业和能力的进步。

二、分布式数据库的优点

分布式数据库为什么那么重要?因为它有一些单机数据库无法比拟的优点。

(1)更安全。分布式数据库包含多个节点,不管是放在同一个机房,还是不同机房,都要比单机数据库安全得多。

(2)高可用。如果单个数据库节点故障下线,其他节点还可以照常工作,不会单点失败。

(3)性能更好。对于大数据、大计算量的任务,分布式数据库可以并行处理,大大缩短处理时间。

(4)体验更好。当数据库分布在多个机房,可以为用户分配就近的数据库节点,提供更好的响应速度。

三、分布式数据库的难点

虽然有上面这些优点,但是分布式数据库的使用并不普及,小公司一般不用它,这是为什么?

主要原因是,分布式数据库有两大问题,阻碍了它的普及:成本高和复杂性。

分布式数据库属于"异地多活",提供了额外的冗余性,来保障数据安全,成本高自不必多言。

它的复杂性主要体现在下面几点。

(1)一致性问题。如何保证不同节点的数据一致?如果节点的数据不一致怎么办?

(2)通信问题。怎样保证节点之间的通信可靠?如果通信延迟或失败怎么办?

(3)分区问题。如果拆分大型数据表,数据储存在不同的节点,那么拆分策略、节点间的数据迁移可能会非常复杂。

(4)优化问题。如果来自多个节点的数据需要组合,查询就必须优化以提高性能。

四、CAP 定理

大家可能知道,有一条著名的 CAP 定理,说的就是分布式系统(包括分布式数据库)无法克服的局限性。

分布式系统有三大目标----数据一致(Consistency)、高可用(Availability)、数据分区(Partition tolerance)。

CAP 定理告诉我们,三大目标无法同时满足,最多只能同时做到两个。在数据分区的前提下,要么为了(强)一致性,舍弃高可用;要么为了高可用,舍弃(强)一致性。

因此,任何分布式数据库都做不到完美,只能是三大目标的某种取舍和均衡。

五、分布式数据库的产品

分布式数据库的历史非常悠久,市场上至少有上百种产品,有开源的,也有闭源的。

几乎所有的分布式数据库,既可以单机使用(即作为单机数据库),也可以多机联合,分布式使用。因此,很多我们熟悉的单机数据库,其实也是分布式数据库。

开源的分布式数据库,比较有名的是 Postgres 和 MySQL(关系型数据库),以及 MongoDB 和 CockroachDB(非关系型数据库)。

商业数据库里面,最有名的就是 Oracle。它是分布式数据库事实上的标准,大企业一般都选择用它。

六、国产数据库 TDSQL

下面,我选择国产数据库 TDSQL 作为示例,介绍分布式数据库的功能和用法。

TDSQL 是腾讯的产品,属于国内领先的分布式数据库。腾讯的几乎所有关键业务,比如微信、QQ、腾讯音乐、腾讯游戏等等,都运行在它之上,经受了高强度、海量的实战考验。

外部很多大公司也在用它,比如小红书、拼多多、B 站、海尔、深圳地铁等等。

它完全按照金融级的标准打造,属于金融级数据库,注重安全、高可用、高并发,客户目前超过50万。在国内金融行业,它服务 TOP10 银行中的7家,已经助力30余家金融机构的核心系统改造。

TDSQL 是完全的国产数据库,特别强调 Oracle 的兼容,企业现有的 Oracle 数据库可以平滑迁移,它的成本要比 Oracle 低很多。如果国内企业有国产化和供应链安全的考虑,它是很好的替代品。

它的产品能力和自主研发,通过了国家认证(《中国信息安全测评中心的安全可靠测评结果公告(2023年第1号)》),对于国有企业的技术选型,这也是很重要的考虑之一。

最后,TDSQL 是腾讯云对外公开的一个服务,任何人都可以使用。只要在网页上点击几下,就开通了,非常容易上手。

七、分布式数据库的功能

我们通过 TDSQL,看看分布式数据库有哪些功能。

(1)强同步复制。分布式数据库往往采用主从式架构,一个集群有一个主节点(master)和若干个从节点(slave)。系统支持节点之间的强同步复制,以保证数据一致。

具体来说,写入数据时,主节点会等待从节点返回操作成功消息,然后才向用户返回结果,这样保证了主节点和从节点的数据完全一致。

(2)事务一致性。系统为每一笔事务提供全局唯一数字序列,每个节点都可以查询事务的执行情况,保证在分布式环境下的事务一致性。

(3)自动拆分。分布式数据库的大型数据表,往往需要进行拆分,储存在不同的节点。TDSQL 支持自动水平拆分(分表),将数据均匀写入到不同节点,查询时也自动聚合返回。

对于用户来说,分表是透明的,完全可以无视,业务端看到的就是一张逻辑完整的表,无需感知后端的分表细节。

(4)高度可扩展。当数据库性能或容量不足时,TDSQL 可以不停机扩展,只需在控制台点击,就可自动升级完成。系统内的数据迁移、数据均衡和路由切换,都是自动的。

(5)高度灵活性。用户可以在线变更表结构;遇到某些类型的故障,系统可以自动恢复;所有节点,不管是主节点还是从节点,都可进行读写。

(6)产品管控能力。TDSQL 对开发者友好,提供大量监控工具,实时监控和告警,每日推送详细的健康探查报告。

腾讯云有一个专门的云服务 DBbrain,利用机器学习、大数据、专家经验引擎等手段,为用户的数据库提供性能、安全、管理等功能。

比如,它会全方位诊断和优化 SQL,发现性能瓶颈,让 SQL、事务、业务流水全链路可观测,可视化展现死锁等异常,易于理解。

它很大程度上了替代了人工 DBA,将传统的人工运维变成智能化服务。

TDSQL 还有一个 AI 智能问答系统(下图)。它基于知识库与小模型训练,快速准确地响应用户查询,相当于一个智能客户,提供专业且个性化的解答。

八、TDSQL 的用法

下面,我来演示一下 TDSQL 的用法,很简单,在网页上开通后,你就可以使用分布式数据库了。

第一步,在 TDSQL 的官网上,进入产品控制台。

第二步,在控制台页面,选择数据库服务器所在的地域(跟你的云服务器应该是同一个地域),以及数据库引擎,然后点击"新建"按钮。

目前 TDSQL 有三种引擎:MySQL、自研的 TDStore 和 PostgreSQL。不管哪一种引擎,都具备一样的容灾能力和高可用,并且兼容 Oracle。

第三步,会跳出一个配置页面,让你选择数据库配置。不同的配置,价格不一样。

其中有一项,问你要不要开通"强同步"。

强同步可以确保主节点和从节点的数据一致性。如果你的应用不要求强一致,更在意快速返回结果,这里可以选择"异步"。

第四步,配置完成后,会进入付款环节,然后数据库就开通了,你的分布式数据库就已经在线了。

使用时,需要先连接数据库,分成内网连接和外网连接,这里可以参考文档。需要注意,如果开通外网连接,数据库就暴露在公网上,任何人都可以请求,必须注意安全风险。

连接数据库以后,就可以执行 SQL 语句了,到了这一步,就跟使用普通数据库没有任何区别。分布式数据库的 SQL 与单机数据库,基本是一样的

九、TDSQL 的最佳实践

分布式数据有一些最佳实践,下面举出三个(以 MySQL 引擎为例)。

(1)如何将数据导入分布式数据库

这分成两种情况。第一种情况是将现有的单机实例,导入到新建的分布式实例。操作步骤如下(详细命令见文档)。

  1. 导出单机数据库的表结构和数据,拿到两个 SQL 文件。
  2. 打开数据库的表结构文件,设置每个表的主键(primary key),以及分片依据的 shardkey。
  3. 将修改后的两个 SQL 文件,上传到云服务器,导入到分布式数据库。

第二种情况是将现有的一个分布式实例,导入到另一个分布式实例。操作步骤与上面一样,只是少了第二步,不需要指定主键和 shardkey,因为原来就有了。(详细命令见文档)。

(2)如何分片

分片(sharding)是分布式数据库的核心问题之一:到底要架设多少个数据分区?数据在多个分区如何分布?

分片数量取决于,整个数据库预估的最大并发,以及每个分片能够处理的请求数量,可以用下面的公式计算。

读写并发性能 = ∑(分片性能 * 分片数量)

单个分片的性能,主要与实例的 CPU / 内存数量相关。单个分片规格越高、分片数量越多,数据库系统的处理能力越强。

除了性能,分片还要考虑容量问题。一般来说,单个分片至少存储5000万行数据。

(3)如何配置硬件

分布式数据库的硬件,下面给出三个推荐的配置。

A. 测试功能。

这种情况不要求性能,只用来验证系统,建议配置2个节点,每个节点 2GB 内存 + 25GB 硬盘。

B. 业务发展初期。

这种情况数据规模较小,增长快,建议配置2个节点,每个节点 16GB 内存 + 200GB 硬盘。

C. 业务发展稳定期。

这种情况根据业务实际情况配置,可以配置4个节点,每个节点硬件为:(当前业务峰值 * 增长率) / 4。

十、总结

总的来说,当代的分布式数据库产品,将自身的大量复杂性,都隐藏了起来,为用户提供一个易用的操作接口。

一般来说,不建议自己搭建分布式数据库,即使你有专门的数据库工程师和运维工程师,成本也会非常高。使用云服务商的产品,是更经济更省事的选择。

就拿 TDSQL 来说,它有两个版本:集群版和基础版。前者是多节点的,供企业在生产环境使用;后者是单节点的,费用较低,专门供个人使用,但功能是一样的,很适合个人开发者学习或者尝试分布式数据库。

(完)

福利内容

在这个 AI 时代,如何使用云服务,助力企业的数据管理?

下面是三个国内大厂的真实案例。

案例一:微信读书的"AI 问书"。这个功能让 AI 来回答读者提问,关于海量的书籍内容的各种问题。

案例二:海峡银行核心系统升级。省级银行如何使用 TDSQL,将核心系统升级为分布式数据库。

案例三:极光大数据平台的架构优化。极光(URORA)是国内领先的开发者服务提供商,数据量近百 PB,节点过千,文件4亿,应该如何优化架构?

它们来自腾讯云内部编写的资料 《AGI 时代首选的全栈式数据管理方案》 ,包括工具指南、用户案例分享等诸多内容。

现在可以免费下载,只需微信扫描下方二维码。如果你关注国内真实环境中的企业级开发,不妨看看。