产品目录 - 文档存储或列系列存储

时间:2013-06-12 10:46:40

标签: nosql document-store

想知道哪种技术可以更好地用于网上商店的典型产品目录。我正在编写关于企业环境中的nosql的硕士论文,并且我现在很长时间都专注于文档存储。 阅读大量推荐文档商店的文章,因为它的灵活性是模拟数千种不同产品所必需的。但据我所知,像卡桑德拉这样的Column-Family Stores提供了同样的灵活性。

我最喜欢使用cassandra的想法是,nosql-database.org所说的内容(标记了最有趣的功能):

  

大规模可扩展,分区行存储,无主架构,线性扩展性能,无单点故障,跨多个数据中心的读/写支持&云可用区域。 API /查询方法:CQL和Thrift,复制:点对点,写入:Java,并发:可调一致性,其他:内置数据压缩,MapReduce支持,主/二级索引, 安全功能

最后,我专注于构建一个高度可用且可扩展的Multishop系统的原型,该系统利用多语言持久性,为产品目录和库存的RDBMS提供会话,文档存储或列族系列存储的K / V存储。 /像Sadalage和Fowler在他们的书“NoSQL Destilled”中提到的定价。

如果可能,请提供科学论文或其他可靠的资料来获取答案。

谢谢!

2 个答案:

答案 0 :(得分:3)

文件商店的阿喀琉斯之踵

Stuart Halloway提到文档存储是最大的模式锁定解决方案,它太不灵活了,我同意这一点。 Couch / Mongo和其他人试图通过提供变通方法来创建次要指标,能力和必要性以了解普通对象ID等来缓解这种情况。当然,如果您考虑版本控制(即向系统添加“时间”变量) ,文件商店快速失败,提供顺畅的支持和时间旅行。

列存储:问题相关性

Cassandra是一个非常引人注目的解决方案,用于构建具有Netflix等真实示例的“可扩展”/“分布式”系统,其中500个Cassandra节点可以在AWS中启动几分钟,所有请求都会遇到Cassandra环。

然而,考虑到你的问题所述的问题,Cassandra将是一个不必要的矫枉过正。不仅因为它比“其他”更复杂,或者因为在列导向商店之上创建一个可靠的数据模型在精神上更难,而且因为“产品目录”问题不是一个火箭科学。如果你想稍后添加机器学习来预测/识别/等等,它可以是,但目录本身不是,例如PostgreSQL等更简单的商店可以轻松解决它。

NoSQL的简单愿望

如果您真的想要将NoSQL用于产品目录,我肯定会考虑使用3种解决方案来适应您的原型:

  • Riak作为“会话的K / V”
  • Datomic解决“产品目录,库存和定价”
  • 根据问题的大小和性质以及最终解决方案,我会考虑Redis来缓存这些会话,同时让Datomic轻松地将Riak作为其存储服务。

实践与理论

首次在实践中使NoSQL听起来真实的两篇经典NoSQL论文是DynamoBigTable。我认为通过引入具有真实指标关系的混合数据模型而没有模式锁定和不变性来使Datomic成为数据库领域的下一个进化步骤从中得到一切:安全时间旅行,缓存,本地数据库值等等。

实际上,如果它不是主要论文,根据真实的问题规模和定义,我会选择Datomic和PostreSQL来解决目录,库存,定价等。

  • Datomic的一大优势在于时间旅行。在实践中,能够在“购物系统”中安全且容易地做到这一点非常重要。

  • PostgreSQL的一大优势是它对分析和报告的熟悉程度和SQL工具可用性。

答案 1 :(得分:1)

到目前为止,我认为Column-Family Stores不适合产品calaloges。 这是因为产品通常包含某些类型的集合,如标签,音乐记录的跟踪列表,不同尺寸的衣服等等。

Cassandra supports collections到现在为止他们无法搜索到!例如,这是标签的必备功能。 相比之下,MongoDb提供了$in运算符来搜索嵌套数组......

我不想说在Cassandra中对产品calalog进行建模是不可能的,但我认为在文档存储中更直接。