Являются ли индексы смешанного типа приемлемыми в Neo4j?

Question

У меня есть набор данных, который включает в себя несколько узлов, все из которых помечены claim, которые могут иметь различные свойства (имена P1, P2 и т. Д., Через P2000). В настоящее время каждый из узлов claim может иметь только одно из этих свойств, и каждое свойство имеет значение, которое может быть разных типов (то есть P1 может быть строкой, P2 может быть float, P3 целым и т. Д.). Мне также нужно иметь возможность искать узлы любым свойством (т. Е. "find all nodes with P3 which equals to 42").

Я смоделировал его как узлы, имеющие свойство value и маркировку в соответствии с свойством P. Затем я определяю индекс схемы на метке claim и свойстве value. Затем поиск будет выглядеть примерно так:

MATCH (n:P569:claim) WHERE n.value = 42 RETURN n 

Мой первый вопрос - это ОК, чтобы иметь такой индекс? Разрешены ли индексы смешанного типа?

Второй вопрос заключается в том, что поиск выше работ (хотя я не уверен, используется ли индекс или нет), но это не - обратите внимание на порядок метка включается:

neo4j-sh (?)$ MATCH (n:claim:P569) WHERE n.value>0 RETURN n; 
IncomparableValuesException: Don't know how to compare that. Left: "113" (String); Right: 0 (Long) 

P569 свойства все числовые, но существуют строковые свойства других P-значений, одним из которых является «113». Так или иначе, даже если я сказал, что метка должна быть как утверждают, и P569, то «113» значение по-прежнему включены в сравнение, даже если он не имеет P569 метки:

neo4j-sh (?)$ MATCH (n:claim) WHERE n.value ="113" RETURN LABELS(n); 
+-------------------+ 
| LABELS(n)   | 
+-------------------+ 
| ["claim","P1036"] | 
| ["claim","P902"] | 
+-------------------+ 

Что здесь не так - почему это работает с одним порядком на этикетке, но не с другим? Можно ли улучшить эту модель данных?

Answer 1

Позвольте мне хотя бы попытаться ответить на ваш вопрос, есть еще один способ, которым вы могли бы моделировать это, чтобы решить хотя бы некоторые из ваших проблем.

Вы кодируете имя свойства как ярлык. Возможно, вы хотите сделать это, чтобы ускорить поиск подмножества узлов, где это свойство применяется; по-прежнему кажется, что вы вызываете много трудностей, когда все данные, сопоставимые с потрясающими данными, попадают в одно и то же свойство с именем «значение».

Что делать, если в дополнение к использованию этих меток каждое свойство было названо так же, как значение? Т.е .:

CREATE (n:P569:claim { P569: 42}); 

Вы все еще получаете ваши этикетки Lookups, но сегрегацию имена свойств, вы можете гарантировать, что планировщик запросов никогда не случайно сравнивать несравнимые значения в том, как он строит план выполнения. Ваш запрос для этого узла будет затем:

MATCH (n:P569:claim) WHERE n.P569 > 5 AND n.P569 < 40 RETURN n; 

Обратите внимание, что если вы знаете правильный ярлык для использования, то вы гарантированно знать имя права собственности на использование. Используя свойства разных имен, если вы регистрируете свои данные таким образом, чтобы P569 всегда были целыми числами, вы не можете оказаться в той несравненной ситуации, которая у вас есть. (Я думаю, что это происходит из-за того, каким образом cypher выполняет этот запрос)

Возможная недостача здесь заключается в том, что если вам нужно индексировать все эти свойства, это может быть много индексов, но все равно может быть что-то рассматривать.

Answer 2

Я думаю, что имеет смысл сделать шаг назад и подумать, чего вы на самом деле хотите достичь, и почему у вас есть эти свойства 2000 в первую очередь и как вы могли бы моделировать их по-другому на графике?

Также не забудьте оставить объекты, которые вам не нужны, и использовать coalesce() для предоставления по умолчанию.