美国知名大学开授China数据库理论,你没看错!

开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题,有需求都可以加群群内有各大数据库行业大咖,可以解决你的问题。加群请联系 liuaustin3 ,(共2790人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9)(1 2 3 4 5 6 7群均已爆满,开8群260+ 9群)

Austindatabases公众号已经开启了,AI 文章分析,AI 文章问答,比如你想知道AustinDatabases 里面,说了多少种数据库,那些是讲 MySQL,那些是PostgreSQL, 那些是OB ,POLARDB ,MongoDB ,SQL Server, 阿里云的,问他他会列出来,同时如果有问题不明白,可以将文章的文字粘贴到公众号提供的专用AI ,公众号将通过众多文章(目前1300多篇)来进行尝试性的解释。使用方法,直接到微信公众号中点击服务,选择AI问答。如下示例

图片


人外有人,天外有天,这句话可能是我今年的口头禅了,最近有老师给我一些信息,个人看属于,氢弹级别,美国著名大学加州Berkeley---世界数据库系统的摇篮,CS286--2024春季研究生数据库系统的课程,正式将PolarDB 云原生数据库低延迟一致性读的原理,写入到正式的课程中,且开始教授它,世界顶尖的学府的学生也能学到数据库业界最先进的技术。希望国内的大学课程也可以与时俱进,在讲授20年前的数据库理论的同时,也可以把国产现代数据库的原理和学生们讲一讲,终究洋人崇中媚中,咱们崇洋媚外这话可是不好听。

美国加州博纳克利大学数据库系统--研究生课程
美国加州博纳克利大学数据库系统--研究生课程
PolarCB的SCC研究正式在课上讲授
PolarCB的SCC研究正式在课上讲授

想想,这所大学诞生过,Ingres、PostgreSQL、Oracle、DB2等这些数据库,算是数据库系统的摇篮,数据库理论的圣殿。在数据库研究生的课程中开始教授PolarDB的理论,这次我们国产数据库翻身了。让我不得不把这篇,我之前翻译过的论文再次的好好的又读了一遍。(想和我一起在读一遍这篇PolarDB-SCC  白皮书的可以在文尾连接区下载PDF)

PolarDB-SCC: A Cloud-Native Database Ensuring Low Latency for Strongly Consistent Reads

首先我们要确定的是PolarDB 无论是PolarDB for MySQL 还是 PolarDB for PostgreSQL,这两种云原生数据库,均具有在实际业务中完成读写分离的瞬时主从节点数据一致的能力,我们可以简单理解为,主从没有延迟,从节点在主节点写入数据后,可以立即读出写入的数据,与此同时能提供比MySQL,PostgreSQL 单机更好的性能和多种复杂的功能,如行列混存,数据压缩,数据加密,数据归档命令内部执行,并行SQL查询等能力。

这些传统数据库脑仁疼的问题--如读写节点数据只能承诺最终一致性的问题,被彻底的解决了,且是中国的国产数据库系统解决的这一问题。

开发者在之前的数据库系统中遇到数据库的读写分离中最大的问题---主从节点数据的一致性无法满足时效性的要求,不是只能达到最终一致性,要不就是数据虽然可以从从库读出写库数据,但要付出主节点的性能损失,属于鱼和熊掌不可兼得。

在PolarDB中,开发和架构将不在因为在写节点写入数据后无法立刻在读节点读出数据,从而要做的一系列架构的调整和开发的代码结构的变动,这一切再PolarDB都不需要在考虑,开发专心搞好业务逻辑开发就好,之前架构人员在MySQL上的所做的需要都作废了,这些工作如下:

1  要明确主从读取数据的一致性级别的问题 

2  读写分离的策略,针对业务进行改造要分辨那些业务必须写库写,写库读,那些写库写,读库读的大量业务改造。 

3  处理主从延迟所带来的方法,如延迟告警,强制读取写库,业务重试机制,数据校验工作。

这将大大减少开发的成本和业务开发的复杂性,及架构设计的成本和复杂性。

那么什么技术,让国际最重要的数据库系统理论发明的“基地”来教授中国PolarDB的数据库理论给他们的加州博纳克利大学的研究生,我们来看看:

这个关键性的技术难题在PolarDB中被这三点解决

1  分层修改跟踪器:(Hierarchical Modification Tracker, HMT)在全局、表级和页级三个粒度上跟踪读写节点的修改时间戳。当只读节点需要进行强一致性读取时,它会首先检查全局级别的时间戳,然后是表级和页级的时间戳。一旦某个级别满足要求(即只读节点在该级别的数据是最新的),就可以直接处理请求,而无需检查下一个级别。只有当页级时间戳不满足时,才需要等待相关页面的日志应用完成. 这种细粒度的跟踪避免了等待所有内存数据更新完成造成的开销。

2 线性Lamport时间戳:(Linear Lamport Timestamp, LLT)为了减少只读节点频繁地从读写节点获取时间戳的操作,PolarDB-SCC 在只读节点上设计了一种线性 Lamport 时间戳。只读节点在从读写节点获取一次时间戳后,可以本地缓存该时间戳,并在后续的某些读取请求中直接重用该时间戳,从而减少网络和通信开销。

3 基于 RDMA 的数据传输:利用高速的 RDMA(Remote Direct Memory Access)网络 进行日志传输和时间戳获取。RDMA 可以提供低延迟的网络通信,并绕过读写节点的 CPU 来进行远程内存访问,从而降低网络开销和读写节点的 CPU 使用率。

其中论文还论述了PolarDB云原生数据库保证读写一致性的整套理论,通过写节点每次写入操作后返回一个日志的LSN号,给代理节点,代理节点将同一个事物中的后续请求都发给只读节点前,会检查只读节点上已经应用的最高LSN,确保读取节点的数据已经包含了之前的写入数据。

而读写节点强一致并不是重点,而是起点,因为在读写节点强一致的基础下,数据库真弹性的能力,最大可以一次性瞬间弹出16个读节点以应对突发的读请求。基本上百分之90%以上的读问题都可以在PolarDB上解决,而那些假的弹性,如基于K8S那样的技术的假弹性,只能在这样的技术面前,下跪。

https://cs286berkeley.net/Lecture%2023%20Cloud%20OLTP.html

我们反过来看看上面具体Berkeley大学的研究生课程中,具体对PolarDB-Scc理论秉持的是一个什么态度。

1  在CS286课程中,质疑了Aurora 的“Stale RO copies! What? Is that OK?” 这表明在云 OLTP 中,如何保证只读副本的数据不落后于主节点是一个重要的变化和挑战。这与 OLAP 系统更能容忍一定程度的数据延迟不同。CS286讨论了 PolarDB-SCC 解决“Stale reads suck”的问题中所做的努力,强调了强一致性的重要性在OLTP业务中的重要性。

2  在CS286课程中对事务处理的低延迟要求描述中提到OLTP 系统通常需要处理大量的并发事务,并对每个事务的响应时间有严格的要求。课程提到了commit-wait 和 read-wait 等保证一致性的简单方法,但同时也指出了它们会导致事务本身的高延迟,这在 OLTP 中是不可接受的。PolarDB-SCC 的目标就是确保低延迟的强一致性读取。

3 在CS286课程中,还提到读写分离架构下的挑战 许多云原生数据库采用读写分离架构,即将读请求分发到只读节点,写请求发送到主节点。CS286中提到的 “Single-mastered databases! What? Is that OK?” 以及后续关于如何处理只读副本一致性的讨论,都反映了这种架构在 OLTP 中带来的特有挑战。如何在保证数据一致性的前提下,充分利用只读节点来扩展读性能,是云 OLTP 需要重点考虑的问题,截止到目前只有PolarDB 做到了。

4 在CS286课程中,弹性伸缩的需求和单Master的影响中提到云环境的弹性是其重要特性,课程中提出“Elasticity is available: what shall we use it for and how? Impact of single-master”,暗示了如何在 OLTP 系统中利用弹性,以及单Master架构可能带来的限制。例如,在需要强一致性的场景下,如果只读节点数据过时,可能无法简单地通过增加只读节点来扩展读性能. PolarDB-SCC 的设计目标之一就是实现真正的可扩展性和弹性,允许根据应用负载动态增加或减少只读节点的数量,同时保证强一致性。

所以,我一直强调,RDS的弹性是假的,K8S在云上搭建的MYSQL OR POSTGRESQL 系统谈弹性都是垃圾,这点是做实了,这在CS286这么课程中的总结上面的第四点印证了,加州博纳克利大学的教授知名数据库业界学者 Joseph M. Hellerstein,估计也是这么看的。

当然这门课程在这一章节里面还提到了,故障容错,快速修复,工作负载于LaaS定价模型,等等,这些后面我都会去好好的看看和学习,让我们记住这些先进技术的发明者的名字吧!

 https://www.vldb.org/pvldb/vol16/p3754-chen.pdf

置顶

“PostgreSQL” 高性能主从强一致读写分离,我行,你没戏!

数据库的 4月1日 愚人节,我没有被愚弄 !

搞 PostgreSQL多才多艺的人--赵渝强 《PG数据库实战派》

追逐太阳的男人--林春 《金融数据库转型实战》

数据库的 4月1日 愚人节,我没有被愚弄 !

数据库界的“申公豹”,带云DBA走出--救生筏困境!

阿里云DTS 产品,你真让我出离愤怒,3年了病还没治好???

让数据先“活”起来,如何实现数据在企业中的最大价值

专访唐建法-从MongoDB中国第一人到TapData掌门人的故事

ETL 行业也够卷,云化ETL,ETL 软件不过了

天上的“PostgreSQL”  说 地上的 PostgreSQL 都是“小垃圾”

宇宙的“PostgreSQL” 说 “地球上的PG” 都是“小垃圾”

云数据库核爆在内部,上云下云话题都是皮外伤!--2025云数据库专栏(二)

云原生 DB 技术将取代K8S为基础云数据库服务-- 2025年云数据库专栏(一)

临时工:数据库人生路,如何救赎自己  -- 答某个迷茫DBA的职业咨询

阿里云DTS 产品,你真让我出离愤怒,3年了病还没治好???

PolarDB 相关文章

宇宙的“PostgreSQL” 说 “地球上的PG” 都是“小垃圾”

“PostgreSQL” 高性能主从强一致读写分离,我行,你没戏!

PostgreSQL 的搅局者问世了,杀过来了!

在被厂商围剿的DBA 求生之路 --我是老油条

POLARDB  添加字段 “卡” 住---这锅Polar不背

PolarDB 版本差异分析--外人不知道的秘密(谁是绵羊,谁是怪兽)

在被厂商围剿的DBA 求生之路 --我是老油条

PolarDB 答题拿-- 飞刀总的书、同款卫衣、T恤,来自杭州的Package(活动结束了)

PolarDB for MySQL 三大核心之一POLARFS 今天扒开它--- 嘛是火

PostgreSQL 相关文章

PostgreSQL的"犄角旮旯"的参数捋一捋

PostgreSQL逻辑复制槽功能

PostgreSQL 扫盲贴 常用的监控分析脚本

“PostgreSQL” 高性能主从强一致读写分离,我行,你没戏!

PostgreSQL  添加索引导致崩溃,参数调整需谨慎--文档未必完全覆盖场景

PostgreSQL 的搅局者问世了,杀过来了!

PostgreSQL SQL优化用兵法,优化后提高 140倍速度

PostgreSQL 运维的难与“难”  --上海PG大会主题记录

PostgreSQL 什么都能存,什么都能塞 --- 你能成熟一点吗?

PostgreSQL 迁移用户很简单 ---  我看你的好戏

PostgreSQL 用户胡作非为只能受着 --- 警告他

全世界都在“搞” PostgreSQL ,从Oracle 得到一个“馊主意”开始
PostgreSQL 加索引系统OOM 怨我了--- 不怨你怨谁

PostgreSQL “我怎么就连个数据库都不会建?” --- 你还真不会!

病毒攻击PostgreSQL暴力破解系统,防范加固系统方案(内附分析日志脚本)

PostgreSQL 远程管理越来越简单,6个自动化脚本开胃菜

PostgreSQL 稳定性平台 PG中文社区大会--杭州来去匆匆

PostgreSQL 如何通过工具来分析PG 内存泄露

PostgreSQL  分组查询可以不进行全表扫描吗?速度提高上千倍?

POSTGRESQL --Austindatabaes 历年文章整理

PostgreSQL  查询语句开发写不好是必然,不是PG的锅

PostgreSQL  字符集乌龙导致数据查询排序的问题,与 MySQL 稳定 "PG不稳定"

PostgreSQL  Patroni 3.0 新功能规划 2023年 纽约PG 大会 (音译)

PostgreSQL   玩PG我们是认真的,vacuum 稳定性平台我们有了

PostgreSQL DBA硬扛 垃圾 “开发”,“架构师”,滥用PG 你们滚出 !(附送定期清理连接脚本)

DBA 失职导致 PostgreSQL 日志疯涨

OceanBase 相关文章

OceanBase 6大学习法--OBCA视频学习总结第六章

OceanBase 6大学习法--OBCA视频学习总结第五章--索引与表设计

OceanBase 6大学习法--OBCA视频学习总结第五章--开发与库表设计

OceanBase 6大学习法--OBCA视频学习总结第四章 --数据库安装

OceanBase 6大学习法--OBCA视频学习总结第三章--数据库引擎

OceanBase 架构学习--OB上手视频学习总结第二章 (OBCA)

OceanBase 6大学习法--OB上手视频学习总结第一章

没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛

OceanBase  送祝福活动,礼物和幸运带给您

跟我学OceanBase4.0 --阅读白皮书 (OB分布式优化哪里了提高了速度)

跟我学OceanBase4.0 --阅读白皮书 (4.0优化的核心点是什么)

跟我学OceanBase4.0 --阅读白皮书 (0.5-4.0的架构与之前架构特点)

跟我学OceanBase4.0 --阅读白皮书 (旧的概念害死人呀,更新知识和理念)

聚焦SaaS类企业数据库选型(技术、成本、合规、地缘政治)

OceanBase 学习记录-- 建立MySQL租户,像用MySQL一样使用OB

PolarDB 相关文章

“PostgreSQL” 高性能主从强一致读写分离,我行,你没戏!

PostgreSQL 的搅局者问世了,杀过来了!

在被厂商围剿的DBA 求生之路 --我是老油条

POLARDB  添加字段 “卡” 住---这锅Polar不背

PolarDB 版本差异分析--外人不知道的秘密(谁是绵羊,谁是怪兽)

在被厂商围剿的DBA 求生之路 --我是老油条

PolarDB 答题拿-- 飞刀总的书、同款卫衣、T恤,来自杭州的Package(活动结束了)

PolarDB for MySQL 三大核心之一POLARFS 今天扒开它--- 嘛是火

MySQL相关文章

MySQL SQL优化快速定位案例 与 优化思维导图

"DBA 是个der" 吵出MySQL主键问题多种解决方案

MySQL 怎么让自己更高级---从内存表说到了开发方式

MySQL timeout 参数可以让事务不完全回滚

MySQL 让你还用5.7 出事了吧,用着用着5.7崩了

MySQL 的SQL引擎很差吗?由一个同学提出问题引出的实验

用MySql不是MySQL, 不用MySQL都是MySQL 横批 哼哼哈哈啊啊

MYSQL  --Austindatabases 历年文章合集

MongoDB 相关文章

MongoDB  大俗大雅,上来问分片真三俗 -- 4 分什么分

MongoDB 大俗大雅,高端知识讲“庸俗” --3 奇葩数据更新方法

MongoDB 学习建模与设计思路--统计数据更新案例

MongoDB  大俗大雅,高端的知识讲“通俗” -- 2 嵌套和引用

MongoDB  大俗大雅,高端的知识讲“低俗” -- 1 什么叫多模

MongoDB 合作考试报销活动 贴附属,MongoDB基础知识速通

MongoDB 年底活动,免费考试名额 7个公众号获得

MongoDB 使用网上妙招,直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)

MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模

MongoDB  双机热备那篇文章是  “毒”

MongoDB   会丢数据吗?在次补刀MongoDB  双机热备

MONGODB  ---- Austindatabases  历年文章合集

临时工访谈系列

没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛

ETL 行业也够卷,云化ETL,ETL 软件不过了

SQL SERVER 系列

SQL SERVER维保AI化,从一段小故事开始

SQL SERVER 如何实现UNDO REDO 和PostgreSQL 有近亲关系吗

SQL SERVER 危险中,标题不让发,进入看详情(译)

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值