2015-04-09 7 views
0

Я все еще пытаюсь решить проблему с моей скоростью (показано здесь: Cypher MATCH query speed).Neo4j Индекс, созданный ограничением

Единственное, что я заметил, это то, что я импортирую данные с помощью уникального ограничения (доказано ниже).

neo4j-sh (?) $ Создать индекс на: лице (имя пользователя);

QueryExecutionKernelException: Label 'Person' и свойство 'username' имеют на них уникальное ограничение, поэтому индекс уже создан , который соответствует этому.

При попытке просмотреть индексы в раковине, я получаю следующее:

Neo4j-ш $ индекс --indexes
Node индексы (?):

индексы отношений:

Есть ли автогенерированные индексы, которые не должны отображаться? Как я могу проверить, что уникальное ограничение фактически индексирует имя пользователя?

Основная проблема (как показано в приведенной выше ссылке) заключается в том, что нижний простой запрос занимает 36 секунд (с ожидающим вызовом) и дважды в то же время, когда переключается на невозвратный вызов.

USING PERIODIC COMMIT 15000 
LOAD CSV WITH HEADERS FROM "file:d:/messages.csv" AS line 
MATCH (a:Geotagged { username: line.sender }) - [r:MSGED] -> (b:Geotagged { username: line.recipient }) 
RETURN NULL; 

Обратите внимание, это за исключением SET вызов Первоначально я пытался использовать, я удалил его и в одиночку MATCH принимает навсегда.

Кроме того, я также увеличил pagecache до нескольких раз, что мне нужно, и не видел никаких изменений.

EDIT 1 Узлы с надписью «Geotagged» обозначены как «Лицо». Все узлы являются «Person», некоторые из них также могут быть «Geotagged».

ответ

2

Использовали ли вы уникальность с меткой Geotagged, а также с меткой Person? Я обнаружил, что уникальность, сдерживающая обе метки, значительно увеличивала скорость.

+0

Мой процесс импорта/загрузки заключается в том, чтобы установить уникальное ограничение на Person: username, а затем загрузить все, все под меткой Person. В этом же запросе у меня есть серия операторов CASE WHEN + FOREACH, которые проверяют свойства узлов и добавляют к ней конкретную метку. Вы предполагаете, что мне может потребоваться сдерживать каждую отдельную метку? – Brooks

+1

Да. У меня была аналогичная проблема. У меня было только 3 варианта для моего вторичного лейбла, не знаю, сколько вы добавляете. Я обнаружил, что добавление ограничения единственности для каждой из трех вторичных меток увеличивает экспоненциальные скорости. – Mel18

1

Вы используете команду index для устаревших индексов, использования schema в список индексов схемы и ограничение.

Кроме того, если вы подходите по :Geotagged(username) вы должны иметь индекс для этой комбинации:

create index on :Geotagged(username); 

или матч на :Person(username) вместо этого.

+0

Майкл, спасибо! Я боролся с этим. Есть ли способ создать индекс на уже существующих узлах? Кажется, что команда create index просто добавляет индекс и фактически не индексирует узлы. – Brooks

+0

Я начал писать, можете ли вы предоставить мне обратную связь, если бы это помогло вам? http://gist.asciidoctor.org/?dropbox-14493611%2Fneo4j_indexes_match_and_merge.adoc –

+0

Индекс схемы всегда будет также индексировать существующие узлы с помощью этой комбинации ярлыков и свойств. –

Смежные вопросы