产品目录 - Document Store 或 Column Family Store [关闭]答案

【问题标题】：Product Catalog - Document Store or Column Family Store [closed]产品目录 - Document Store 或 Column Family Store [关闭]
【发布时间】：2013-08-14 21:56:53
【问题描述】：

想知道哪种技术更适合网店的典型产品目录。我正在写关于企业环境中的 nosql 的硕士论文，并且我认为现在一直专注于文档存储。阅读大量推荐文档存储的文章，因为它具有为数千种不同产品建模所需的灵活性。但据我所知，像 Cassandra 这样的 Column-Family Stores 提供了同样的灵活性。

我最喜欢使用 cassandra 的想法是 nosql-database.org 对它的评价（标记为最有趣的功能）：

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

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

如果可能，请为您的答案提供科学论文或其他可靠来源。

谢谢！

【问题讨论】：

标签： nosql document-store

【解决方案1】：

Document Store 的致命弱点

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

列存储：问题相关性

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

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

NoSQL 的简单愿望

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

Riak 作为“会议的 K/V”
Datomic解决“产品目录、库存和定价”
根据问题的规模和性质以及最终解决方案，我会考虑使用Redis 缓存这些会话，同时让 Datomic 舒适地位于 Riak 之上作为其存储服务。

实践与理论

Dynamo 和BigTable 是第一次让 NoSQL 在实践中听起来真实的两篇经典 NoSQL 论文。我认为 Datomic 是 DB 领域的下一个进化步骤，它引入了具有 真实索引 和关系的混合数据模型，没有模式锁和 不变性 em> 一切都由此而来：安全时间旅行、缓存、本地 db 值等。

实际上，如果不是硕士论文，根据实际问题的规模和定义，我会在 Datomic 和 PostreSQL 之间进行选择来解决目录、库存、定价等问题。

Datomic 的一大优势是时间旅行。在实践中，能够在“购物系统”中安全轻松地做到这一点非常重要。
PostgreSQL 的一大优势在于其对分析和报告的熟悉度和 SQL 工具可用性。

【讨论】：

嗨 tolitius，即使我不同意你的第一句话，评论的其余部分对我很有帮助；）我的地图上没有 Datomic，所以我会仔细看看它。我认为 PostgreSQL 不能满足我的需求，因为它不够灵活，而且它不像我认为的任何其他 RDBMS 那样水平扩展。 Redis 作为缓存的想法我也会评估！
我知道第一个陈述可能听起来有争议并且确实取决于一个问题，但是在不同的项目中使用文档存储我刚刚得出与 Stuart 相同的结论，所以我将把它留给你个人经验。任何数据库商店都可以调整工作，但我相信如果从今天开始 Foursquare 就不会使用 Mongo。至于 Postgres 和横向规模，如果你同意我的观点，Instagram 是一个“足够大”的系统，那就是 how they do it。

【解决方案2】：

到目前为止，我认为 Column-Family Stores 不太适合产品目录。这是因为产品通常包含某种集合，例如标签、音乐唱片的曲目列表、不同尺寸的衣服等等。

Cassandra supports collections 现在但它们不可搜索！例如，这是标签的必备功能。相比之下，例如 MongoDb 提供了 $in 运算符来搜索嵌套数组...

我不想说不可能在 Cassandra 中为产品目录建模，但我认为在文档存储中进行建模更直接。

【讨论】：