Titan Db игнорируя индекс
У меня есть график с парой индексов. Это два составных индекса с ограничениями надписей. (оба одинаковы только для разных свойств / меток). Один, безусловно, работает, а другой нет. Я сделал следующий профиль () для двойной проверки:
Один называется KeyOnNode: имущество uid и этикетка node:
gremlin> g.V().hasLabel("node").has("uid", "xxxxxxxx").profile().cap(...)
==>Traversal Metrics
Step Count Traversers Time (ms) % Dur
=============================================================================================================
TitanGraphStep([~label.eq(node), uid.eq(dammit_... 1 1 2.565 96.84
optimization 1.383
backend-query 1 0.231
SideEffectCapStep([~metrics]) 1 1 0.083 3.16
>TOTAL - - 2.648 -
Вышеуказанное вполне приемлемо и хорошо работает. Я предполагаю, что волшебная линия backend-query,
Другой называется NameOnSuperNode: имущество name и этикетка supernode:
gremlin> g.V().hasLabel("supernode").has("name", "xxxxxxxx").profile().cap(...)
==>Traversal Metrics
Step Count Traversers Time (ms) % Dur
=============================================================================================================
TitanGraphStep([~label.eq(supernode), name.eq(n... 1 1 5763.163 100.00
optimization 2.261
scan 0.000
SideEffectCapStep([~metrics]) 1 1 0.073 0.00
>TOTAL - - 5763.236 -
Здесь запрос занимает огромное количество времени, и у нас есть scan линия. Сначала я задавался вопросом, не был ли индекс зафиксирован через систему управления, но, увы, следующее, кажется, работает просто отлично:
gremlin> m = graphT.openManagement();
==>com.thinkaurelius.titan.graphdb.database.management.ManagementSystem@73c1c105
gremlin> index = m.getGraphIndex("NameOnSuperNode")
==>NameOnSuperNode
gremlin> index.getFieldKeys()
==>name
gremlin> import static com.thinkaurelius.titan.graphdb.types.TypeDefinitionCategory.*
==>null
gremlin> sv = m.getSchemaVertex(index)
==>NameOnSuperNode
gremlin> rel = sv.getRelated(INDEX_SCHEMA_CONSTRAINT, Direction.OUT)
==>com.thinkaurelius.titan.graphdb.types.SchemaSource$Entry@26b2b8e2
gremlin> sse = rel.iterator().next()
==>com.thinkaurelius.titan.graphdb.types.SchemaSource$Entry@2d39a135
gremlin> sse.getSchemaType()
==>supernode
Я не могу просто сбросить БД на данный момент. Любая помощь в определении проблем может быть поразительной, я бью стену здесь. Это признак того, что мне нужно переиндексировать?
ИНФОРМАЦИЯ: Titan DB 1.1 (TP 3.1.1)
ура
ОБНОВЛЕНИЕ: я нашел, что рассматриваемый индекс не в REGISTERED государство:
gremlin> :> m = graphT.openManagement(); index = m.getGraphIndex("NameOnSuperNode"); pkey = index.getFieldKeys()[0]; index.getIndexStatus(pkey)
==>INSTALLED
Как мне получить его для регистрации? я пробовал m.updateIndex(index, SchemaAction.REGISTER_INDEX).get(); m.commit(); graphT.tx().commit(); но, похоже, ничего не делает
ОБНОВЛЕНИЕ 2: я попытался отредактировать индекс, чтобы переиндексировать следующее:
gremlin> m = graphT.openManagement();
index = m.getGraphIndex("NameOnSuperNode") ;
import static com.thinkaurelius.titan.graphdb.types.TypeDefinitionCategory.*;
import com.thinkaurelius.titan.graphdb.database.management.ManagementSystem;
m.updateIndex(index, SchemaAction.REGISTER_INDEX).get();
ManagementSystem.awaitGraphIndexStatus(graphT, "NameOnSuperNode").status(SchemaStatus.REGISTERED).timeout(20, java.time.temporal.ChronoUnit.MINUTES).call();
m.commit();
graphT.tx().commit()
Но это не работает. У меня все еще есть мой индекс в INSTALLED статус, и я все еще получаю тайм-аут. Я проверил, что не было открытых транзакций. У кого-нибудь есть идея? К вашему сведению, график работает на одном сервере и имеет ~100К вершин и ~130К ребер.
2 ответа
Так что здесь может происходить несколько вещей:
Если оба описанных вами индекса не были созданы в одной и той же транзакции (и рассматриваемый проблемный индекс был создан после
namepropertyKeyбыл уже определен), то вы должны выполнить переиндексацию, согласно документам Titan:Имя индекса графа должно быть уникальным. Графические индексы, построенные на основе вновь определенных ключей свойств, т. Е. Ключей свойств, определенных в той же транзакции управления, что и индекс, сразу же становятся доступны. Графические индексы, построенные на основе ключей свойств, которые уже используются, требуют выполнения процедуры переиндексации, чтобы убедиться, что индекс содержит все ранее добавленные элементы. До завершения процедуры переиндексации индекс будет недоступен. Рекомендуется определять графовые индексы в той же транзакции, что и исходная схема.
Индекс может быть время ожидания процесса, который требуется, чтобы перейти от
REGISTEREDвINSTALLEDв каком случае вы хотите использоватьmgmt.awaitGraphIndexStatus(), Вы даже можете указать количество времени, которое вы готовы ждать здесь.Убедитесь, что на вашем графике нет открытых транзакций, иначе статус индекса действительно не изменится, как описано здесь.
Это явно не так, но в Titan есть ошибка (исправленная в JanusGraph через этот PR), такая, что если вы создадите индекс для вновь созданного propertyKey, а также для ранее использовавшегося propertyKey, индекс застрянет в
REGISTEREDгосударствоИндексы не будут перемещаться в
REGISTEREDесли каждый узел Titan/JanusGraph в кластере не подтверждает создание индекса. Если ваши индексы застряли вINSTALLEDсостояние, есть вероятность, что другие узлы в системе не подтверждают существование индексов. Это может произойти из-за проблем с другим сервером в кластере, обратной засыпки в очереди сообщений, которую Titan/JanusGraph использует для общения друг с другом, или, что наиболее неожиданно: из-за наличия фантомных экземпляров. Это может происходить каждый раз, когда ваш сервер уничтожается из-за ненормальных процессов завершения работы JVM, т.е.kill -9сервер из-за того, что он застрял в трэш сборщик мусора. Если вы ожидаете, что проблема заключается в обратной засыпке, комментарии в этом классе помогут лучше понять настраиваемые параметры конфигурации, которые могут помочь решить проблему. Чтобы проверить наличие фантомных узлов, используйте эту функцию, а затем эту функцию для уничтожения фантомных экземпляров.
Я думаю, что вы пропустили конфигурацию к вашему графику. Если вы использовали backend is cassandra, вы должны сконфигурировать с помощью asticsearch. Если вы использовали backend hbase, вы должны сконфигурировать с кэшированием. Подробнее читайте по ссылке ниже: https://docs.janusgraph.org/0.2.0/configuration.html