一份数据搞定OLAP+OLTP（上）

在最近读的一篇论文中提出了通过设计新的存储模型(Lineage-based Data Store)，解决在当前数据存储下OLAP 与 OLTP场景优化不可兼得的问题。

 原论文连接：https://www.researchgate.net/publication/324150481_L-Store_A_Real-time_OLTP_and_OLAP_System

1.背景介绍：

首先作者介绍了数据存储的发展背景，首先是因应不同场景下的需求单独开发一套专用的数据库及数据引擎，但是由于后续发现开发与维护这么多的数据库及引擎需要大量的人力资源以及会引起数据孤岛。因此在接下来的发展中学术界和工业界都考虑采用较为通用的解决方案来解决上述的问题。

在这个时候，数据库被大概分成了两种类型，针对OLAP优化及针对OLTP优化的数据库。这样虽然解决了维护大量引擎的问题，但是还是存在着两种引擎之间的数据没有被打通，未完全实现一份数据支持多种使用场景以及实时决策的问题。因此这篇文章将尝试通过设计新的存储模型来解决这个问题。

什么问题提出了实时OLAP与OLTP结合的需求？

在进入互联网时代后，对于实时的广告竞价/电信诈骗检测催生了基于实时数据进行决策的需求。

2.存储结构介绍

在目前来说，数据存储主要分成两个流派：针对OLTP的基于行的存储，以及针对OLAP的基于列存储的。他们分别有着in-place 更新 和 按需读取相关列数据的优点。

在本次的研究中的L-store 数据结构将会是基于列的存储。总体来说L-store将数据分成了两个部分，只读的base page 和 只写的tail page。这两个部分的数据通过指针来进行关联，并且在这个设计的数据结构中会在后台周期性地执行无冲突的merge，把tail page 的数据merge 到base page中。通过把数据分成只读和只写两个部分来同时满足OLAP 和 OLTP的需求。

总体存储结构介绍：

L-store 是基于列存储的结构，除了存储数据的列之外有几列是系统列。

RID：针对某一行数据的唯一识别码

Indirection column: 在Base Page中，充当后向指针的作用，指向在Tail Page中被更新的最新版本。如果没有被更新过，当前行将会设置为null；

在Tail page中，指向对应行上一次修改的记录

Schema Encoding: 利用bitmap来表示数据中对应的列是否被修改过

Start Time cloumn: 记录数据是什么时候被放入base page的

Last Updated TimeColumn: 记录数据的更新时间，在Merge之后会被移除

在本篇文章中，将会对数据的CRUD操作进行讲解，在下一篇文章中再来讲解

Update & Delete 

首先明确一点是在L-store 结构中，数据被分成Base page 及 tail page 两部分。

以Table 2 作为例子，首先对Update 操作进行讲解。在对某一行数据进行首次更新时，将会记录原来的数据作为数据快照（这个的作用是为了后续的Merge做准备）。然后再添加相应的更新数据。 但是如果为非首次更新，那么则会直接新建一行，指针指向上一次更新操作。除了单独对某一列进行了更新之外，如果对统一个RID下的数据的多行进行了修改，那么这样的修改将会生成一条累积性更新，如Table 2 t5;

对于delete操作，如表2中t8，则会新建一行记录，所有的列都设置为空。

Insert

在Base Page的末尾，有一块区域是专门用来存储Insert 的数据的，当进行Insert操作时，原理与Update操作类似。系统将从insert区中分配出首列未被使用的列，然后对其进行全列的数值插入操作。 这块在BasePage中被预留的区域与Insert Page 的大小相同，因此他们之间是一一对应的关系。

在下一篇文章中将会讨论这些Tail page 和 Insert page 是怎么进行无冲突合并，并且是如何保证同时对OLAP 与 OLTP的优化的。