【问题标题】:Scenario for Document vs Columnar DBs文档与列式数据库的场景
【发布时间】:2013-02-24 00:39:54
【问题描述】:

NoSQL 数据库可以分为 KV、Document、Columnar 和 Graph。我一直在尝试找出针对不同场景使用哪种 NoSQL,阅读了几篇博客/文章,但仍然感到困惑。

假设我想存储员工详细信息。它可以存储在像 HBase 这样的列式数据库和像 Mongo 这样的文档数据库中。那么,Columnar vs Document 的场景是什么?我想根据查询模式,必须选择合适的数据库。

【问题讨论】:

  • 同意查询模式将决定使用哪个。我认为还要考虑围绕该技术的工具。我认为 Mongo 的一个重要论点是,即使它将数据存储为 BSON,文本表示也是 JSON。如今,JSON 已成为通用语。我会考虑的。
  • 如果两者似乎都符合要求,则数据库选择取决于 CAP 定理

标签: database-design nosql document-database


【解决方案1】:

就像 Ryan 提到的,对数据的访问模式与它有很大关系。由于 Ryan 涵盖了 MongoDB 方面(我对此知之甚少),因此我将试一试 Hbase 方面。

对于初学者,我建议您阅读BigTable paper,因为 Hbase 深受其设计的影响。该视频在Hbase's design elements 上也有一些很好的细节。另外,如果您对 Zookeeper 更感兴趣,请尝试阅读 Chubby Paper

Hbase 需要考虑的事项:

索引行:在 Hbase(或Cassandra using the Ordered Partitioner)中“索引”行的方式是福是祸。我相信,mongoDb 使用 B+Tree(如果我错了,请纠正我),其中 Hbase 只是按顺序存储行。这种方法适用于 map-reduce 作业和顺序读取。对于 map-reduce 作业,它意味着运行作业的区域服务器的数据本地性。它通过允许磁盘控制器在执行密钥“扫描”时读取磁盘上的顺序扇区来帮助顺序读取。诅咒是数据是按顺序存储的......所以如果你没有很好地设计你的行,你最终会有“热”节点。例如,如果您简单地将时间戳用作行键,则最终可能会导致一个节点负责所有写入,而您的其他节点则处于空闲状态。所以,designing your row-keys in Hbase is very important。这个video on OpenTSDB 详细介绍了他们如何使用 HBase。

列式数据库的另一个优点是它们可以使用列压缩而不是行压缩。通常,一列的熵远低于一行的熵。所以它使压缩更有效。例如,如果您的列存储 UserAgent、URL、关键字……它们的压缩效果会非常好。

Hbase 解决方案示例: 假设您想创建一个解决方案来跟踪您的电子商务网站上的访问者数据,并要求支持任何日期范围内的聚合。因为 Hbase 在磁盘上以顺序方式存储密钥,所以如果您的密钥设计得当,Hbase 可能会为您提供更好的性能来创建实时顺序扫描。

对于这个例子,假设我们使用以下键存储了大量关于访问者的指标 架构 ( {product-category}.{sub-category}.{metric}.{timestamp-rounded-to-the-minute} )。例如:单页访问可能会写入以下键: shoes.running.search-terms.1362818100, shoes.running.user-agents.1362818100, shoes.running.visitors-country.1362818100,... 旁注:所有这些键基本上是顺序的,很可能会写入单个区域服务器,您可能想要 这些写入被分发到多台机器上。一种解决方案 将替换 {product-category}.{sub-category} 部分 带有 HashOf( {product-category}.{sub-category} ) 的键。或者像 OpenTSDB 那样使用密钥查找。

因此,通过这种关键设计,运行这些指标的临时/实时查询变得更快。例如,要查询在 1331666259(2012 年 3 月 13 日星期二)到 1334344659(2012 年 4 月 13 日星期五)之间使用的所有搜索词,您可以对 (shoes.running.search-terms.1331666259 到 shoes.running.search-terms.1334344659)

编辑:我修正了几个错别字

【讨论】:

  • HBase 也有一个 B-Tree 的 -ROOT- 和 .META.,它们是 HBase 中的目录表 (goo.gl/Z44Oi)。
  • 没错,我会接受它是“有效”的分布式 B+树。但是 Hbase 客户端缓存区域位置以避免“遍历树”,即每次查询 ZooKeeper、-ROOT- 和 META 表。我绝对不是想进入 HBase 比 MongoDB 战争更好。我知道 Mongo 在很多方面都比 Hbase 更好,我只是想举一个例子说明一个场景,如果它很合适的话。
【解决方案2】:

我会冒险回答。我在文档和 Mongo 方面有相当多的经验,但对列式数据库没有经验。

深度与平面

我的第一个建议是文档可以具有嵌套的子文档,并且列式数据库可能是严格的平面记录。

但是在阅读了这个http://wiki.apache.org/cassandra/DataModel之后,似乎一些列式数据库也可以对记录有深度。

事实上,如果您阅读有关 Cassandra 的页面,您会发现它们通常将概念记录表示为 JSON。所以从这个意义上说,数据建模之间似乎没有区别——至少从概念的角度来看。

同构与异构

另一个巨大的潜在差异是一个集合/表中的同质数据模型与异构数据模型。

Mongo 允许您将具有不同模式的文档存储在数据库的同一集合中。

据我所知,对于 HBase,每一行都必须具有相同的表架构。来自列族部分 (http://wiki.apache.org/hadoop/Hbase/DataModel):

“这些族是表架构的一部分,并且对于每一行都保持相同;行与行的不同之处在于列键可以非常稀疏。”

如果我对 HBase 有错误,也许有人可以纠正我。

【讨论】:

  • HBase 允许灵活的模式。表和列族必须预先定义,列可以定义运行类型。此外,每件事都存储为字节数组,并留给应用程序根据需要解释字节数组。
猜你喜欢
  • 1970-01-01
  • 2011-08-02
  • 2013-02-24
  • 1970-01-01
  • 2019-08-19
  • 2014-11-09
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多