在我开始之前，道歉一下：
本博客文章，试图纠正我在以前的关于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是如何使用内存。
图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有关的学习。所以我还是比较熟悉的。
- SAP Managed Tags:
