Kri*_*hna 9 java database database-design hadoop hbase
最近,我开始研究HBase(面向列的数据库之一).在浏览源代码时,一个问题不断涌现.想到这个想法.我的问题是,面向行的数据库究竟是如何处理信息检索(比如选择查询)以及面向列的数据库时的不同之处.这些数据库在底层平面文件中存储数据的方式有多么不同(在一天结束时,每个数据库都使用文件).
如果我在这个问题的任何部分出错了,请纠正我.
此致,克里希纳
Per*_*DBA 10
如果我理解正确,那么您对底层存储和撤销问题更感兴趣,而DDL和定义问题,列导向dbs的类别则更少,对吧？
我将假设您了解几乎所有存储,无论供应商是什么,都是以下形式:
除此之外,每个供应商都有优化和专利专业化.例如.Sybase(行)有:
下一个问题是所有供应商(除了oracle)都有相当复杂的引擎,采用模块化设计,并且I/O在低级别异步处理以获得速度.I/O单元是一个页面.对于OLTP系统通常为2到8KB,对于DSS通常为8到64KB.(注意我避免了Row vs Column问题.)因此,无论行/列如何,DSS引擎都构建用于批量检索,因为在大块中获得更多的索引/数据行或列,I/O请求更少.
通过使用一个I/O请求将Extents(8 Pages)和更大的AllocationUnits(256 Pages)读入内存,可以执行"大I/O".但基本单位是Page.
行与列
针对引擎执行的所有查询都必须导航索引,从上述数据存储结构中检索数据行/列.
结果是上面的乘法;
小/大块,时间
潜在的物理结构,时代
行/列方向
那是你在找什么？对于Sybase ASE,一个OLTP/DSS严格面向行的引擎,上面有一组技术(非温和模糊)图表,如果您有兴趣,我可以动手.
.
你的意思是说,无论数据库类型如何,我们最终都会归结为页面.
是.
如果是这种情况,那么将如何进行数据库聚类.让我们采用一个数据库来存储行中的数据.如果我正在为这种类型的数据库进行聚类,那么表结构将如何被精确地传递到不同的节点(如果我有多个节点).此表结构是链接到页面还是通过不同的机制.
你知道,在我回答这个问题之前,我必须承认你.对于具有您的知识水平的人来说,您已经深入到了关键点,获得了这种洞察力,这是非常好的.湿婆ki Jai!
是的,这是集群DBMS的关键设计问题,这是关键的限制问题,尤其是与集群相关的各种设计问题; 如果供应商处理好这个问题,集群运行良好; 如果没有,群集是狗早餐.
IT中的一切都受物理定律的支配.没有什么是免费的,功能的每个功能都有成本,处理或存储.除了MS营销手册外,没有任何魔力.
良好的集群数据库架构
我不知道所有的集群DBMS; 我非常了解Sybase CE和Oracle RAC.Sybase IQ的工作知识.
Sybase CE只有一年的历史.但是这个架构很棒,它可以很好地处理这个关键问题.SAN上只有一个版本的页面.所有节点都连接到SAN.任何节点都可以读取或写入页面.节点通过专用LAN连接(除了网络上其他所有用户使用的普通客户端 - 服务器LAN).节点协调锁加上一些节点间通信以进行节点平衡等
.
在一天结束时,为了获得最大的并发性,即使使用Sybase CE,您也需要对数据库进行逻辑分区,以便分离每个节点上的工作负载,访问不同的文件路径或共享数据库的单独物理区域.
Sybase IQ已经100%面向列.这是他们的DW产品.它已经完全负载平衡.它可以用于集群,但不能用于上述CE意义上的集群.我应该把它包括在里面
糟糕的集群数据库架构
狗早餐类型的群集dbms做蠢事.列举一些:
将页面存储在每个节点上[大量复制],但随后必须在集群周围移动更新的页面
使用MVCC来克服这个问题(但MVCC的开销要大得多,实际上降低了并发性,所以它正在自行解决)
群集不适合专用数据库服务器
基本上集群对于某些应用程序来说非常棒,但对于专用数据库服务器来说这是一个愚蠢的想法(一个地方有一个事实;共同管理的共享资源;锁定争用,当在一个地方管理因为数据在一个地方时最有效).我绝不会为数据库服务器推荐集群.
与SAN问题相同.当然,很多人将数据库存储放在SAN中,但是为了获得最高速度,并且与连接到SAN的其他服务器的负载问题隔离,本地磁盘上没有任何东西可以接近.
与VMWare问题相同.当然,很多人都将db服务器建立为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