gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-12-03 23:15:25 26 4
gpt4 key购买 nike

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

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

问候,
克里希纳

最佳答案

如果我对您的理解正确,那么您对底层存储和恢复问题更感兴趣,而对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代码。
  • 关于java - 行数据库和列数据库在处理信息检索方面的区别,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/4152100/

    26 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com