最近,我开始研究 HBase(面向列的数据库之一)。在浏览源代码时,一个问题一直在我脑海中浮现。想问这个。我的问题是,面向行的数据库究竟如何处理信息检索(比如选择查询),以及面向列的数据库有何不同。以及这些数据库在底层平面文件中存储数据的不同之处(最终,每个数据库都使用文件)。
如果我在这个问题的任何部分出错,请纠正我。
问候,克里希纳
最近,我开始研究 HBase(面向列的数据库之一)。在浏览源代码时,一个问题一直在我脑海中浮现。想问这个。我的问题是,面向行的数据库究竟如何处理信息检索(比如选择查询),以及面向列的数据库有何不同。以及这些数据库在底层平面文件中存储数据的不同之处(最终,每个数据库都使用文件)。
如果我在这个问题的任何部分出错,请纠正我。
问候,克里希纳
如果我理解正确,您对底层存储和检索问题更感兴趣,而不是 DDL 和定义问题,面向列的数据库的类别,对吗?
我假设您了解几乎所有存储,无论供应商如何,都是某种形式:
在此基础上,每个供应商都有优化和专利专业化。例如。Sybase(行)具有:
下一个问题是所有供应商(除了 oracle)都有相当复杂的引擎,采用模块化设计,并且 I/O 在低级别异步处理以获得速度。I/O 的单位是页。OLTP 系统通常为 2 到 8KB,DSS 系统通常为 8 到 64KB。(注意我避免了行与列的问题。)因此,无论行/列如何,DSS 引擎都是为大规模检索而构建的,因为在大块中获得更多的索引/数据行或列,而 I/O 请求更少。
“大 I/O”可以通过一个 I/O 请求将 Extents(8 页)和更大的 AllocationUnits(256 页)读入内存来执行。但基本单位是页面。
行与列
针对引擎执行的所有查询都必须导航索引,从上述数据存储结构中检索数据行/列。
结果是上面的乘法;
小/大块大小,次
底层物理结构,时代
行/列方向
那是你要找的吗?上面有一组 Sybase ASE 的技术(不是温暖和模糊的)图表,一个 OLTP/DSS 严格面向行的引擎,如果你有兴趣,我可以得到。
.
您的意思是说,无论数据库类型如何,最终我们都会归结为页面。
是的。
如果是这种情况,那么数据库的集群将如何完成。让我们看一个以行方式存储数据的数据库。如果我正在为这种类型的数据库进行集群,那么表结构将如何准确地传送到不同的节点(如果我有多个节点)。将这个表结构链接到一个页面还是会通过不同的机制。
你知道,在我回答这个问题之前,我必须承认你。以你这样的知识水平,能深入到那个关键点,得到那个洞见,真是太好了。湿婆奇杰!
是的,这是集群 DBMS 的关键设计问题,关键的限制问题,尤其是与集群相关的各种设计问题;如果供应商很好地处理了这个问题,则集群运行良好;如果没有,集群就是狗早餐。
IT 中的一切都受物理定律的支配。没有什么是免费的,功能的每一个功能都有成本、处理或存储。没有魔法,除了可能在 MS 营销手册中。
良好的集群数据库架构
我不知道所有的集群 DBMS;我非常了解 Sybase CE 和 Oracle RAC。Sybase IQ 的工作知识。
Sybase CE只有一岁。但该架构非常出色,它很好地处理了这个关键问题。SAN 上只有一个页面版本。所有节点都连接到 SAN。任何节点都可以读取或写入 Page。节点通过专用 LAN 连接(除了网络上其他所有设备使用的普通客户端-服务器 LAN)。节点协调锁加上一点节点间通信以实现负载平衡等
。
归根结底,为了获得最大的并发性,即使使用 Sybase CE,您也需要对数据库进行逻辑分区,以便每个节点上的工作负载是分开的,正在访问不同的文件路径,或者共享数据库的单独物理区域。
Sybase IQ已经 100% 面向列。这是他们的 DW 产品。它已经完成了完全负载平衡。它可以用作集群,但不能用于上述 CE 意义上的集群。我应该把它包括在
糟糕的集群数据库架构
集群 dbms 的狗早餐类型会做一些愚蠢的事情。列举几个:
将页面存储在每个节点上[大量重复],但随后必须在集群中移动更新的页面
使用 MVCC 来解决这个问题(但是 MVCC 的开销要大得多,实际上会减慢并发速度,所以它正在与自己作斗争)
不适合专用数据库服务器的集群
基本上集群对于某些应用程序来说非常有用,但对于专用数据库服务器来说这是一个愚蠢的想法(一个事实在一个地方;共享资源一起管理;锁争用在一个地方管理时最有效,因为数据在一个地方)。我永远不会为数据库服务器推荐集群。
与 SAN 问题相同。当然,许多人的数据库存储位于 SAN 中,但为了获得最高速度,并与连接到 SAN 的其他服务器的负载问题隔离,没有什么能比得上本地磁盘。
与 VMWare 问题相同。当然,很多人都将db server建立为VMWare主机单元,但是为了最高速度,去掉VMWare的开销;为了与机箱中其他主机单元的负载问题隔离,请将其从那里取出,放到专用的硬盒上。
为什么数据库供应商会为集群烦恼
哦,它有价值,但不是现在,而是将来。AFAIC,随着时间的推移,Sybase 体系结构将占主导地位,而所有其他体系结构都将被淘汰。每个供应商都会照常复制它。
Sybase CE 的真正强大之处在于:
真正的 100% 正常运行时间(能够将节点添加到集群并关闭旧节点进行维护)和
完全动态负载平衡(比如现有节点是 4 x 四核;添加一个临时 4 x 四核节点;关闭旧节点;插入 2 x 四核;启动它;关闭临时节点),然后在60 秒,没有手指在任何键盘上,整个野兽重新平衡。
一家可以错开几台单节点服务器的夜间数据库维护计划的商店,可以节省相当多的钱;他们只有几台额外的机器用于切换进/出。
数据仓库有点不同。它们大多是只读的。因此,将它托管在集群上是没有问题的(许多读取器节点,只有一个写入器节点,没有争用,没有人关心页面正在被读取时被写入)。Sybase IQ 就是这样的产品。
面向列的 Sybase CE
Sybase IQ 已经是面向列的,可以部署在集群中,但不能部署在上述 CE 意义上的集群中。列映射到页面。我应该将它包含在上面的Good Clustered Db Architecture中,现在更正了。
我不知道混合面向列和面向行的混合是否值得。
但该问题的完整答案是,使用纯 Db(而非 DW),例如 Sybase ASE 或 ASE/CE,并实现真正的第六范式数据库。这就是最终的归一化,即不可约的 NF,具有几个实质性优势,包括速度和易于旋转。它在页面上提供面向列的存储。由于 SQL 不完全支持 6NF,您需要提供视图以从(存储的)6NF 结构中提供 5NF 行。我为目录编写了一个扩展,以便我可以生成供开发人员使用的 SQL 代码。
您的问题的一个问题是,长期存在的数据库术语“面向列”已被 NOSQL 社区占用(有些人可能会说“被劫持”!)来描述与最初含义完全不同的东西。“面向列”的两种含义仍然适用,但它们指的是非常不同的 DBMS 产品。因此,澄清您在谈论的内容通常很有帮助。在这种情况下,它是该术语的 NOSQL 含义。
在面向列的数据库的原始含义中,您的问题的答案是您检索信息的方式没有区别。列存储不是不同的数据模型,它只是内部存储中不同类型的表示。
然而,在 NOSQL 社区中,术语列存储是指一种不同类型的数据模型。
这里有很好的解释:
http://dbmsmusings.blogspot.com/2010/03/distinguishing-two-major-types-of_29.html
面向行的数据库,又名“传统 RDBMS”(如 MySQL、Oracle、DB2)使用事务二级索引更新,在大多数情况下使用 B-Tree 式二级索引结构
面向列的数据库,又名“NoSQL”(例如 Google Big Table、HBase、Cassandra)对主键索引(不是 B-Tree)使用简化的结构
面向列的数据库不支持“传统”事务二级索引。维护“倒排索引”是用户的责任。
Cassandra 支持行的类似 B-Tree 的索引:行中的每个单元格都有一个标题,并且单元格按标题进行物理排序。
另一个(可能是非常重要的)区别:对于 Oracle 中的无数条记录,您需要为主键维护 B-Tree,它的大小也将类似于无数条记录;“按主键查找”的性能不好。
另一方面,您可以在 Cassandra 或 HBase 中拥有“宽行”,并将相似的“单元格”合并为单个宽行;“主键索引”的大小变小了数百万倍,并且“按主键查找”超级快(而且它不是 B-Tree;它是聚集搜索)