关系型数据库

这是关于MonetDB执行引擎的一篇paper，总体分为了2个部分，第一部分主要讲了下modern cpu的工作原理并给出了一个TPC-H Q1的例子，从这部分中我们便可以清晰的看到为什么向量化的执行方式如此有意义。第二部分则主要介绍了MonetDB X/100这个新的向量化执行引擎。这篇paper被引用的极为广泛，启发了后续很多列存数据库在执行引擎上的设计思路。个人感觉第一部分尤其有意义，如果想入门下列存/向量化执行，看看第一部分应该就有些概念了。

这篇简短的paper从非常high level的角度描述了下Oracle 10g对于parallel query所做的重新设计和其中的一些优化，由于Oracle RAC特殊的share-disk架构，使其在并行计算上与普通的MPP数据库有一些不同，例如对于worker的调度和分配方式以及对于资源/数据的动态调整。

Snowflake是目前话题度超高的云原生数仓产品，从20年下半年上市到现在已经市值千亿了。它的流行进一步印证了云的重要性。纵观现在大大小小的数据库厂商，上云是必然要走的战略步骤，而snowflake则更加直接，类似于AWS Aurora或我们的PolarDB，它就是围绕着云基础设施构建的OLAP数据库产品。

FoundationDB一个具有事务语义的分布式KV存储，是最早的一批把NoSQL和分布式事务结合起来的数据库系统，它提供了NoSQL的高扩展，高可用和灵活性，同时保证了serializable的强ACID语义。

在前面的文章中，介绍了Oracle是如何做cost-based query transformation的，其中也包含Oracle基于rules/cost所做的若干种常见的query rewrite。对于CBQT的极简描述是对一个query做deep copy后，尝试一系列transform并利用physical optimizer计算cost，如果cost更低则保留该变换，否则抛弃。详细介绍可以参考之前的文章。 这篇paper算是之前那篇的后续，把重点放在了对subquery的处理上。subquery是一种在分析型query中非常常见的SQL construct，非常便于表达一些语义因此被

这篇精干的paper介绍了IBM DB2基于window function对相关子查询进行解相关的等价变换。

这是一篇1996年的老paper了，主要讲解了IBM DB2如何针对query当中的有序性进行优化。但对于后续physical property的优化有较为深远的影响，由于DB2的优化器起源于System-R以及其后续演进的starburst，因此延续了system-R中的interesting order和order property的概念。关于system-R的介绍请看之前的文章。 order这种physical property并不只限于order by算子，基于有序的group by/distinct等，都会利用到数据的排序操作，而排序本身就是比较昂贵的计算，因此应该对其做尽可能的优化

这篇paper介绍了HyPer中引入的groupjoin算子，针对 join + group by这种query，可以在某些前提条件下，在join的过程中同时完成grouping+agg的计算。 比如用hash table来实现hash join和group by，就可以避免再创建一个hash table，尤其当join的数据量很大，产生的group结果又较少时，可以很好的提升执行效率。

这篇paper中讨论是的Microsoft的cosmos DB，其本身是一个海量数据的大规模计算平台，有些类似hadoop，使用的是一种类SQL的脚本，叫做SCOPE，针对SCOPE的优化器负责生成最优的执行计划。在1998年前后Microsoft基本丢弃了Sybase原有的优化器实现，并由Graefe主导重写了基于cascades的优化器。因此和Microsoft所有其他的数据库产品一样，SCOPE optimizer也是基于Cascades的transformation-based的优化器。

这篇paper主要介绍了Oracle从10g开始引入的CBQT(Cost Based Query Transformation)框架。虽然以Oracle历来的风格，无法期待它在paper中讨论很多细节，不过这篇还是可以让我们一窥Oracle对于query rewrite的处理思路和很多非常实用的query rewrite模式，对于开发优化器的同学很有参考意义。 值得一提的是，PolarDB目前也在做这方面的工作，而主要的参考正是这篇paper。此外这篇paper的思路和MemSQL optimizer中对query rewrite的处理思路非常接近，关于MemSQL optimizer的介绍可

这篇承接了上一篇对于TPC-H中chockpoint的定性分析，基于Hyrise这个学术系统进行了较为孤立且细致的量化分析，并给出了不同类型chokepoint优化对于TPCH query的相对影响。 TPC-H的chokepoints在上一篇已详细介绍，并介绍了MySQL和PolarDB的对应优化情况。

TPC-H可以说是世界上最为流行的OLAP workload的benchmark程序，无论你看什么样的论文或技术文章，只要是和query processing相关的，大多会在evaluation时使用TPC-H作为评估工具。而如果你从事query optimization/query execution的工作，则怎么都会和TPC-H打上交道，即使是TP型的数据库系统。

在之前的文章中我们讨论了基于graph的DP-based算法，来解决join ordering的枚举问题。 这些DP算法通过join predicate描述的连通性，解决了枚举可能的表组合问题，但join graph本身(即使hypergraph)是无法完整的描述join语义的，因为连通边本身无法描述不同类型的join语义，例如left outer join/semi join/anti join...，因此即使找到了所谓的csg-cmp-pair，也不一定是有效的plan。 这篇paper讨论的就是这个问题，当枚举出一个csg-cmp-pair (S1 o S2)，如何判断这是有效的join

这篇paper是著名的DPccp算法的延续，仍然是讨论如何最高效的基于Dynamic Programing，实现join ordering这个SQL查询优化中最为核心的功能。

随着互联网数据的爆炸性增长，传统数据库系统在单表数据容量方面承受了越来越大的压力。以前公司内部的数据库，存放的主要是来自公司业务或内部管理系统的信息，中小型公司甚至一个MySQL实例就搞定了。但现在数据源不仅更丰富，数据量也在指数级增长，从业务的角度，基于hash/range的分区表变得越来越有吸引力。

在上篇文章中，主要讨论了SQL Server的MPP数仓系统PDW的分布式优化过程，PolarDB的并行优化从中有所借鉴，本篇文章主要看下这篇介绍Oracle并行执行策略的paper，因为在PolarDB的分布式执行策略中，有很多与其有所重叠。

最近一年一直在做PolarDB的并行优化器，过程中调研了各种分布式数据库系统的优化和执行框架，后续几篇文章将一一分享，首先介绍对PolarDB MySQL的并行优化框架影响最大的，也就是SQL Server PDW。

今天我们要介绍的MemSQL就采用这样一种新的形态（Oracle也变为了这种方式 ）：即在做transformation时，要基于cost确定其是否可应用。 当然，本篇paper不止讲解了CBQT，还包括一些MemSQL优化器其他方面的介绍，包括一个有意思的heurstic based bushy join的方案。

在前文最后，我们提到了围绕着Orca打造的测试工具集，其中一个就是本篇paper的主角: TAQO。这个测试框架目标是为了测试优化器cost model的精确性，它针对优化的本质目标，提出了一种简单灵活，且易于扩展的方案，且便于实现。目前在PolarDB的分布式优化器中，我们已经采用了这种方法去度量分布式exchange 算子(Enforcer)和复杂计算(aggregation...)的代价因子。 当然，这个框架不局限于Orca，它可以在近乎黑盒的情况下对cost model进行校准，并针对不同optimizer的cost model质量进行横向评估，如果有开发或扩展优化器cost mode

在之前的几片paper笔记中，对最为主流的两套优化器框架进行了解读，包括bottom-up dynamic programming的search策略和基于Top-down memorization的search策略

数据库查询优化器的搜索技术，基本上分为了基于动态规划的bottom-up search(详见文章System-R论文解读)和基于Cascades/Volcano的top-down search两个流派，这篇文章我们来看一下Cascades的前身也就是Volcano优化器框架的paper。

如果说选一篇在优化器框架上，被引用次数最多的文献，应该非这篇论文莫属了，还记得Andy Pavlo在cmu的课程中提到IBM Research的一群大神们，是怎么一人一个模块来负责System R的设计的，而关于Join order enumeration，Selinger可以说是开创了dynamic programing based 的bottom-up的搜索空间算法的先河，直至今日，很多成熟的商业或开源数据库系统仍在沿用这套框架，比如Oracle / DB2 / PostgreSQL ...

PolarDB 作为阿里云的重磅明星产品，是目前唯一 100% 兼容 MySQL 5.6/5.7/8.0 的云原生数据库产品。 通过多节点集群架构，存储与计算分离，共享存储等一系列创新技术， PolarDB 拥有卓越的计算性能，100TB的存储容量，100%兼容MySQL，1/10其他商用数据库的成本，为阿里云客户以及阿里集团提供强有力的数据库服务。我们的技术不仅服务于千万阿里云线上客户，创造PolarDB系列产品的营收神话，还多次登上数据库顶级会议SIGMOD，VLDB等的世界舞台。

作者：漠雪

作者：孟勃荣

作者：明宗

作者：技师

作者：康俊彬（博士）

作者：蔡乐

在 MySQL 8.0 之前，Server 层和存储引擎（比如 InnoDB）会各自保留一份元数据（schema name, table definition 等），不仅在信息存储上有着重复冗余，而且可能存在两者之间存储的元数据不同步的现象。不同存储引擎之间（比如 InnoDB 和 MyISAM）有着不同的元数据存储形式和位置(.FRM, .PAR, .OPT, .TRN and .TRG files)，造成了元数据无法统一管理。此外，将元数据存放在不支持事务的表和文件中，使得 DDL 变更不会是原子的，crash recovery 也会成为一个问题。

业务/技术亮点：高效运维/弹性能力/跨机房容灾/数据迁移一致性

云数据库占比持续增长

阿里巴巴自主研发的下一代关系型分布式云原生数据库PolarDB，在兼容传统数据库生态的同时，突破了传统单机硬件的限制，为用户提供大容量，高性能，极致弹性的数据库服务。

友邦人寿日前加速重要业务系统上云进程，包括保险出单、保单契约等在内的数十套业务系统，开始采用阿里云PolarDB云原生数据库，通过全面替代传统商业数据库，进一步提升业务系统性能，为最终用户提供最稳定、可靠的服务。

本文主要围绕数据误删中的行级误删情况，介绍了 PolarDB-X 的 SQL 闪回是如何帮助用户恢复数据的。相对于现有的数据恢复方案，SQL 闪回的 SQL 级的回滚能力以及易于上手的操作界面能够帮助用户更加精准、更加快速地恢复误删数据。

死锁是关系型数据库系统中最为常见的错误，出现在不同事务中同时对某些数据访问加锁时都要等待对方请求中的数据而无法获取锁，数据库系统会自动牺牲回滚代价最小的事务，从而导致对应的写请求失败，更严重的情况是在大量死锁发生时，会导致数据库系统效率低下，堆积进程大量堆积引发性能问题。

PolarDB集群原生支持读写分离方式接入业务，但是在真实业务中，经常出现节点上负载不均情况，严重的话可能导致单节点承担大量的流量被拖跨，最终整个集群雪崩影响业务。本文主要描述PolarDB代理的配置方法以及流量不均时如何定位。

免费体验RDS-MySQL物理备份上云功能

内容简要： 一、PostgreSQL行业位置 二、数据安全大事件 三、数据库安全体系 四、PostgreSQL最佳实践案例

ACM SIGMOD被公认是数据库领域具有最高学术地位的国际性会议，收录论文代表了数据库相关技术的最高水平，也是未来技术发展的重要风向标。阿里多个团队参与了本次大会，获得录取的13篇论文来自阿里云数据库、计算平台、阿里巴巴达摩院等团队，其中数据库论文就有8篇，论文覆盖云原生数据库、数据库管理资源优化、SQL 查询优化、增量图算法、时序多周期检测等前沿和热点技术领域。

今年欧洲杯、美洲杯等热点赛事期间，国内最大的体育互联网平台虎扑迎来密集流量洪峰的大考，通过充分使用云上资源，尤其利用阿里云RDS数据库企业级自治能力，轻松应对创下新高的并发访问量。

作者：王颜培（感仰） 内容简要： 一、阿里云RDS MySQL简介 二、云原生架构之路 三、后续规划

记者日前采访获悉，高考报名咨询机构“圣达信”在今年的业务高峰到来之前，通过引入阿里云PolarDB云原生关系型数据库，平稳应对高考报考数十倍的突发流量增长，助力高考学子选择合适的专业和院校。

在近期的上海ACE同城会上，阿里云数据库高级产品专家吴林为大家分享了云原生分布式数据库PolarDB-X的技术架构、业务场景以及最佳实践等。 本文内容根据演讲录音及PPT整理而成。 本次分享将主要分为四个方面： 一、数据库简介； 二、PolarDB-X 架构； 三、PolarDB-X 业务场景； 四、PolarDB-X 案例。

内容简要： 一、PostgreSQL行业位置 二、PostgreSQL版本升级背景 三、PostgreSQL版本升级解密 四、PostgreSQL版本升级成果