Titan Db, игнорирующий индекс

Question

У меня есть график с несколькими индексами. Это два составных индекса с ограничениями на метки. (оба они точно одинаковы только для разных свойств/меток). Кажется, что определенная работа работает, а другая - нет. Я сделал следующий профиль() для проверки удвоилась:

Один называется 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 

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

INFO: Titan DB 1.1 (TP 3.1.1)

Приветствия

UPDATE: Я обнаружил, что индекс в вопрос не в состоянии 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();, но это, кажется, не делать ничего

UPDATE 2: Я попытался regitering индекс для того, чтобы индексировать следующим:

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, и я все еще получаю таймаут. Я проверил, что открытых транзакций не было. У кого-нибудь есть идея? FYI граф работает на одном сервере и имеет вершины ~ 100K и края ~ 130 Кбайт.

Answer 1

Итак, есть несколько вещей, которые могут быть случающиеся здесь:

1. Если оба этих показателей, которые вы описываете не были созданы в одной транзакции (и индекс проблемного был создан после того, как namepropertyKey был уже определен), то вы должны выдать REINDEX, согласно Titan docs:

   имя индекса графа должно быть уникальным. Графические индексы, построенные по сравнению с новыми ключами свойств, то есть ключами свойств, которые определены в той же транзакцией управления, что и индекс, немедленно доступны .Графические индексы, построенные по ключам свойств, которые уже используются , требуют выполнения процедуры reindex, чтобы индекс содержал все ранее добавленные элементы. Пока процедура reindex не будет завершена, индекс будет недоступен. Это рекомендуется определять индексы графа в той же транзакции, что и исходная схема .

2. Индекс может быть таймаут процесс, который требуется, чтобы перейти от REGISTERED к INSTALLED, в этом случае вы хотите использовать mgmt.awaitGraphIndexStatus(). Вы даже можете указать количество времени, которое вы готовы подождать здесь.

3. Убедитесь, что на вашем графике нет открытых транзакций, или статус индекса действительно не изменится, как описано here.

4. Это явно не относится к вам, но есть ошибка в Titan (фиксированная в JanusGraph через this PR), так что если вы создадите индекс для вновь созданного свойстваKey, а также ранее использованный propertyKey, индекс застрянут в REGISTERED государственных

5. индексов не будет переходить на REGISTERED, если каждый узел Titan/JanusGraph в кластере не признает создание индекса. Если ваши индексы застревают в состоянии INSTALLED, существует вероятность того, что другие узлы в системе не подтвердят существование индексов. Это может быть связано с проблемами с другим сервером в кластере, обратной засыпкой в ​​очереди сообщений Titan/JanusGraph используется для общения друг с другом или, что самое неожиданное: наличие фантомных экземпляров. Они могут возникать каждый раз, когда ваш сервер убит с помощью неработающих процессов остановки JVM, т. Е. kill -9 сервера из-за того, что он застрял в мировой коллекции мусора. Если вы ожидаете, что проблема с обратной засыпкой будет проблемой, комментарии в this class дают хорошее представление о настраиваемых параметрах конфигурации, которые могут помочь устранить проблему. Чтобы проверить наличие фантомных узлов, используйте this function, а затем this function, чтобы убить фантомные экземпляры.