Титан - странное поведение has() со смешанным индексом

У меня есть график Titan с бэкэндом ES и DynamoDB для сохранения.

Метод has("mykey", "value") никогда не извлекает вершину. он всегда ничего не возвращает при запросе mykey, который индексируется Elasticsearch. Индекс обновлен и включен.

КОГДА выполняется этот запрос,

gremlin>  graph.indexQuery("verticesIndex2", "v.mykey:myvalue").vertices().asList().size()
==>1  // It works here!! The vertex is retrieved successfully.
gremlin> g.V().has("mykey", "myvalue").hasNext()
==>false // doesn't retrieve anything!!!
gremlin> g.V(16998408).values("mykey")
==>myvalue // the vertex exists in my graph for sure !!

Я попробовал трюк, чтобы заставить его работать

gremlin> g.V().has("mykey").has("mykey", "myvalue").next() 
19:49:44 WARN  com.thinkaurelius.titan.graphdb.transaction.StandardTitanTx  - Query requires iterating over all vertices [()]. For better performance, use indexes
==>v[16998408] // It works !!

Кажется, это где-то проблема, но не уверен, где именно. Есть мысли по этому поводу?


person Mohamed Taher Alrefaie    schedule 12.05.2016    source источник


Ответы (2)


У меня аналогичная проблема с индексом lucene, включая те же симптомы использования индекса.

Обратите внимание, что в запросе, который ничего не извлекает, он также не жалуется на отсутствие индекса. Но в запросе, который это делает, он жалуется на необходимость перебирать все вершины.

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

person Nathan Kronenfeld    schedule 29.08.2016

Я использую ES и HBase, и у меня тот же вопрос.

когда я создаю смешанный индекс, используя ES для типа String, при запросе с чем-то вроде

g.V().has("mykey", "myvalue").hasNext()

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

Но когда я создаю смешанный индекс, используя ES для типа Integer и выполняя запросы типа

g.V().has("myInt", "myIntValue").hasNext()

он ничего не предупреждает и запрашивает довольно быстро.

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

person ziploe    schedule 07.09.2016