1.7.8 of course. =)

Am Mittwoch, 20. August 2014 10:39:24 UTC+2 schrieb Enrico Risa:
>
> Hi Curtis 
>
> which version of orientdb-lucene do you have?
>
>
> 2014-08-19 18:41 GMT+02:00 'Curtis Mosters' via OrientDB <
> [email protected] <javascript:>>:
>
>> select * from Abstract where [appln_abstract] LUCENE "solar"
>>
>> Just wanted to add the other try and the error what comes with it:
>>
>> java.lang.NoSuchMethodError: com.orientechnologies.orient.core.sql.
>> OIndexSearchResult.getLastField()Lcom/orientechnologies/orient/core/sql/
>> filter/OSQLFilterItemField$FieldChain;
>>
>> Am Dienstag, 19. August 2014 18:31:36 UTC+2 schrieb Curtis Mosters:
>>
>>> select * from V where appln_abstract LUCENE "solar"
>>>
>>> runs 0,16 seconds, I didn't say anything. Sorry for not reading the 
>>> special syntax and thank you very much =)
>>>
>>> Just another question. If I write this one here:
>>>
>>> select * from V where blabla LUCENE "solar"
>>>
>>> so I'm getting the same results. How can that be. So the question is how 
>>> can I tell Lucene to just take *Abstract.appln_abstract* for it's 
>>> search? Taking *Abstract *instead of *V* gives me an error.
>>>
>>> Am Dienstag, 19. August 2014 15:41:21 UTC+2 schrieb Enrico Risa:
>>>>
>>>> Hi Curtis 
>>>> the Second one Lucene it is not the correct way to query the lucene 
>>>> index
>>>>
>>>> see here for the docs
>>>>
>>>> http://www.orientechnologies.com/docs/1.7.8/orientdb-
>>>> lucene.wiki/Full-Text-Index.html
>>>>
>>>>
>>>>
>>>> 2014-08-19 15:03 GMT+02:00 'Curtis Mosters' via OrientDB <
>>>> [email protected]>:
>>>>
>>>>> Ok let me combine all OrientDB results here:
>>>>>
>>>>> 34 sec (SB-Tree FULLTEXT)
>>>>>
>>>>> select * from Abstract where appln_abstract LIKE "%of a pipe of the 
>>>>> pipe%"
>>>>>
>>>>> 25 sec (Lucene FULLTEXT)
>>>>>
>>>>> select * from Abstract where appln_abstract LIKE "%of a pipe of the 
>>>>> pipe%"
>>>>>
>>>>> 3 sec (no index was set)
>>>>>
>>>>> select * from Abstract where appln_abstract CONTAINSTEXT "of a pipe 
>>>>> of the pipe"
>>>>>
>>>>> This is what I have tested.
>>>>>
>>>>> Am Dienstag, 19. August 2014 12:51:24 UTC+2 schrieb Enrico Risa:
>>>>>>
>>>>>> Hi  Curtis
>>>>>>
>>>>>> 3 sec without FullText index ?
>>>>>> select * from Abstract where appln_abstract CONTAINSTEXT "of a pipe 
>>>>>> of the pipe"
>>>>>>
>>>>>> can you post the explain of the previous query?
>>>>>>
>>>>>>
>>>>>> How do you run the  LUCENE query?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2014-08-19 10:50 GMT+02:00 'Curtis Mosters' via OrientDB <
>>>>>> [email protected]>:
>>>>>>
>>>>>> Wow, I tested 
>>>>>>>
>>>>>>> select * from Abstract where appln_abstract CONTAINSTEXT "of a pipe 
>>>>>>> of the pipe"
>>>>>>>
>>>>>>> on 280k entries without index. It was running 3 sec till I got a 
>>>>>>> result.
>>>>>>>
>>>>>>> Then I tested again on the Lucene indexed 280k database and it took 
>>>>>>> 20 sec.
>>>>>>>
>>>>>>> So how can that be. I read that OrientDB is already indexing. But 
>>>>>>> from Neo4j I know that Lucene is much faster. But why in my case it's 
>>>>>>> 7x 
>>>>>>> slower? Which indexer is used when you don't explicitly set an indexer? 
>>>>>>>
>>>>>>> Am Montag, 18. August 2014 21:33:30 UTC+2 schrieb Enrico Risa:
>>>>>>>>
>>>>>>>> Hi Curtis
>>>>>>>>
>>>>>>>> the LIKE operator doesn't use the FULLTEXT index.
>>>>>>>>
>>>>>>>> Could you retry the query with the CONTAINSTEXT 
>>>>>>>> operator. It should be faster because rely on the FULLTEXT index
>>>>>>>>
>>>>>>>> http://www.orientechnologies.com/docs/1.7.8/orientdb.wiki/SQ
>>>>>>>> L-Where.html
>>>>>>>>  see here
>>>>>>>>
>>>>>>>> Enrico
>>>>>>>>
>>>>>>>>
>>>>>>>> 2014-08-18 20:47 GMT+02:00 'Curtis Mosters' via OrientDB <
>>>>>>>> [email protected]>:
>>>>>>>>
>>>>>>>> I now tried it with Lucene and the index creating is much *faster*. 
>>>>>>>>> =)
>>>>>>>>>
>>>>>>>>> Also tested again both ways:
>>>>>>>>>
>>>>>>>>>    1. Importing without index: 120 sec + Indexing 80 sec
>>>>>>>>>    2. Importing with index: 340 sec
>>>>>>>>>    + extracted 274.139 records (686 records/sec) - 274.139 
>>>>>>>>>    records -> loaded 274.13
>>>>>>>>>    8 vertices (686 vertices/sec) Total time: 339809ms [0 warnings, 
>>>>>>>>>    0 errors]
>>>>>>>>>    
>>>>>>>>>    
>>>>>>>>> So is Lucene actually faster when building up the index 
>>>>>>>>> afterwards? Or is my computer really that crappy so that my 100% cpu 
>>>>>>>>> usage 
>>>>>>>>> really harming the benchmark?
>>>>>>>>>
>>>>>>>>> They query from above was done in ~25 sec, so it's also a bit 
>>>>>>>>> faster. Can that be true?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am Montag, 18. August 2014 17:23:40 UTC+2 schrieb Enrico Risa:
>>>>>>>>>
>>>>>>>>>> Hi Curtis
>>>>>>>>>>
>>>>>>>>>> can you post the result of
>>>>>>>>>>
>>>>>>>>>> explain select * from Abstract where appln_abstract LIKE "%of a 
>>>>>>>>>> pipe of the pipe%"
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Enrico
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2014-08-18 17:19 GMT+02:00 'Curtis Mosters' via OrientDB <
>>>>>>>>>> [email protected]>:
>>>>>>>>>>
>>>>>>>>>>> I'm still testing around with OrientDB. Today I realized that 
>>>>>>>>>>> OrientDB is 3 times slower on the same data, with the same indexer 
>>>>>>>>>>> compared 
>>>>>>>>>>> to MySQL. How can that be?
>>>>>>>>>>>
>>>>>>>>>>> So there are ~250k entries. FULLTEXT indexer are used on both 
>>>>>>>>>>> db's. (from https://github.com/orientechnologies/orientdb/
>>>>>>>>>>> wiki/Indexes)
>>>>>>>>>>>
>>>>>>>>>>> And the test query is:
>>>>>>>>>>> select * from Abstract where appln_abstract LIKE "%of a pipe of 
>>>>>>>>>>> the pipe%"
>>>>>>>>>>>
>>>>>>>>>>> in OrientDB: 34 sec
>>>>>>>>>>> in MySQL: 14 sec
>>>>>>>>>>>
>>>>>>>>>>> I tested this on them both 3 times and this is the average.
>>>>>>>>>>>
>>>>>>>>>>> Any ideas?
>>>>>>>>>>>
>>>>>>>>>>>  -- 
>>>>>>>>>>>
>>>>>>>>>>> --- 
>>>>>>>>>>> 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 [email protected].
>>>>>>>>>>>
>>>>>>>>>>> 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 [email protected].
>>>>>>>>> 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 [email protected].
>>>>>>> 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 [email protected].
>>>>> 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 [email protected] <javascript:>.
>> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to