java – 在处理信息检索中面向行和面向列的数据库之间的区别

前端之家收集整理的这篇文章主要介绍了java – 在处理信息检索中面向行和面向列的数据库之间的区别前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
最近,我开始研究HBase(一个面向列的数据库).在通过源代码的时候,一个问题不断涌现在我的脑海中.想到这个问题
我的问题是,一个面向行的数据库如何处理信息检索(比如一个select查询),以及当面向列的数据库时有多不同.
并且这些数据库如何将数据存储在底层平面文件中(在最后一天,每个数据库都使用文件).

如果我在这个问题的任何部分出错,请纠正错误.

问候,
克里希纳

解决方法

如果我正确理解你,你对基础存储和retreival问题更感兴趣,而在DDL和定义问题中,更少的是面向列的dbs的类别,对吗?

我会假设你明白,几乎所有的存储,无论供应商,是某种形式:

>指数的B树
>一个无组织数据的堆

在这个基础之上,每个供应商都有优化和专利专长.例如. Sybase(row)具有:

>集群索引,它将数据行与B-Tree结合,并消除堆.

下一个问题是,所有的供应商(除了oracle)都有相当复杂的引擎,采用模块化设计,并且I / O处于异步状态,处于低水平,以获得速度. I / O单位是页面. OLTP系统通常为2〜8KB,DSS通常为8〜64KB. (注意我避免了Row vs Column问题.)所以,无论行/列,DSS引擎都是为大量检索而构建的,因为在大块中获得更多的Index / Data行或列,具有较少的I / O请求.

可以通过一个I / O请求读取内存(8页)和更大的分配单位(256页)到内存中执行“大I / O”.但基本单位是Page.

行vs列

>行

>每一行是页面上的一个连续的单元,并且多个行被打包到页面中.
>对于指数,这并不重要,因为整个数据结构是关键字中的复合列;索引条目或记录是一个小的索引条目指针,并且更多的索引条目被打包到相同的页面中.
>他们对于小行数非常快;总结列聚集缓慢
.

>栏

>每列是页面上的连续单位.并且由于列可能是数百万条目(行)长,它们运行了很多页面.
>指数与上述行相同.通过添加专门的索引形式,应该更快地进行柱状导航.
它们对于柱状聚集体是非常显着的;从基于列的数据构建行非常慢

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

结果是上述的乘法;

>小/大块大小,次数
>底层物理结构,时代
>行/列方向

那是你在找什么?对于Sybase ASE,有一组技术(不是温暖和模糊的)图表,一个OLTP / DSS严格的面向行的引擎,如果你有兴趣,我可以得到我的手.

回应评论

.
你的意思是说,最终我们将归结到页面,而不管数据库类型.

是.

如果是这种情况,那么数据库的聚类将如何完成.让我们拿一个数据库来存储数据.如果我正在为这种类型的数据库进行聚类,那么将如何将表结构承载到不同的节点(如果我有多个节点).这个表结构会链接页面还是将通过不同的机制.

你知道,在我回答这个问题之前,我必须承认你.对于有知识水平的人来说,您已经深入到了关键点,获得了洞察力.湿婆i ai!

是的,这是集群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,您也需要在逻辑上对数据库进行分区,以使每个节点上的工作负载分开,访问不同的文件路径或共享数据库的单独的物理区域.
> Sybase IQ已经是100%的列导向.这是他们的DW产品.它已经完成了负载均衡.可以使用的是一个集群,但不是在上述CE认证中聚类.我应该把它包含进来

差的群集数据库架构

狗早餐类型的聚集dbms做愚蠢的事情.列举几个:

>将页面存储在每个节点上[大规模复制],但是必须在集群周围移动更新的页面
>使用MVCC来克服这个问题(但是MVCC的开销更大,实际上减慢了并发性,所以它正在战斗)

集群不适合专用DB服务器

基本上,集群对于某些应用程序来说非常棒,但是对于专用的数据库服务器来说,这是一个愚蠢的想法(一个事实在一个地方;一起管理的共享资源;锁争用,在一个地方管理时是最有效的,因为数据在一个地方).我不会推荐一个数据库服务器的集群.

>与SAN问题相同.当然,很多人都将数据库存储位于SAN中,但是要达到最高速度,并且与连接到SAN的其他服务器的负载问题隔离开来,则没有任何东西靠近本地磁盘.
>与VMWare问题相同.当然,很多人都将数据库服务器建立为VMWare主机,但是以最高的速度,删除了VMWare的开销;为了与机箱中其他主机单元的负载问题隔离,将其从该处卸载到专用硬盒上.

为什么数据库供应商厌倦了集群

哦,这里有价值,但不是现在,在将来. AFAIC,Sybase架构将随着时间的推移而占主导地位,而其他所有其他项目都将落后.每个供应商都会照常复制.

Sybase CE的实力是:

>真正的100%正常运行时间(能够将一个节点添加到集群,并将旧节点关闭进行维护)和
>完全动态负载平衡(说现有的节点是4 x四核;添加一个temp 4 x四核心节点;把旧节点放下;插入2 x四核;启动它,把temp节点下降),然后在60秒内,任何键盘上都没有手指,整个野兽重新平衡.

一个可以错开其几个单节点服务器的夜间数据库维护计划的商店可以节省大量资金;他们只需要几台额外的机器来切换进出.
>数据仓库有所不同.它们大都是只读的.因此,在集群上托管它是没有问题的(许多阅读器节点,只有一个编写器节点,没有争用,没有人关心这些页面正在被读取时被写入). Sybase IQ是这样的产品.

用于面向列的Sybase CE

> Sybase IQ已经面向列,可以部署在集群中,但不能在上述CE认证中进行集群.列映射到页面.我应该把它包含在上面的“好的聚类Db架构”中,现在更正了.>我不知道组合列和行的有价值的混合动力.>但是对于这个问题的完整答案是使用纯粹的Db(而不是DW),如Sybase ASE或ASE / CE,并实现一个真正的第六个普通格式数据库.这是最终的规范化,不可约束的NF,具有几个显着的优点,包括速度和易于转动.它在页面上提供了面向列的存储.由于sql不完全支持6NF,您将需要提供视图以从(存储的)6NF结构提供5NF行.我写了一个扩展到目录,所以我可以生成sql代码供开发人员使用.

猜你在找的Java相关文章