Titan - seltsames Verhalten von has() mit gemischtem Index

Question

Ich habe ein Titan-Diagramm mit ES-Backend und DynamoDB für Persistenz.

Methode has("mykey", "value") ruft nie einen Vertex ab. es gibt immer nichts zurück, wenn nach einer mykey Abfrage gesucht wird, die von Elasticsearch indiziert wird. Der Index wird aktualisiert und aktiviert.

wenn diese Abfrage ausgeführt wird,

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 !! 

ich einen Trick versuchte es

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 !! 

Dies scheint irgendwo ein Problem zu sein, aber nicht sicher, wo genau funktioniert. Irgendwelche Gedanken dazu?

Answer 1

Ich habe ein ähnliches Problem mit einem Lucene-Index - einschließlich der gleichen Index Verwendung Symptome.

Beachten Sie, dass in der Abfrage, die nichts abruft, es sich auch nicht über das Fehlen eines Index beschwert. Aber in der Abfrage, die das tut, beschwert es sich, über alle Scheitelpunkte iterieren zu müssen.

Ich vermute, es ist der Index, der versagt - dass die einfache hat ("...") Operation erfordert zuerst eine Nicht-Index-Suche, so ist erfolgreich, aber jedes Mal, wenn eine Indexsuche verwendet wird, schlägt fehl.

Answer 2

Ich benutze ES und HBase, und ich habe die gleiche Frage.

, wenn ich einen gemischten Index mit IHM für einen String-Typen bauen, wenn sie mit soming Sache wie

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

warnt mir die Abfrage, dass ich mit Indizes nicht, und querys eher langsam.

Aber wenn ich baue einen gemischten Index für einen Integer-Typen mit IHM und Abfragen wie

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

warnt es nichts und querys ziemlich schnell.

So jetzt verwende ich compositeIndex für String-Typen, um dies zu vermeiden