可调整的版本化图形数据库

Question

我目前正在开展一个项目，我使用自然语言处理从文本中提取情感，将其与上下文信息相关联。

上下文信息的定义：与描述实体及时空间情况相关的每一条信息。

我正在寻找的数据结构说明：

有一个任意数量的实体（一个实体可以是一个人或一组例如（推特哈希标签））我想跟踪其中的上下文信息及其与其他实体的对话。处理实体之间的对话以便对其情感特征进行分类。基本情感特征包含一个向量，用于指定百分比的出现次数：{fear: 0.1, happiness: 0.4, joy: 0.1, surprise: 0.9, anger: 0} 实体还可以提交他们想要分享的任何上下文信息，例如：位置，室温，血压......等等（将其称为上下文变量） 。 由于实体的会话数量和他们想要共享的上下文变量的数量在任何时间点都不清楚，因此数据结构需要能够相应地进行调整。

重要：数据中的每次更改都必须代表一个自己的状态，因为我期待将状态中的某些更改相互关联。

示例：Bob和Alice的对话显示出极大的恐惧感。几个小时之后，他们又进行了另一次谈话，不再表现出恐惧，而是幸福。 现在，人们可以争辩说，高度恐惧，其次是幸福，实际上可以解释为情绪缓解。

然而，为了能够提取这些信息，我需要能够将不同的状态相互关联起来。 使用上下文信息将它们与对话中跟踪的情绪相关联也是如此。 这就是为什么必须记录和提供每个州的变化。

为了让您更清楚，我已经创建了graphic并将其附加到问题中。

现在，我的实际问题是：我可以使用哪种数据库/数据结构来解决这个问题？ 我已经查看了事件采购数据库，但我不相信我是否可以轻松地使用它们重新创建图形结构。我也查看了图形数据库，但没有找到我要找的东西。

因此，如果有人能够至少指出我正确的方向或帮助我相应地调整我的结构以解决问题，那将是很好的。但是，如果有数据结构支持，我称之为带有快照的图形数据库，那么易用性可能是过滤最重要的功能。

Answer 1

Rich Hickey（Clojure成名）的数据库名为Datomic，可以随时间存储事实。数据库中的每个条目都是一个带有时间戳的事实，仅在事件源中附加。

这些事实可以用关系/逻辑语言ala Datalog（让人联想到Prolog）来查询。有关快速概述，请参阅This post by kisai。它已被用于查询图表，过去取得了一些成功：Using Datomic as a Graph Database。

虽然我没有使用Datomic的经验，但它似乎非常适合您的特定问题。

Answer 2

你有一个有趣的项目，我不直接在这样的事情上工作但是我的2美分 -

在我看来，你的照片有点瑕疵。你试图代表一个图表数据库超时，但这并不是一种以这种方式表示时间的方法。 如果我们检查图像，你的对话和上下文数据会随着时间的推移而变化，但事实上，＆＃34; Bob＆＃34;和＃34; Alice＆＃34;和＆＃34; Malory＆＃34;实际上并没有随着时间的推移而改变。所以让我们从等式中删除它们。

而是专注于您可以随时间建模的事物，对话，背景，位置。随着新数据的出现，这些事情将会发生变化。这些对象是事件源模型的绝佳选择。在您的应用中，对话将被建模为一系列单独的事件，您的聚合将使用这些事件并将其组合并生成最终状态，这将是您的“减轻”状态。测定

例如，你可以写逻辑，如果谈话生气，那么一个非常快乐的事件就会出现，那么这个主题现在感到宽慰。

我要做的是在与你的“事实”相关的图表数据库中建模这些对话状态。对象＆＃34; Bob＆＃34;，＆＃34; Alice＆＃34;等等。还有一个问题，例如＆＃39;现在感觉什么是爱丽丝？＆＃39;将是一个遍历您的会话状态的图表遍历与alice连接的上下文数据中的因子。

回答一个问题，例如“5分钟前爱情的感觉是什么？”＆＃39;您可以将所有事件流用于对话并将它们回滚到适当的点，然后检查对话的状态。

TLDR： 将时间相关变量与时间无关变量分开，并使用事件源来模拟时间。

Answer 3

在给定时间的状态与具有给定模式的关系数据库之间存在明显的1：1对应关系。因此，随着时间的推移，您的状态集与变更模式数据库之间存在明显的1：1对应关系，即一个变量，其值为数据库加元数据，由DDL和DML更新命令操纵。因此，没有证据表明您不应该只使用关系型DBMS。

关系型DBMS允许通过自动实现进行通用查询，具有一定的计算复杂性，并具有一定的优化机会。任何应用程序都可以使用专门的查询，使专用数据结构和运算符成为更好的选择。但您必须设计您的应用程序并知道关于此类特殊方面以证明这一点。事实上，由于你们的州和关系国之间存在明显的对应关系，这是没有道理的。

经常使用EAV代替DDL和更改架构。但是在EAV下，DBMS不知道您关注的真实表，它们具有EAV属性的列，并且在DDL / DML更改模式方法中是明确的。因此EAV放弃了简单性，清晰度，优化以及最重要的完整性和ACID。只能通过证明具有架构更新（添加，删除和更改列和表）的DDL比特定应用程序中的EAV更差（只有上述），才能证明它是合理的（与DDL / DML相比，假设关系表示是合适的）

仅仅因为您可以使用图表在某个时间绘制应用程序状态的图片并不意味着您需要graph database。重要的是您将评估的专门查询/表达。您应该了解这些在您的问题域中的含义，这可能是最容易根据某些专业数据结构和运算符以及相关性表达的。然后，您可以将表达和计算需求与专业数据结构，关系表示和models of particular graph databases进行比较。务必谷歌stackoverflow。

根据维基百科＆＃34; Neo4j是目前使用最流行的图形数据库＆＃34;。