具有“非图形”数据的图形数据库

Question

--- 更新 ---
感谢您的评论和到目前为止的帮助。我很抱歉没有进一步说明问题。我已经更新了下面的问题。
- - 更新 - -

目前，我被要求为大量数据开发数据库结构。我正在争论实现图形数据库而不是“普通”关系数据库，并且想知道如果数据不一定包含任何关系有什么缺点？可以像表/表中的行一样使用单独的、未连接的节点吗？

我问这个是因为现在不需要关系，但我正试图在未来证明数据库（预期关系）以扩展数据的能力。如果有任何帮助，我正在 OrientDB/Neo4j 或 mySQL/postgreSQL 之间进行辩论。

一个例子：
假设我们有一个充满股票的数据库。任何人几乎可以在任何时间/天买卖股票（只要市场开放）。现在这个数据库可以是一个普通的关系数据库：Table 1: IDs | Products | Prices | Sizes | Dates. 但也有可能被组织为关系数据库Node 1: Stock A | Node 2: Stock B。
如果我只是使用数据库来存储股票信息，在我看来普通的数据库会更好。但这是真的吗？它会不会对我使用关系数据库产生负面影响/使用普通数据库会更好吗？在节点而不是行中组织我的数据是否有缺点？

一张图说明一切：

该数据库将主要用于买卖类似股票的产品，但它们也有其他信息，例如附加到它们的位置。我正在尝试预测功能的实现，例如推荐产品，甚至预测某人要购买的下一个产品。

来自数据库的大多数查询将针对每个产品。
从数据库中提取：每天 100 到 1000 次。
推送到数据库：每天 20.000。

一个额外的问题可能会揭示一个缺点：
从关系到图或从图到关系有多容易。有任何锁定危险吗？

感谢所有的帮助，到目前为止评论都很棒！电阻

Answer 1

我认为您在这里犯了一个相当常见的错误，即选择 NoSQL 技术以便在不了解权衡的情况下“面向未来”。如果有疑问，请从 PostgreSQL 开始，并根据需要随时设置图形数据库或其他 NoSQL 数据库。您也可以在 PostgreSQL 中进行图遍历，但请记住，您正在使用集合，因此这与具有不同优点和缺点的图数据库非常非常不同。

您的基本权衡是在数据输入的灵活性和灵活利用输出数据的能力之间进行权衡。NoSQL 数据库（包括图形数据库）为前者牺牲了后者，因为通常您需要能够对数据集运行即席查询，您可能希望在某处使用 RDBMS。这意味着如果您有一个好的数据模型，您应该能够将附属数据库服务器添加到您的环境中，以便您的 RDBMS 无法处理它的特殊目的。

尽管如此，有几个特定的​​原因，如果您在某个时候考虑添加各种 NoSQL 解决方案，为什么我会建议从 PostgreSQL 而不是 MySQL 开始，这与 NoSQL 友好的数据库结构的性能以及 PostgreSQL 支持的事实有关WITH RECURSIVE 公用表表达式。这种方法（带有递归 CTE）允许使用可以重复遍历路径的递归 SQL 语句来遍历层次结构和图形等内容。对于基于集合的方法，这些也是相对有效的，因此如果您最终遇到很多零件/子零件建模问题，您可以直接在 PostgreSQL 中完成，而无需太多工作。但是，如果这不起作用，您还可以更轻松地以更容易导入 NoSQL 数据库的方式表示数据。因此，它可以让您走得更远，并且可以更好地集成。您甚至可以针对您的 NoSQL 数据库设置外部“表”，并从 Pg 内部对其运行查询！

更多关于权衡 1

图数据库源于对大量信息进行快速二进制遍历的需要。一个明显的例子可能是像 LinkedIn 这样的社交网站，它可能想快速告诉你你与另一个用户的距离（简单来说，这意味着它们本质上是为了玩“六度凯文培根”而设计的）。通常在图形数据库上，您实际上是使用通常被描述为代表图形的“三个单词句子”来遍历节点。在这方面，您正在查看本质上类似于“John 与 Jane 成为朋友”并以这种方式遍历的内容。通常，API 是相对导航的。

关系数据库实际上是为处理信息集而设计的。通常，当放弃关系数据库时，也会放弃集合操作。这可能是一件大事。通常，能够进行设置操作而不是导航、聚合和报告在操作上和开发时间方面都更快。这是一个巨大的差异，如果您的用例适合关系工作流，我很难想象图形数据库会帮助您。

更多权衡 2：一致性模型

要调查并记住的第二件事是您的数据库使用什么一致性模型的问题。即使使用“符合 ACID”的 RDBMS，也有一系列基于不同事务隔离级别的一致性模型，可用于防止出现问题。如果您的数据很重要，那么标准 RDBMS 一致性模型将比大多数 NoSQL 模型表现得更好，因为它们为 DBA 和应用程序提供了更多保证。图数据库是一个比较大的领域，每个厂商的一致性模型可能会有一些差异。这不一定会排除使用，但在从整体上查看解决方案时需要谨慎。

请注意，模式灵活性在 NoSQL 世界中既是福也是祸，这也会影响图数据库。这是一件好事，因为您可以在初始阶段更快地启动和运行，但这是一个诅咒，因为 RDBMS 的设置操作强度取决于固定模式，以及在一定程度上放宽该模式的那些（例如 Informix，支持返回集中的锯齿行）需要程序员了解放宽这些要求的地方。