Mr.Phoebe的专栏

数据库设计的非正统方法：Shard的来临关于Shard和Partition的区别，大家可以看看What’s the difference between sharding DB tables and partitioning them?以及Database sharding Vs partitioning。简单而言，就是通常意义上的Partition是在本地数据上的分片，Shard是在多台

原文地址数据库管理系统将数据存储在磁盘、磁带以及其他的裸设备上，虽然这些设备的访问速度相比内存慢很多，但其非易失性和大容量的特点使他们成为数据存储的不二之选。本文主要讨论大型数据库产品的磁盘存储内部结构，这对于深入理解数据库各种数据结构具有至关重要的作用。数据库磁盘存储的体系结构以上两图分别展示了存储器分级结构以及磁盘内部物理结构

原文地址索引（Index）是数据库管理系统中一个非常重要的数据结构，索引的合理使用能够极大提高数据库系统的性能。那么，什么是索引？索引有时如何提高数据库系统性能的呢？阅读本文时建议参考：《深入理解数据库磁盘存储（Disk Storage）》索引概念以一本书为例，通常一本书开头会有目录，而后才是正文，通过目录中每行左侧的标题和右侧的页码，我

事务的定义事务（txn）是一系列在共享数据库上执行的行为，以达到更高层次更复杂逻辑的功能。事务是DBMS中最基础的单位，事务不可分割。ACIDACID，是指在可靠数据库管理系统（DBMS）中，事务(transaction)所应该具有的四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。原子性

我们知道，目前通用的数据库查询语言是SQL语言（Structured Query Language）。SQL语言也是一种编译型语言，需要SQL编译器编译后才能执行，但它与C、C++、Java等语言不同，SQL语言是一种非过程化语言，这意味着使用SQL进行操作的时候，你只需要指定你要达到什么目的，而无需指明要怎样达到目的。 既然用户只需要解决“做什么”的问题，那么，“怎么做”的问题正是本文要讨论的

因为数据库中的事务是具有隔离性的，一个事务的运行不应该影响另一个事务的运行。 但是因为并行机制的存在，会有一系列的问题： 脏读：事务A修改了一个数据，但未提交，事务B读到了事务A未提交的更新结果，如果事务A提交失败，事务B读到的就是脏数据。 不可重复读：在同一个事务中，对于同一份数据读取到的结果不一致。比如，事务B在事务A提交前读到的结果，和提交后读到的结果可能不同。 幻读：

多版本并发控制Multi-Version Concurrency Control基础理解事务T1改变数据V1，将其改为数据V2，在堆中，数据如下图事务T3改变了V2，将其改为V3，在堆中，数据如下图：目前事务T2还在活动中，所以V1和V2属于recently dead状态，而不是真的dead状态。从可视性而言，事务T0只能看到数据V1。因为它早于事务T1启动。事

索引的锁和闩(Locking & Latching)索引的锁和闩索引作用一种能够加快数据检索速度的数据结构，但是会占用额外的读写维护操作和存储空间。索引实现B树系列、哈希表等等。这些别的地方说的比较多，我就不多提了。索引锁对于之前疏文章中提到的那些并发控制、多版本控制等，我们知道了如何使用锁来保护数据库的数据。但是对于索引，我们需要用别的方式和方法来

不需要锁和闩的索引（Latch-free OLTP Indexes Part I）T-TreesT-Trees 是一种基于AVL树的数据结构，它的设计是人们针对内存数据库做的优化。不像B-Trees 系列在硬盘上那样存储大量的信息，包括索引、值等等，T-Trees 利用了所有数据都已经在内存中的这个条件，它存储的是指向数据的指针。这样可以有效地减少overhead，具有较高的节点空

不需要锁和闩的索引（Latch-free OLTP Indexes Part II）Bw-Tree Index对于并发的跳表而言，我们不能在无锁的情况下有反向指针，因为CaS一次只能更新一个地址。这个数据结构是微软在2010年左右做的，一开始微软想用的是Skip List，但是因为Skip List的限制，他们就设计了Bw-Tree。现在用Skip List的数据库，老师知道的只有

OLAP Indexes对于传统的分析数据库结构大致如下OLTP数据库保持相互独立，然后将需要的数据传输到OLAP数据库。OLAP Schemas决策支持系统（DECISION SUPPORT SYSTEMS）为组织的管理，运营和计划层面提供帮助的人通过分析历史数据来帮助人们做出有关未来问题和问题的决策的应用程序。大数据的起源就是这儿。STAR SCHE

数据库十二（2）：HIVE文件存储格式昨天在看HIVE的时候，突然发现HIVE的文件存储对数据的压缩刚好是前天看的数据库压缩的内容。所以刚好可以拿出来讲一下。TextFileHive默认格式，数据不做压缩，磁盘开销大，数据解析开销大。可结合Gzip、Bzip2、Snappy等朴素压缩算法使用（系统自动检查，执行查询时自动解压），但使用这种方式，hive不会对数据进行切分，从

Logging ProtocolsLogging Schemes恢复算法日志一般与系统恢复有关，恢复算法是确保数据库一致性、原子性和持久性（尽管事务失败）的技术。恢复算法有两个部分：正常txn处理期间的操作，以确保DBMS可以从故障中恢复。无法将数据库恢复到确保原子性，一致性和持久性的状态之后的操作。日志方案有两种日志方案物理日志记录 记录对数

Checkpoint Protocols背景日志允许DBMS在崩溃/重新启动后恢复数据库。 但是这个系统每次都要重做整个日志。检查点允许系统忽略大部分日志以减少恢复时间，就像存档点一样。理想的检查点应该具有：不能减慢常规事务的处理速度。不能引入不可接受的延迟峰值。不能要求过多的内存。CONSISTENT VS. CHECKPOINTS方法1：一致的检查点

Optimizer Implementation(Part I)背景在讲述这个优化器的时候，就必须先了解查询过程。在本系列的数据库四：浅谈数据库查询过程（Query Processing）中大致地说明了一下数据库的查询过程，但是没提到查询优化器的具体策略与实现。对于查询而言，我们期望优化器的作用是找到最小代价的正确执行方案。但是这是一个NP完全问题，所以没有一个优化器能够真正地找到

Optimizer Implementation(Part II)在这儿解释一下，逻辑查询计划或者逻辑计划指的是关系代数层面的查询语句；物理查询计划或者物理计划指的是具体查询层面的查询算法，具体到每一个JOIN的算法选择，每一个SELECT操作的算法实现（scan或者index）。瀑布模型（Cascades）分层搜索（STRATIFIED SEARCH）首先使用转换规则重写

Optimizer Cost Models我们在上两次讲查询优化文章中，提到了基于成本的查询计划，它们为数据库的当前状态生成执行特定查询计划的查询成本估计。查询成本与我们上一节课讨论的优化器搜索查询策略的方式无关。就像二维平面上的最短路模型（不同的最短路算法，如Dikstra、Floyd）与它采用的距离模型（曼哈顿距离、欧氏距离、切比雪夫距离）无关。那么这节课就是讲解不同的估价模型。

Query Execution & Scheduling对于数据库系统，交互模式大致如上。前端有多个用户，也就是多个应用程序来访问后端。后端则发送逻辑查询给DBMS，DBMS得到SQL语句或者其他方式的逻辑查询之后，将之转化为物理查询，得到数据后再返回给后端。查询计划一个查询计划是由多个操作组成的。比如，SELECTION，JOIN等等。一个操作对应到具体的物理查询操作

Parallel Join Algorithms (Hashing)背景我们在执行Join操作的时候，肯定会使用多线程。但是这些多线程不是完全独立运行的，因为你需要在进入下一个阶段前将这一个阶段的所有数据处理完，而不能让一个线程先进入下一个阶段。所以如何设计Join算法来减少overhead就是非常关键的事情了。这篇文章我们将介绍Hash Join的算法，下片文章介绍的是Sort-

Parallel Join Algorithms (Sorting)背景关于Join的其他背景可以查看上一篇讲Hash Join的文章。SINGLE INSTRUCTION, MULTIPLE DATA (SIMD)有一系列的CPU指令允许处理器同时在多个数据点上执行相同的操作。目前的AMD和Intel CPU均具有ISA和微体系结构，支持SIMD操作。优点：

Query Compilation背景对于in-memory数据库，因为所有的数据都在内存之中，所以很多其他影响速度的因素（如磁盘IO等）都消失了，所以提高吞吐量的唯一方法是减少执行的指令数量。提高十倍速度，DBMS需要减少90%的指令提高百倍速度，DBMS需要减少99%的指令我们可以通过code specialization来实现这种指令数量的减少。即，通过生成DBMS

Vectorized Execution (Part I)说实话，这节课有点没听明白。上节课说到了通过矢量化来加速查询的优化，需要这么做的原因是：构建一个DBMS是非常难的一件事情DBMS中有很多的问题需要去克服新的CPU加速效果不明显，所以必须想别的办法来提升效果硬件方面一般来说，现在用的CPU主要分为两种MULTI-CORE CPUS使用少量高功率内

Vectorized Execution (Part II)上一次将的哥大的论文的矢量化算法在没有四五个SIMD寄存器的情况下是没法运行的。因为DBMS需要将64位的地址和64位的数据存入寄存器考虑到数据压缩技术，我们不能改变64位的地址，但是我们不一定要全部存储64位的数据。这样产生的问题是，压缩数据的位宽不一定自然地适合SIMD寄存器插槽。如你压缩前128位的寄存器存储了4个32位

Larger-than-Memory Databases背景我们知道DRAM价格非常昂贵，且运行耗电量也非常大。那么当内存数据库存储的信息更大了之后，我们就希望使用更加便宜的存储设备，希望改善DRAM带来的一些不利条件。新技术因此就产生了Larger-than-Memory Databases这种技术。即，允许内存中的DBMS存储/访问磁盘上的数据，而无需重新引入面向磁

Non-Volatile Memory Databases背景新兴的存储技术提供像DRAM一样的低延迟读取/写入，但具有永久写入和大容量等类似SSD的特性。AKA存储级内存，永久内存最早的设备将是块地址（NVMe），但是基于块地址的设备并不被数据库研发人员所青睐，它的性能仅仅类似于一个更好更快的NAND flash内存。后来的设备，字节地址改变了人们设计操作系统结构的方