在我的数据模型中，我使用带有主题标签的用户声明，每个主题标签变为node，它们的共现是它们之间的relationship。对于我需要考虑的每种关系：
rel.user property rel.timestamp property rel.context property rel.statement财产现在，Neo4J不允许关系属性索引，因此当我进行需要检索和评估这些属性的搜索时，需要很长时间。具体来说，当我做这种Cypher请求时：
MERGE hashtag1-[rel:TO
{context:"deb659c0-a18d-11e3-ace9-1fa4c6cf2894",
statement:"824acc80-aaa6-11e3-88e3-453baabaa7ed",
user:"b9745f70-a13f-11e3-98c5-476729c16049"}]->hashtag2
ON CREATE
SET
rel.uid="824f6061-aaa6-11e3-88e3-453baabaa7ed",
rel.timestamp="13947117878770000";
此请求首先检查是否与这些属性存在关系，如果有，则不会执行任何操作，但如果没有，则会添加一个新的（具有唯一ID和时间戳）。那么，因为必须对每个关系进行评估 - 并且它们没有被编入索引 - 这个请求需要很长时间才能完成。现在我遇到了这样的请求有问题，因为我在一个查询处理大约100个节点和300个关系（上面的一个只有一种类型，还有一些其他的添加到查询中，但上面的那些是最多的贵的）。
因此实际问题：
是否有人知道保留这些关系属性的好方法，并以某种方式使它们更快地工作，以便在需要时更快地检索和评估它们？或者您认为我应该使用不同类型的请求（如果是，哪个？）
谢谢！
答案 0 :(得分：0)
这几乎让我感觉好像你的关系实际上应该是一个节点，然后它将连接到节点：
然后你可以有合理的合并选项（.e.g在UID上合并）。
目前，您失去了图表模型对于您的人际关系的影响力。
这也在电子邮件域章节的graph-databases book中进行了讨论。
答案 1 :(得分：0)
您是否已经使用hashtag1和hashtag2节点？
如果是这样，这些之间已经存在多少个rels ？
Cypher要做的工作就是重复每个关系并比较所有3个属性（我不确定它们是否适合shortstring storage）所以如果它们不在缓存中，则必须加载它们。您可以检查商店文件，如果您有一个大的字符串存储文件，那么这些uid可能不适合属性记录，必须单独加载。
服务器的内存配置是什么（堆和mmio）？
所有这些加起来。