我正在寻找一种适合可以在产品/商店建议 + 产品订单项目中生成的数据数据库的最佳方法。
我提取了在这样一个项目中操作的主要实体。
- costumer - 根据客户数据(以前的订单)和他的 friend 生成的数据(通过 facebook 等收集)执行产品建议，以图形格式显示是个好主意，这让我使用了 neo4j 数据库。
- order - 这是简单的东西，但是写的命令太多了。订单生命周期是创建 -> 修改状态(准备好与否) -> 商店读取 -> 删除。这意味着订单数据库的主要特点是写入操作量巨大(读写比为3)。可能 DynamoDB 是完成此任务的不错选择。
- 商品 - 它们是非结构化的(不同的产品 - 不同的领域)并且属于某些类别(层次结构)。这对 mongodb 很有用。
- 商店 - 关于商店的唯一一件事就是它的地理位置(如果商店是一家餐馆，那么顾客就会愿意光顾它)。这也可以由 mongodb 处理。
经过这样的分析，我发现我需要 3 个不同模型的不同数据库:Neo4j、DynamoDB、mongoDB，这有点奇怪。这个解决方案在您看来是否不错，或者您对此类任务有好的建议(关系数据库也是可能的选择)。
最佳答案
您几乎已经正确识别了您的数据库，但在我看来，您绝对应该让某种关系型 SQL 数据库处理与“订单”相关的数据。由于订单信息可能是一条关键任务信息，并且需要本质上应该是原子的 CRUD 操作，因此 SQL 数据库在这些情况下被证明是极其可靠的。它们不仅保证原子性，而且所有 ACID特性。可以使用 transactions 将信息写入数据库!
现在，其他 NoSQL 数据库确实也支持事务，但通常您会希望“订单”数据库具有相当高的可靠性，SQL 可以保证这一点。不要让任何人告诉您像 PostgreSQL 这样的数据库无法扩展和处理大量数据。事实上，无论出于何种意图和目的，无论您选择哪种 SQL 数据库，都极有可能处理您向其输入的任何数据量(数百万行)。如果您确实达到了数据库给您带来性能瓶颈的地步，那么有很多方法可以扩展它们。
现在，就您的非结构化“商品”信息而言，NoSQL 文档存储应该完全没问题。 MongoDB 将是完美的!
产品建议和建议通常适用于图数据库。您绝对应该继续使用 Neo4j，我相信您会感到惊讶，或者已经感到惊讶，因为启动和运行它是多么容易!更不用说叠加社交图谱不需要额外的努力。
对于具有地理位置的“商店”，您需要提供更多信息，说明您要在此处完成的任务以及您所面临的任何主要限制。据我所知，如果您对 Neo4j 感到满意(我想您会的)，请查看 Neo4j spatial .在这里使用 Neo4j 的好处是您可以轻松地将您的建议与地理位置相关联，而无需进行多个数据库连接所需的额外计算开销。其他关系和文档存储选项也可以作为存储地理位置的答案，但您必须做更多的研究，同时牢记您的限制。
所有这一切中最重要的因素是，当您最终选择不同的数据库来表示各种信息时，您将需要确定一种确保数据完整性的好方法。例如，mongo 集合中的用户 ID 需要以某种方式与 Neo4j 用户节点中的属性标志相关联。我很确定您将在这方面面临挑战，这些挑战将根据您的情况进行微调。但我敢肯定，当你到达那座桥时，你会穿过那座桥!
您尽早花时间尝试使您的“架构”正确，这很好!最终会有返回!
关于database - 电子商务的 NoSql 数据模型，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22264943/