Java 行数据库与列数据库在信息检索中的区别

最近，我开始研究HBase（一种面向列的数据库）。在浏览源代码时，有一个问题不断出现在我的脑海中。我想问这个问题。 我的问题是，面向行的数据库究竟如何处理信息检索（比如选择查询），而面向列的数据库又有什么不同。 以及这些数据库在底层平面文件中存储数据的不同之处（在一天结束时，每个数据库都使用文件）

如果我在这个问题的任何部分出错，请务必纠正我

问候,，

---

Krishna

您的问题的一个问题是，NOSQL社区使用了长期存在的数据库术语“面向列”（column-oriented）（有些人可能会说“jacked”！）来描述与最初含义完全不同的内容。“面向列”的两种含义仍然很流行，但它们指的是非常不同的DBMS产品。因此，澄清你正在谈论的内容通常是有益的。在本例中，这是术语的NOSQL含义

在面向列的数据库的最初含义中，问题的答案是检索信息的方式没有区别。列存储不是一种不同的数据模型，它只是内部存储中不同类型的表示

然而，在NOSQL社区中，术语列存储指的是另一种数据模型

这里有很好的解释：

---

如果我理解正确，您对底层存储和检索问题更感兴趣，而对DDL和定义问题（面向列的数据库的类别）感兴趣，对吗

我假设您了解，几乎所有的存储，无论供应商如何，都是某种形式的：

• 索引的B-树
• 未组织数据的堆

在这个基础之上，每个供应商都有优化和专利专业。例如，Sybase（世界其他地区）有：

• 聚集索引，它将数据行与B树相结合，并消除堆

下一个问题是，所有供应商（oracle除外）都有相当复杂的引擎，采用模块化设计，I/O以低水平异步处理，以获得速度。I/O的单位是一页。OLTP系统通常为2到8KB，DSS通常为8到64KB。（注意避免了行与列的问题。）因此，不管行/列如何，DSS引擎都是为大规模检索而构建的，因为在大的块中获得更多的索引/数据行或列，而I/O请求更少

“大I/O”可以通过一个I/O请求将扩展数据块（8页）和更大的分配单元（256页）读入内存来执行。但基本单位是页面

行与列

• 行
  
  • 每一行是页面上的一个连续单元，许多行被打包到页面中
  • 对于索引，这并不重要，因为整个数据结构是键中的复合列；索引项或记录是一个小的索引项+指针，更多的索引项被打包到相同的页面中
  • 对于少量行，它们的速度非常快；汇总列集合时速度较慢
    .
• 纵队
  • 每列都是页面上的一个连续单元。由于该列可能有数百万个条目（行）长，因此它们可以运行很多很多页面
  • 索引与上一行相同。添加了一种专门的索引形式，该索引对于专栏导航来说应该更快
  • 对于柱状聚集体，它们是显著的；从基于列的数据构造行时非常慢

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

结果是上述结果的乘法

• 小/大区块大小，次

• 潜在的物理结构、时间

• 行/列方向

这就是你要找的吗？Sybase ASE是一个OLTP/DSS严格面向行的引擎，上面有一组技术（不是温暖和模糊）图，如果您感兴趣，我可以亲自动手

对评论的答复 .
您的意思是说，不管数据库类型如何，最终我们将归结为页面

对

如果是这种情况，那么将如何对数据库进行集群。让我们以一个按行存储数据的数据库为例。如果我为这种类型的数据库进行集群，那么表的结构将如何精确地传递到不同的节点（如果我有多个节点）。此表结构是链接到页面还是通过不同的机制链接到页面

你知道，在我回答这个问题之前，我必须承认你。对于像你这样有知识水平的人来说，你能深入到关键点，获得洞察力，这是非常棒的。Shiva ki Jai

是的，这是集群DBMS的关键设计问题，关键限制问题，首先是与集群相关的各种设计问题；如果供应商能够很好地处理这个问题，集群就会很好地工作；如果不是的话，集群就是狗的早餐

其中的一切都受物理定律的支配。没有什么是免费的，每个功能都有成本、处理或存储。除了微软的营销手册之外，没有什么神奇的东西

良好的集群数据库体系结构

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

• Oracle RAC的存在时间更长，更为成熟。它处理这一关键问题相当糟糕。因此，它最终与自身抗争，需要比最初估计更多的CPU能力（核心、CPU，而不是节点）。节点越多，争用就越多。
  .
  它是