I also tried latest stable Lucene (1.7.4) and latest OrientDB (1.7.8) and having the same error. java.lang.NoSuchMethodError: com.orientechnologies.orient.core.sql.OIndexSearchResult.getLastField()Lcom/orientechnologies/orient/core/sql/filter/OSQLFilterItemField$FieldChain;
select * from Member where full_name LUCENE "test*" Em quarta-feira, 20 de agosto de 2014 07h12min58s UTC-3, Curtis Mosters escreveu: > > 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]>: >> >>> 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]. >>> 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.
