Nick ...
(1) I don't work for OrientDB, (2) I am not familiar with the Tinkerpop
APIs outside of OrientDB.
OrientGraph.getVertices() returns an iterator, not a pipe. Gremlin adds a
DSL method *_()* that will turn an iterator into a pipeline, from which you
can do the normal Gremlin queries.
AFAIK, the OrientDB Java/Groovy/Gremlin APIs require you to explicitly
select an index to use. The SQL queries can either explicitly specify an
index (SELECT * from INDEX:...) or they may take advantage of an existing,
properly specified, index, maybe. This is an area where OrientDB still
needs a lot of work, IMO. Or at least a lot more documentation.
FWIW, I've been working with databases all my career, and I've never moved
from one database to a different but comparable database without having to
make changes to *some* aspect of my application. Blueprints is nice, but it
is not a cross-graph-database panacea.
- Craig -
On Tue, Jun 2, 2015 at 12:35 PM, Nick DeYoung <deyoung.n...@gmail.com>
wrote:
> Craig,
>
> I have tried that, it takes 11 ms. but that is not a Pipe -
> (g.getVertices())
>
> our code base is leveraging another TinkerPop enabled graph databse and
> are researching the idea of switching it out.
>
> my research is trying to figure out how does orient perform on the generic
> Tinkerpop API.
> I want to do things like
> g.V().has("someProperty","someValue").outE("someLabel")....somemoreStepsInMyPipe..
> and know that that is going to hit indexes.
>
> Does it ?
>
> this is a simple test of the different ways I am accessing the graph and
> their timing on 300,000 vertices (not connected at the momen)
>
> time("orient graph api 'orient specific'") {
> val v = g.getVertices("V.testProperty",
> "cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e")
>
> } 11 ms
>
> time("tinkerpop pipeline 'generic'") {
> val v = new GremlinPipeline(g, true).V("testProperty",
> "cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e").next()
>
> } 21 seconds
>
> time ("another blueprints? " ) {
> val v = g.query().has("testProperty",
> "cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e").vertices()
>
> } 19 seconds
>
> time("sql count all 'orient specific'") {
> val v:OResultSet[ODocument] = g.getRawGraph.query(
> new OSQLSynchQuery[ODocument]("select * from
> INDEX:V.testProperty where key = 'cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e'")
> ) 1 ms
>
>
> }
>
> // throws an error in distrubuted mode
> // time ("gremlin command 'generic' ") {
> // val r = g.getRawGraph.command(new
> OCommandGremlin("g.V().has('testProperty')")).execute()
> // }
>
>
> If I understand Orient's documentation right, I am going to have to either
> change our pipes (traversals in tinkerpop) into SQL+ queries in order to
> leverage the claims of orient's speed.
>
> If i'm wrong in this, let me know
>
>
>
>
> On Mon, Jun 1, 2015 at 11:33 PM, W. Craig Trader <craig.tra...@gmail.com>
> wrote:
>
>> Nick ...
>>
>> Much like you told the SQL engine to use an index (select * from
>> INDEX:V.testProperty ...), you need to explicitly use indexes from the
>> graph API, as follows:
>>
>> *Java:*
>>
>> OrientVertex result = g.getVertices( "V.testProperty", "
>> cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e" ).iterator().next();
>>
>>
>> *Gremlin:*
>> GremlinPipeline p = g.getVertices( "V.testProperty", "
>> cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e" )._()
>>
>>
>> I think you'll find that using indexes with the Java API is even faster
>> than the SQL query API.
>> - Craig -
>>
>>
>> On Mon, Jun 1, 2015 at 5:33 PM, Nick DeYoung <deyoung.n...@gmail.com>
>> wrote:
>>
>>> I have an orient db 2.0.10 community server up and running
>>> I have created a simple test where I have placed 300,000 vertices in an
>>> orient database each with a property "testProperty" with a value -
>>> UUID.randomUUID().toString
>>> I have created an index on the property
>>>
>>> graph.createKeyIndex("testProperty", classOf[Vertex]) // this is
>>> scala :)
>>>
>>> In a test I create an OrientGraph connected via remote:
>>> 127.0.0.1:2424/test-database
>>>
>>> and do
>>>
>>> g.query().has("testProperty", "cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e")
>>>
>>> This takes 20 seconds to return the vertex with that UUID.
>>>
>>> In another test I do
>>>
>>> g.getRawGraph.query(new OSQLSynchQuery[ODocument]("select * from
>>> INDEX:V.testProperty where key = 'cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e'"))
>>>
>>> which takes 1 millisecond to return the vertex.
>>>
>>> Is the java graph query api really this slow or am I doing something
>>> wrong?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "OrientDB" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to orient-database+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "OrientDB" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/orient-database/Ff5Fbxi6p20/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> orient-database+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> // ndy
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OrientDB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to orient-database+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
