lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-8146) Allowing SolrJ CloudSolrClient to have preferred replica for query/read
Date Sat, 08 Oct 2016 16:12:20 GMT

    [ https://issues.apache.org/jira/browse/SOLR-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15558228#comment-15558228
] 

ASF GitHub Bot commented on SOLR-8146:
--------------------------------------

Github user susheelks commented on the issue:

    https://github.com/apache/lucene-solr/pull/66
  
    Merged routingRule changes after latest refactored code


> Allowing SolrJ CloudSolrClient to have preferred replica for query/read
> -----------------------------------------------------------------------
>
>                 Key: SOLR-8146
>                 URL: https://issues.apache.org/jira/browse/SOLR-8146
>             Project: Solr
>          Issue Type: New Feature
>          Components: clients - java
>    Affects Versions: 5.3
>            Reporter: Arcadius Ahouansou
>         Attachments: SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch
>
>
> h2. Backgrouds
> Currently, the CloudSolrClient randomly picks a replica to query.
> This is done by shuffling the list of live URLs to query then, picking the first item
from the list.
> This ticket is to allow more flexibility and control to some extend which URLs will be
picked up for queries.
> Note that this is for queries only and would not affect update/delete/admin operations.
> h2. Implementation
> The current patch uses regex pattern and moves to the top of the list of URLs only those
matching the given regex specified by the system property {code}solr.preferredQueryNodePattern{code}
> Initially, I thought it may be good to have Solr nodes tagged with a string pattern (snitch?)
and use that pattern for matching the URLs.
> Any comment, recommendation or feedback would be appreciated.
> h2. Use Cases
> There are many cases where the ability to choose the node where queries go can be very
handy:
> h3. Special node for manual user queries and analytics
> One may have a SolrCLoud cluster where every node host the same set of collections with:
 
> - multiple large SolrCLoud nodes (L) used for production apps and 
> - have 1 small node (S) in the same cluster with less ram/cpu used only for manual user
queries, data export and other production issue investigation.
> This ticket would allow to configure the applications using SolrJ to query only the (L)
nodes
> This use case is similar to the one described in SOLR-5501 raised by [~manuel lenormand]
> h3. Minimizing network traffic
>  
> For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 (or N) separate
racks: rack1 and rack2.
> On each rack, we have a set of SolrCloud VMs as well as a couple of client VMs querying
solr using SolrJ.
> All solr nodes are identical and have the same number of collections.
> What we would like to achieve is:
> - clients on rack1 will by preference query only SolrCloud nodes on rack1, and 
> - clients on rack2 will by preference query only SolrCloud nodes on rack2.
> - Cross-rack read will happen if and only if one of the racks has no available Solr node
to serve a request.
> In other words, we want read operations to be local to a rack whenever possible.
> Note that write/update/delete/admin operations should not be affected.
> Note that in our use case, we have a cross DC deployment. So, replace rack1/rack2 by
DC1/DC2
> Any comment would be very appreciated.
> Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message