Skip to Content

原文作者:David Dobrin

在我开始之前,道歉一下:

本博客文章,试图纠正我在以前的关于SAP HANA微博中的一个被很多次引用的错误。我说HANA是“或者是面向列或面向行”。正确的是面向行<it>和</it>列。错误的是非黑即白的论断。 “大卫,你知道没有一种魔杖你可以的只是挥手就能掌控它,”原来的设计师之一告诉我。 “这没有那么简单。”

然后,在这一块,我硬着头皮,并解释它是如何“真正”工作的,那就是,一个单一的数据库,包含行和列的表,如何既行面向<it>,又</it>列面向?

首先, HANA的是一个数据库。在数据库中,有表。表基本上是空白的空间,在那里你可以载入记录的字段集合。在面向行的数据库,表中的每一行包含一个记录,记录中的每个领域中占有的空间,即使是没有实际数据。

下面是一个例子。想象一个家庭地址表,其中包含一些人的姓氏,街道,城市,电话号码。 (每个被称为一个字段。)在一个面向行的表,填好表将包含很多行(或“行”),为每个地址。每行包含所有的值,但如果,例如,你没有一个电话号码,电话号码的空间将被留空。

在面向列的表,每个领域都占据一个单独的列。当你载入一个地址,你不要在同一行载入所有信息。你只需要添加任何需要的值。所以假使你只要姓氏“姓”一栏,全市“城市”一栏,别的就不必添加。

那么,面向列的表如何知道数据实际上是“属于”你加载的某些其他值吗? (技术术语是“纪录”。),基本上handwaving警报!每个值有一个标签,有另外一张表,你用标签去查询这个值属于哪条记录。

你可以看到一个面向行的表更容易来了解概念,它像一个电子表格中的行,但一个面向列的表节省了更多的空间,事实证明,列存储下读取数据的速度也是很快的。

有关HANA有一篇非常有趣的文章(Sikka等,“高效的事务处理的SAP HANA的数据库 – 一列存储神话的终结”。),Sikka描写到,面向行的表是“写优化”和面向列表的“读优化,”这是公平的描述的两种表“的重要优势。使用行方式写数据。用列方式分析和读取数据。

大多数数据库选择他们打算如何操作。数据库中的所有表都将是面向行的,或所有数据库中的表要面向列。

但HANA不是的,一个表可以是面向行或面向列,由程序员(或数据设计)决定。

但是这还不是全部就是这么回事。因为,一个程序员,在HANA里面,选择行<it>或</it>列和别处是不一样的。在HANA中,如果您决定表是要面向列的,不一定放弃了写优化(行表擅长)。 HANA有一个内部系统面向列的表,允许你输入面向行的数据,然后推入列面向数据表,而不损害面向列的表的性能。

因此,HANA的是面向行的<it>和</>面向列。A:它允许你创建无论是面向行的表或面向列的表。 B.如果您创建面向列的表,面向列的表的数据录入有面向行的缓冲区,这是写优化,从而好像它是一个行的表。

写优化列

了解如何做到这一点是值得的,因为它给你一些洞察到HANA是如何使用内存。

PastedGraphic-1.jpg
图4。统一的概念表概述

来源:“高效的事务处理在SAP HANA的数据库 – ”Vishal Sikka等,页731-741。一列存储神话的终结。

HANA的列表可以像行存储有一个简单的理由:这是行存储。正如你从上图中可以看到,有一个缓冲区存储(L1),这是面向行的。数据到L1。

每隔一段时间,一个L1缓存有效地关闭,把它的数据插入到一个面向列的缓冲区(L2)。这涉及到典型的面向列的东西,其中的值添加到各自的列, 他们属于的记录被记在另一张表中。


每隔一段时间,关闭L2缓冲区,数据推到主存储区。

它首先把数据存储到“写优化”行存储(L1)。然后,它需要把数据结构重组,接着把数据推到了L2,这是面向列的。最后,它把数据推到主列存。


这个过程将是古怪拜占庭和缓慢的,如果它不是在内存中做(或并行做)。但由于L1和L2和最后一列存储都在内存中,所有的处理都是在内存中完成,它都可以在后台完成。因为L1和L2操作都比较小,他们的数据可以提供给其他数据库操作。

所以,举例来说,如果你运行一个列数据库查询,而同时另一些数据被添加,查询只检查L1和L2,以及主列存,因为L1和L2总是相对较小,查询在内存中完成,这样的性能开销很小。

你什么时候使用行或列:一个人的意见

你可以看到,为何我解释背后HANA的设计理念。 L1,L2写优化,bla,bla,如果你想知道它做什么这很重要。但很难把握,如果你只是想获得的想法。

此外,肤浅的学习是一件危险的事情。当你知道事情,你开始问问题。为什么提供这么多的灵活性?到底有什么好处?人们将如何使用它呢?如果我们在肤浅的水平工作,你就问不出这样的问题。

但现在,我已经给你的细节,我有责任解释此行和列的东西是什么做的。我回答不了更多。所以我问在HANA上面做产品的人

我开始与Adam,Their,其在SAP的职位包括“数据库”和“架构师”等关键字。

为什么和什么时候使用行表,什么时候使用列表?


“我是一个财务软件开发人员[他过去在海波龙的Essbase的工作,现正在SAP的EPM工作]在一个长期的柏拉图关系枯燥的算法,如”折旧“和”分配“;我咬咬牙想让基本的代数运算在关系型数据库中运作如飞,我在90年代转向列的存储概念并且永不回头。我通常总是从有异常长的文本开始(如描述的东西)。

“然而,即使在HANA的世界,这不是固定的因为文本分析的奇妙。”

所以,如果你对数据做计算,你使用列,如果你做其他事情,像存储文本,然后你使用行,除非你硬是不用。

这似乎够明确。

你什么时候使用列,行:另一个人的意见

我也问了Vijay Vijayasankar


HANA有行和列的存储方式,没有技术上面的限制,我的简单的规则是使用列存储,直到发觉是不对的。

“所有数据都将被存储在多个表,所以你还需要考虑你将如何join表。表现最差的是应用程序试图join行存储的表和列存储的表。


“有其他方面的限制,你不能建立一个列视图基于行表,在HANA动的时刻行表装入内存,查询需要时列表被加载到内存。

所以,当使用行的时候列的性能更好,你使用列的方式。

所以,有什么关系吗?


“优美之处是HANA不关心这个,我就可以开始时候用列表表示,如果不行,可以重新配置行的存储方式”。

简单而富有成效

在我早期的博客,我说,有太多的测试适用于HANA的设计。它简化了吗?和它是富有成效的吗?

这篇文章似乎表明,有一个“简化”的判定标准。但我认为这是形势的误读。

首先,很明显,即使在简单的情况下,列表被创建,因为你想要的是超快的分析。

*在这个设计中,例如,列表可以不断更新,而在大多数分析数据库不能。 (你需要抽出时间来REINDEX)。

*在这个设计中,视图 – 像你看到在大多数分析数据库的多维视图 – 和表结构在逻辑上是独立的,所以你可以做很多不同的视图,包括不重建表做代数视图,你可以改变按你想法改变视图。

*在这样的设计中,你可以嵌入在数据库中的统计函数一样的东西,而在大多数分析数据库,你要拉出来数据,做统计分析。

更复杂的情况?我不确信我们还知道答案。我们所知道的是,当你问那么如何使用“行和列”结构,至少有两个敏锐的数据库开发者都说,“视情况而定”。这可能是因为结构不是那么的有用,但它也可能是亚当介绍的灵活性,给你很多选择。

在这一点上,应该有一个绝对清晰的思路,人们应该如何使用这种灵活性?

我不认为如此。当然,你发现一个类似于最初的电动车流程的设计。基本的设计理念是在1912年凯迪拉克电池供电的点火系统。但在当时,没有一个很肯定它会走向何处。原来的设计师也大多只是想摆脱一个汽车设计的限制,事实上,你不得不转动曲柄启动汽车。 (据传说,发明了一个任性的曲柄的想法后,打破了他的一个朋友的下巴,后来死于坏疽)。他们肯定看到更多的想法。但现代汽车电气系统在完全成熟前至少要花10年来进行反复试验。

作者简介

我在马萨诸塞州的剑桥,运行一个小的分析师公司,它做企业应用的大部分领域的战略咨询。我不是一个数据库专家,但在过去的一年,我已经做了很多与HANA有关的学习。所以我还是比较熟悉的。

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply