Solr- Data search across multiple vores
Hello Folks, I want to search data in two separate cores. Both cores are unidentical only few fields are common in between. I don't want to join data . Is it possible to search data from two cores. I read about distributed search concept but not able to understand that. Is it the only way to search across multiple cores? Regards Harshal
Re: Provide suggestion on indexing performance
Hi Shawn, Thanks for your reply, this is really helpful. I will try this out to see the performance with the docValues. With regards, Aman Tandon On Sep 15, 2017 9:10 PM, "Shawn Heisey"wrote: > On 9/11/2017 9:06 PM, Aman Tandon wrote: > > We want to know about the indexing performance in the below mentioned > > scenarios, consider the total number of 10 string fields and total number > > of documents are 10 million. > > > > 1) indexed=true, stored=true > > 2) indexed=true, docValues=true > > > > Which one should we prefer in terms of indexing performance, please share > > your experience. > > There are several settings in the schema for each field, things like > indexed, stored, docValues, multiValued, and others. You should base > your choices on what you need Solr to do. Choosing these settings based > purely on desired indexing speed may result in Solr not doing what you > want it to do. > > When the indexing system sends data to Solr with several threads or > processes, Solr is *usually* capable of indexing data faster than most > systems can supply it. The more settings you disable on a field, the > faster Solr will be able to index. > > It is not possible to provide precise numbers, because performance > depends on many factors, some of which you may not even know until you > build a production system. > > https://lucidworks.com/sizing-hardware-in-the-abstract-why- > we-dont-have-a-definitive-answer/ > > All that said ... docValues MIGHT be a little bit faster than stored, > because stored data is compressed, and the compression takes CPU time. > On a fully populated production system, that statement might turn out to > be wrong. There may be factors that result in stored fields working > better. The best way to decide is to try it both ways with all your data. > > Thanks, > Shawn > >
Re: Provide suggestion on indexing performance
Hi Tom, Thanks for your suggestion and the information. I will try this out to test and will share the results. On Sep 14, 2017 2:32 PM, "Sreenivas.T"wrote: > I agree with Tom. Doc values and stored fields are present for different > reasons. Doc values is another index that gets build for faster > sorting/faceting. > > On Wed, Sep 13, 2017 at 11:30 PM Tom Evans > wrote: > > > On Tue, Sep 12, 2017 at 4:06 AM, Aman Tandon > > wrote: > > > Hi, > > > > > > We want to know about the indexing performance in the below mentioned > > > scenarios, consider the total number of 10 string fields and total > number > > > of documents are 10 million. > > > > > > 1) indexed=true, stored=true > > > 2) indexed=true, docValues=true > > > > > > Which one should we prefer in terms of indexing performance, please > share > > > your experience. > > > > > > With regards, > > > Aman Tandon > > > > Your question doesn't make much sense. You turn on stored when you > > need to retrieve the original contents of the fields after searching, > > and you use docvalues to speed up faceting, sorting and grouping. > > Using docvalues to retrieve values during search is more expensive > > than simply using stored values, so if your primary aim is retrieving > > stored values, use stored=true. > > > > Secondly, the only way to answer performance questions for your schema > > and data is to try it out. Generate 10 million docs, store them in a > > doc (eg as CSV), and then use the post tool to try different schema > > and query options. > > > > Cheers > > > > Tom > > >
Re: solr 6.6.1: Lock held by this virtual machine
I've seen this error (or similar) reported due to permissions errors. It's kind of a long shot but worth checking. See the discussion at: https://issues.apache.org/jira/browse/LUCENE-7959 Best, Erick On Sun, Sep 17, 2017 at 9:24 AM, Ode3wrote: > HI all - > > I think I am seeing something similar and I had just posted > https://issues.apache.org/jira/browse/SOLR-11361 a bit ago. > > Starters - on my test bed I decided to update from 6.2.1 to 6.6.1. All > seemed okay until I restart Solr and the Core would not load. Going to > 6.6.0 helped or at least the core would load but simlar hard errors are seen > - and I think "Lock held by this virtual machine" seem related? > > from my posting/last comment: > > > Me wrote >> I just went and grabbed Solr 6.6.0 and unpacked it. Then I copied my >> umslog core from 6.6.1 and ran the same tests. >> >> The problem that I am seeing in v6.6.1 does not appear to happen in v6.6.0 >> >> For the record, I am running from Windows Command Line just using the -p >> 8181 or 8282 argument. >> >> Is this because of this error > * >> Lock held by this virtual machine > * >> . After a bit of time Solr 6.6.0 had the same error but the Core was still >> operational. I stop 8181, move to port 8282 and there are no hard errors >> listed. I move back to 8181 and the error is back. Lastly I shut down Solr >> and just wait 30 minutes (perhaps more was not really counting) and 8181 >> comes up with no hard errors. > > > > > > -- > Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: solr 6.6.1: Lock held by this virtual machine
HI all - I think I am seeing something similar and I had just posted https://issues.apache.org/jira/browse/SOLR-11361 a bit ago. Starters - on my test bed I decided to update from 6.2.1 to 6.6.1. All seemed okay until I restart Solr and the Core would not load. Going to 6.6.0 helped or at least the core would load but simlar hard errors are seen - and I think "Lock held by this virtual machine" seem related? from my posting/last comment: Me wrote > I just went and grabbed Solr 6.6.0 and unpacked it. Then I copied my > umslog core from 6.6.1 and ran the same tests. > > The problem that I am seeing in v6.6.1 does not appear to happen in v6.6.0 > > For the record, I am running from Windows Command Line just using the -p > 8181 or 8282 argument. > > Is this because of this error * > Lock held by this virtual machine * > . After a bit of time Solr 6.6.0 had the same error but the Core was still > operational. I stop 8181, move to port 8282 and there are no hard errors > listed. I move back to 8181 and the error is back. Lastly I shut down Solr > and just wait 30 minutes (perhaps more was not really counting) and 8181 > comes up with no hard errors. -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: SolrJ Java API examples
Hi Vishal, You can also check here: https://lucene.apache.org/solr/guide/6_6/using-solrj.html#using-solrj You can get enough information about how to use it. Kind Regards, Furkan KAMACI On Thu, Sep 14, 2017 at 1:25 PM, Leonardo Perez Pulido < leoperezpul...@gmail.com> wrote: > Hi, > This may help: > > https://github.com/leoperezpulido/lucene-solr/tree/master/solr/solrj/src/ > test/org/apache/solr/client/solrj > > Regards. > > On Thu, Sep 14, 2017 at 4:21 AM, Vishal Srivastava < > vishal.smu@gmail.com > > wrote: > > > Hi, > > I'm a beginner at SolrJ , and am currently looking to implement and > > integrate the same at my current organisation using Java . > > > > After a lot of research, I failed to find any good material / examples > for > > SolrJ 's Java library that I could use as reference. > > > > Please suggest some good material. > > > > Thanks a ton. > > > > Vishal Srivastava. > > >
Re: Solr Spatial Index and Data
Hi Can, For your first question: you should share more information with us as Rick indicated. Do you have any errors, do you have unique ids or not etc? For the second one: you should read here: https://cwiki.apache.org/confluence/display/solr/Spatial+Search and ask your questions if you have any. Kind Regards, Furkan KAMACI On Thu, Sep 14, 2017 at 1:34 PM, Rick Leirwrote: > hi Can Ezgi > > First of all, i want to use spatial index for my data include polyghons > and points. But solr indexed first 18 rows, other rows not indexed. > > Do all rows have a unique id field? > > Are there errors in the logfile? > cheers -- Rick > > > . >