数据库的方向 - 行vs列

前言：

转载的好文不多，但此篇的确是难得一见的好文，如若不信，请仔细阅读。

此篇文章没有波涛汹涌的起伏，没有繁多的代码，只有悠然自得的文笔。

因此，分享此文给大家。

数据库的方向 - 行vs列

如果你是一位数据库专家的话，这篇博客可能帮不了你什么。

如果你是一位IT人士，但对数据库技术只知其然的话，这篇博客会很适合你。

如果你是非IT人士，又或者你是我的家人，谢谢你们的阅读，但是显然你应该去寻求更适合你的阅读材料。

如此，可能会对此话题感兴趣的朋友已经减少了。看来你应该是这样一个人，你是非数据库领域的IT专家，但是你深知数据库的重要性，你可能非常想更多的了解一些当前IT界正在热烈讨论的数据库热门话题。

我可以很坦率的告诉大家，虽然我在IBM i的很多个部门工作过，但是我并不是一个DB2的开发人员。所以我会定期的去DB2团队寻求一些聪明的数据库专家给我一些比较高级的数据库指导。尤其,我非常想知道，为什么近来如此多行业都在谈论“列式存储”数据库的原因。所以，我找到了Mark Anderson。 众所周知，Mark是一位杰出的工程师，现在是DB2 for i的首席架构师。下面，我将分享一下我学到的知识。

今天的主题也如同很多有关数据库讨论一样主要集中于性能方面。即，新兴的列式数据库和传统的行式数据库在性能方面的比较。

顾名思义，这两种数据库架构在存贮数据时的方式是大相径庭的。在行式数据库中，每一行中的每一块数据都是紧挨着另一块数据存放在硬盘中。一般情况下，你可以认为每一行存贮的内容就是硬盘中的一组连续的字节。如果你记得DB 101（你已经学习了数据库的介绍课程，对吧？）中介绍的数据库中每一行都是用来记录一些实体信息的。为了方便我们的讨论，我们假设每一行都包含一个用户的信息，每个用户的所有属性都整块儿存储在硬盘上。如下图所示，虚拟表（或者数组）中的列用来存储每个属性。

在硬盘上，大量的页面用来存储所有的数据。我们假设数据库中的每一行的信息都存储在同一页上。在这种情况下，每一页都能保存一个用户的所有信息。在上边的例子中，Alice的所有信息都存储在一个页面中。如果需要获取或更新Alice的信息，那么某一时刻在内存中仅需存储关于Alice的单一页面。

虽然我还没有提到，但是你可以想象，如果是基于列的数据库，所有的数据都是以列的形式存储的。回到之前的例子，假设每一列的存储对应一个页面。如下图所示，所有的ZIP code将会存储到一个页面中，而所有的“2013 Total Order”则会存储在另一个页面中。

（嘿，所有数据库专家可能会就此停留，继而对用户的表设计提出意见，但抱歉，我并不是数据库架构师，这仅仅只是一个教学用例。）

现在，我们言归正传。

所有的数据库（实际上是所有的运算），当它所需要的数据驻留在内存中时其工作速度是最快的。当然正常情况下，数据不会在内存中，它们会被放到别的地方，当数据库调用它们时，它们才会被放到内存中。所以，如果你使用的是行式数据库，那么你对一行数据进行操作时，数据库的性能会是最好的。在上面的例子中，仅一个页面被放到了内存中。（这只是一个示例，事实上，操作系统会带来不止一页的数据，稍后详细说明）

另一方面，如果你的数据库是基于行的，但是你要想得到所有数据中，某一列上的数据来做一些操作，这就意味着你将花费时间去访问每一行，可你用到的数据仅是一行中的小部分数据。若此时你使用了列式的数据库，那就可以方便快捷的获取数据，因为每一列的信息都是存储在一起的。例如，所有的“2013 Total Order”信息都是存储在同一列中的。

可关键在于你使用列式数据库时，当你想要得到Alice的所有信息时，你又必须要读取大量的列（页面）来获取所有的数据。

正因为此，才有了这些天有关列式数据库的讨论。

如果你还是没有很好理解的话，我们下面会有更加详细的介绍。

到目前为止，几乎所有的数据库都是基于行的数据库，此类数据库对大多数的传统业务都是非常有效的。数据库专家们将大部分的数据库工作负载称为OLTP–在线事务处理。OLTP工作负载是数据库现有业务的关键业务。一般而言，这些应用程序在使用行数据库时会有更好的表现，因为其工作负载趋向于单一实体的多个属性（存储在很多的列中）。由于这些应用程序都是基于行工作的，所以在使用时，从硬盘中获取的页面数量是最小的。

如果能对列中的数据进行有效的处理，某些工作负载会运行得更高效。在线分析处理（OLAP）工作负载常常需要收集列中的数据。例如，如果你想要知道标记为“2013 Total Order”列中的所有值，当你使用基于列的数据库时，你可以将这一列放到内存中并统计所有值。但当使用的是基于行的数据库时，就必须去访问每一行而获取对应的数据。

当然，事实并非如此。基于行的数据库，例如DB2 for i，已经增加了一些方法，这些方法可以使得，诸如“sum a column”这样简单的操作，或者更复杂一些的OLAP分析也可以很高效的得到处理。例如，DB2 for i有两种结构，分别是编码向量索引（EVIs）和物化查询表（MQTs），对于这样的操作都有很好的效果。并且DB2 for i给用户的数据是成批的（一次读取很多行），而不是一次一个。除此之外，用户自定义的方法也可以用来提高性能。IBM的存储管理组件也是非常智能的，值得一提的是，它实现了单级存储。正因为它如此的智能，所以在用户提出请求前，已经将数据读取到内存中。正因为在很多的OLTP工作负载中都要求顺序地通过行，而DB2 for i在需要数据之前，已将行数据批量的读取到内存中，可见这个功能是非常重要的。

另一方面，单纯给列式存储的表加索引，也不能使OLTP很高效。Mark曾经说过“这就像把很多的矮胖子放在一起”。行信息分散在很多存储页中。即使整个数据库都存放在内存里，也需要消耗大量的CPU资源，来将一行中的所有列拼接起来。

下面总结这一课的关键内容。在选择使用哪种数据库时，问自己这样一个问题，哪种工作负载是你的数据库需要支持的最关键的工作负载。尽管可能你两种操作都需要，但是当核心业务是OLTP时，一个行式的数据库，再加上数十年积累的优化操作，可能是最好的选择。如果你的企业并不需要快速处理OLTP业务，但需要可以快速处理OLAP时，那么一个列式的数据库将会成为你的不二选择。

如果你需要同时处理两种业务，且要求它们都能高效处理时，可以去了解两种种架构相关的混合技术。你可以选择一种，又或者是使用两种架构的结合来满足你的需求。无论你选择了何种类别，都要确保证这一解决方案是稳定的，这可是要用来切实为企业数据服务的。

到此，尊敬的读者们， DB 102就结束了.现在，当你再读到有关列式数库的文章时，就可以理解其引起讨论的原因了。

在下次的讨论中，我们将进一步学习。

翻译：周松文

转载请注明本文出处：大学之旅_谙忆

Github：https://chenhaoxiang.github.io/

专家 数据库

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。