Database design 文档与柱状数据库的场景

NoSQL数据库可以分为KV、Document、Columnar和Graph。我一直在试图弄清楚在不同的场景中使用哪种NoSQL，读了几篇博客/文章，仍然感到困惑

---

假设我想存储员工的详细信息。它可以存储在像HBase这样的列式数据库和像Mongo这样的文档数据库中。那么，对于Columnar vs Document，应该采用什么样的场景呢？我想，根据查询模式，必须选择适当的数据库。

我将大胆地给出答案。我对文档和Mongo有相当丰富的经验，但对专栏数据库没有经验

深度与平坦度的对比

我的第一个建议是，文档可以有嵌套的子文档，列数据库可能是严格意义上的平面记录

但在读了这篇文章之后，似乎有些专栏数据库也有深度记录

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

同质与异质

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

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

就我所知，对于HBase，每一行都必须具有相同的表架构。从“柱族”部分（）：

“族是表架构的一部分，每行保持不变；每行的不同之处在于列键可能非常稀疏。”

---

如果我对HBase的理解有误，也许有人可以纠正我。

就像Ryan提到的，数据的访问模式与此有很大关系。由于Ryan介绍了MongoDB方面的内容（我对它知之甚少），我将尝试一下Hbase方面的内容

首先，我建议您阅读，因为Hbase深受其设计的影响。这段视频也有一些很好的细节。另外，如果你对《动物园管理员》更感兴趣，也可以尝试阅读《动物园管理员》

<强> HbASE考虑：

索引行：在Hbase（或）中，行被“索引”的方式是它的福与祸。我相信，mongoDb使用B+树（如果我错了，请纠正我），其中Hbase只是按顺序存储行。这种方法适用于map-reduce作业和顺序读取。对于map reduce作业，它意味着运行作业的区域服务器的数据位置。它通过允许磁盘控制器在对键进行“扫描”时读取磁盘上的顺序扇区来帮助顺序读取。祸根在于数据是按顺序存储的。。。因此，如果您没有很好地设计行，那么最终会出现“热”节点。例如，如果简单地使用时间戳作为行键，则可能会导致一个节点执行所有写入操作，而其他节点处于空闲状态。所以这将详细介绍他们如何使用HBase

列数据库的另一个优点是，它们可以使用列压缩而不是行压缩。通常，一列的熵比一行的熵小得多。因此，它使压缩更有效。例如，如果您的列存储用户代理、URL、关键字等，。。。它们会压缩得很好

Hbase解决方案示例： 假设您想创建一个用于跟踪电子商务站点上的访问者数据的解决方案，要求支持任何日期范围内的聚合。由于Hbase以顺序方式在磁盘上存储密钥，如果密钥设计良好，则Hbase可以为您提供更好的性能，创建实时顺序扫描

对于本例，假设我们使用以下键存储了大量关于访问者的度量 模式( {产品类别}.{子类别}.{度量}.{四舍五入到分钟的时间戳} )。例如：单页访问可能会写入以下键： shoes.running.search-terms.1362818100， shoes.running.user-agents.1362818100， 鞋。跑步。游客国家。1362818100，。。。旁注：所有这些密钥基本上都是顺序的，很可能会写入单个区域服务器，您可能需要 这些写操作将被分发到多台计算机。一个解决方案 将取代{product category}.{sub category}部分 具有哈希值（{product category}.{sub category}）的键。或者像OpenTSDB那样使用密钥查找

因此，通过这种关键设计，可以快速运行这些指标的即席/实时查询。例如，要查询133166259（2012年3月13日星期二）到1334344659（2012年4月13日星期五）之间使用的所有搜索词，您需要对（shoes.running.search-terms.1331666259 to shoes.running.search terms.1334344659）进行扫描

---

编辑：我修正了几个打字错误

同意查询模式将决定使用哪个。我认为也考虑了技术的工具。我认为Mongo的一个重要论点是，尽管它将数据存储为BSON，但文本表示是JSON。如今，JSON已成为通用语言。我会考虑。数据库选择取决于CAP定理，如果两者都适合于RealMunthBasic允许灵活的模式。表和列族必须预先定义，列可以定义为运行类型。此外，所有内容都存储为字节数组，由应用程序根据需要解释字节数组。HBase还有一个B-树，即-ROOT-和.META.，这是HBase（）中的目录表。是的，我接受它是“有效的”分布式B+树。但是Hbase客户端缓存区域位置以避免“遍历树”，即每次查询ZooKeeper、-ROOT和META表。我绝对不是想进入HBase比MongoDB战争更好的领域。我知道Mongo在很多方面都比Hbase好，我只是想给大家一个机会