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] <javascript:>>:
>
>> 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] <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