java - 行数据库和列数据库在处理信息检索方面的区别

Question

最近，我开始研究HBase(面向列的数据库之一)。在查看源代码时，一个问题不断涌入我的脑海。想问这个。
我的问题是，面向行的数据库如何准确地处理信息检索(例如选择查询)，而面向列的数据库又有什么不同。
这些数据库在底层平面文件中存储数据的方式有所不同(最终，每个数据库都使用文件)。

如果我在此问题的任何部分出了错，请务必纠正我。

问候，
克里希纳

Answer 1

如果我对您的理解正确，那么您对底层存储和恢复问题更感兴趣，而对DDL和定义问题(面向列的dbs的类别)更感兴趣。

我将假设您了解几乎所有存储，无论是哪个供应商，都是某种形式的:

索引的B树

用于处理非组织数据的堆

在此基础之上，每个供应商都有优化措施，并获得专利专长。例如。 Sybase(行)具有:

聚簇索引，它将数据行与B树结合，并消除了堆。

下一个问题是，所有供应商(除oracle外)都具有相当复杂的引擎，具有模块化设计，并且I/O在较低级别上异步处理以获得速度。 I/O的单位是页。对于OLTP系统，通常为2至8KB，对于DSS，通常为8至64KB。 (注意，我避免了行与列的问题。)因此，无论以行/列为单位，DSS引擎都是为大规模检索而构建的，这是因为在大块中以更少的I/O请求获得了更多的索引/数据行或列。

可以通过一个I/O请求将范围(8页)和较大的AllocationUnit(256页)读入内存来执行“大I/O”。但是基本单位是Page。

行与列

行

每行是页面上的连续单元，并且在行中打包了许多行。

对于索引来说，这并不重要，因为整个数据结构是键中的复合列。索引条目或记录是一个小的索引条目+指针，并且更多的索引条目打包在同一页中。

对于少量行，它们非常快；汇总列汇总速度慢
。

栏

每列是页面上的连续单元。而且由于该列可能有数百万个条目(行)长，因此它们可以运行许多页。

索引与上面的行相同。通过添加特殊形式的索引，该索引对于列式导航应该更快。

对于柱状骨料，它们是惊人的。从基于列的数据

构造行非常慢

针对引擎执行的所有查询都必须导航索引，从上述数据存储结构中检索数据行/列。

结果是上述乘积；

小/大块大小，时间

基础物理结构，次

行/列方向

那是你要找的东西吗？对于Sybase ASE，这是一套严格的面向行引擎OLTP/DSS的引擎，上面有一组技术图(不是温暖的和模糊的)，如果您有兴趣的话，可以尝试一下。

对评论的回应

。
您的意思是说，不管数据库类型如何，最终我们都会归结为页面。

是的。

如果是这种情况，那么如何完成数据库集群。让我们以一个以行方式存储数据的数据库为例。如果我要为这种类型的数据库进行集群，那么将如何将结构化的表精确地传送到不同的节点(如果我有多个节点)。该表结构将链接到页面还是通过其他机制。

你知道，在我回答问题之前，我必须承认你。对于具有您一定知识水平的人，您能够深入到关键点并获得洞察力是非常棒的。 Shiva ki Jai!

是的，这是集群DBMS的关键设计问题，关键的限制问题，首先是与集群相关的各种设计问题；如果供应商能够很好地处理此问题，则集群可以正常运行；如果没有的话，集群就是狗的早餐。

IT中的一切都由物理定律支配。没有什么是免费的，功能的每个功能都有成本，处理或存储费用。除了MS营销手册以外，没有任何魔术。

好的集群数据库架构

我不知道所有集群DBMS；我非常了解Sybase CE和Oracle RAC。 Sybase IQ的工作知识。

Oracle RAC 已经存在很长时间了，并且更加成熟。它非常严重地处理了这个关键问题。因此，它最终无法与自己竞争，并且需要的CPU能力(核心，CPU而非节点)要比原始估计更多。节点越多，争用就越多。
。
应当指出，Oracle非RAC体系结构是废话，或更确切地说是不存在的。因此RAC具有坚实的基础。
。
更不用说，稳定性糟透了死熊。
。

Sybase CE 只有一岁。但是该体系结构很棒，可以很好地处理这个关键问题。 SAN上该页面只有一个版本。所有节点均已连接到SAN。任何节点都可以读取或写入页面。节点通过专用LAN连接(除了网络上其他所有设备使用的普通客户端-服务器LAN)。节点协调锁以及一些节点间通信，以实现平衡负载等。
。
最终，即使使用Sybase CE，也要获得最大的并发性，就需要对数据库进行逻辑分区，以便分离每个节点上的工作负载，访问不同的文件路径或共享db的单独物理区域。

Sybase IQ 已经100％面向列。这是他们的DW产品。它已经进行了完整的负载平衡。可以将其用作群集，但不能在上述CE意义上使用群集。我应该把它包含在

中

集群数据库架构较差

狗早餐类型的群集dbms做愚蠢的事情。列举一些:

将页面存储在每个节点上[大规模复制]，但随后必须在集群

周围移动更新的页面

使用MVCC来解决此问题(但MVCC开销更大，实际上减慢了并发性，因此它正在与自己抗衡)

群集不适用于专用数据库服务器

基本上，群集对于某些应用程序来说非常有用，但是对于专用数据库服务器来说这是个愚蠢的主意(一个事实集中在一处；共享资源一起管理；锁争用在一个地方进行管理时效率最高，因为数据位于一个地方)。我永远不会为数据库服务器推荐群集。

与SAN问题相同。当然，许多人的数据库存储都位于SAN内，但是为了获得最高速度以及与连接到SAN的其他服务器的负载问题隔离，没有什么比本地磁盘更合适了。

与VMWare问题相同。当然，有许多人将数据库服务器建立为VMWare主机单元，但是为了获得最高速度，请消除VMWare的开销；为了与机箱中其他主机部件的负载问题隔离开来，请将其从那里拿到专用的硬盒中。

为什么数据库供应商会打扰群集

哦，这是有值(value)的，但将来不会。随着时间的流逝，Sybase体系结构将占主导地位，所有其他体系结构将被淘汰。每个供应商都将照常复制它。

Sybase CE的真正功能是:

是100％的正常运行时间(能够将一个节点添加到集群并将旧节点关闭进行维护)和

完全动态负载平衡(例如，现有节点为4 x四核；添加一个临时4 x四核节点；关闭旧节点；插入2 x四核；启动它；关闭临时节点)，然后在60秒内，没有任何键盘上的手指，整个野兽就会重新平衡。

一家商店可能会错开其几个单节点服务器的每晚db维护计划，因此可以节省大量资金；他们只有几个附加的机器用于切入/切出。

数据仓库有些不同。它们大多是只读的。因此，将其托管在群集上是没有问题的(许多读取器节点，只有一个写入器节点，没有争用，没有人关心页面在被读取时是否在被写入)。 Sybase IQ就是这样的产品。

面向列的ojit的Sybase CE

Sybase IQ已经面向列，可以部署在群集中，但不能从上述的CE角度进行群集。列映射到页面。我应该将其包含在上面的“良好集群Db体系结构”中，现在进行了更正。

我不知道混合使用面向列和面向行的混合程序是值得的。

但是，该问题的完整答案是，使用纯Db(而不是DW)(例如Sybase ASE或ASE/CE)，并实现真正的第六范式数据库。那就是最终归一化，即不可归约的NF，它具有几个实质性的优点，包括速度和枢转的容易性。它在页面上提供了面向列的存储。由于SQL不完全支持6NF，因此您将需要提供“ View ”以从(存储的)6NF结构中提供5NF行。我编写了目录的扩展，以便可以生成供开发人员使用的SQL代码。