用于电子商务的NoSql数据模型

时间:2014-03-08 04:14:31

标签: database nosql e-commerce

我正在寻找适合数据db的最佳方法,可以在产品/商店建议+产品订单项目中生成。

我提取了在这样一个项目中被操纵的主要实体。

  1. costumer - 对客户数据(以前的订单)和他的朋友(由facebook等收集)生成的数据执行产品建议,最好以图表格式提供,这将我带到了neo4j数据库。
  2. 订单 - 这是简单的事情,但订单写入太多了。订单生命周期是创建 - >修改状态(准备好与否) - >通过商店阅读 - >删除。这意味着订单数据库的主要特征是大量的写​​操作(写读取比为3)。可能是DynamoDB很适合这项任务。
  3. 商品 - 它们是非结构化的(不同的产品 - 不同的领域)并且属于某些类别(层次结构)。这个对mongodb有好处。
  4. 购物 - 商店唯一的一点是它的地理位置(如果商店是餐厅,而不是顾客想去的地方)。这也可以由mongodb处理。
  5. 经过这样的分析后,我发现需要3个不同型号的不同数据库:Neo4j,DynamoDB,mongoDB,哪种奇怪。这个解决方案对你来说是好的还是你对这些任务有很好的建议(关系数据库也是可能的选择)。

1 个答案:

答案 0 :(得分:5)

您几乎已经正确识别了数据库,但在我看来,您绝对应该让某种关系型SQL数据库处理“订单”相关数据。由于订单信息可能是一项关键任务的信息,并且要求CRUD操作本质上应该是原子的,因此SQL数据库在这些情况下证明是非常可靠的。它们不仅保证原子性,还保证所有ACID属性。可以使用transactions将信息写入数据库!

现在,其他NoSQL dbs也支持事务,但一般情况下,您需要在“订单”数据库中具有相当高的可靠性,SQL可以保证这一点。不要让任何人告诉你像PostgreSQL这样的数据库无法扩展和处理大量数据。事实上,无论出于什么意图和目的,您选择的SQL数据库都可能处理您投入的任何数据量(数百万行)。如果确实达到了数据库为您提供性能瓶颈的程度,那么有很多方法可以扩展它们。

现在,就您的非结构化“商品”信息而言,NoSQL文档存储应该非常好。 MongoDB将是完美的!

产品建议和建议通常适用于图形数据库。你肯定应该继续使用Neo4j,我相信你会感到惊讶,或者已经感到惊讶,它是多么容易让它运行起来!更不用说叠加社交图表不需要额外的努力。

对于具有地理位置的“商店”,您需要提供有关您要在此处完成的内容的更多信息以及您拥有的任何主要限制。据我所知,如果你对Neo4j感到满意(我认为你会这样),请看Neo4j spatial。使用Neo4j的好处在于,您可以轻松地将建议与地理位置相关联,而无需进行多个数据库连接所需的额外计算开销。其他关系和文档存储选项也可以作为存储地理位置的答案,但是您必须做更多的研究,同时牢记您的约束。

所有这一切中最重要的因素是,当您最终选择不同的数据库来表示各种信息时,您需要确定一种确保数据完整性的好方法。例如,mongo集合中的用户ID需要以某种方式与Neo4j用户节点中的属性标志相关联。我很确定你会在这方面面临挑战,这些挑战将根据你的情况进行调整。但是当你达到它时,你会越过那座桥我确定了!

你很早就花时间试图让'架构'正确!它最终得到回报!