Specify consistency level through SOLR?

(8 posts) (4 voices)

• Started 10 months ago by jkusar
• Latest reply from thobbs
• This topic is not a support question

Tags:

No tags yet.

1. 

   jkusar
   Member

   Is there a way to specify a consistency level for a query via solr? Some type of parameter that can be passed in via the URL?

   Thanks in advance,
   Jason

   Posted 10 months ago #
2. 

   jas
   Member

   I'm curious about this too...

   The DSE 2.1 docs do mention the ability to specify consistency for updates via Solr. The default is QUORUM, but you can tack on the cl request parameter to override it. They give the example:

   http://<host>:<port>/solr/<keyspace>.<column family>/update?cl=ONE

   I assume this will work via SolrJ as well, but I've not yet tried it.

   Of course, this does not address the query side of things. For much of my content, it's basically read-only for a quarter, so issuing a Solr query with a cl=ONE would be very desirable. I don't see this addressed in the docs. Anybody know how to do this?

   Thanks,

   Jeff

   Posted 10 months ago #
3. 

   jkusar
   Member

   From what I am able to tell, ONE might be the default for reads. When I make a query against the SOLR's web service, I only see hits in the log files for the server I hit. Specifying cl=ALL doesn't seem to change anything. If it's going to the other servers to hit solr it's doing it in such a way that isn't being logged.

   Posted 10 months ago #
4. 

   Piotr Kołaczkowski
   Administrator

   Currently there is no way to specify CL for reads.

   Posted 10 months ago #
5. 

   jas
   Member

   Interesting. Even if it cannot yet be specified, can you confirm if DSE uses cl=ONE?

   I certainly would welcome the ability to set the parameter on reads. Would it make sense to use the name, say, dse.cl=ONE? What if one day Solr defines a cl request parameter?

   Posted 10 months ago #
6. 

   Piotr Kołaczkowski
   Administrator

   It uses cl=ONE. Suppporting other consistency levels is not straightforward. It would require to postprocess solr query results in order to merge duplicate documents (rows). Currently we avoid this by adding predicates filtering on appropriate token ranges, so even at higher RFs, each document can be returned by SOLR at most once, and the final result is a union of results from all solr nodes.

   Posted 10 months ago #
7. 

   jas
   Member

   Thanks for the confirmation on the CL. RF for Solr is still kind of confusing to me. :)

   Just in case anybody else runs into this issue, I ran into a problem using a Solr 4.0 join query across two cores. I had misconfigured one of the core's (in the join fromIndex) keyspace with RF=1, while everything else was RF=2. Querying one node returned the correct answer, while the second did not. Apparently, until the Solr project implements distributed joins, a DSE node must have all of the data locally for both cores in order to do a local cross core join. Thus, RF=node count is required for such a join query to work on all nodes.

   I'm very dependent on this, so I'm glad to see that the default read CL of ONE is used for Solr queries. In addition, since I can specify the CL for an update, I can use ONE there as well. My hope here is that if one of the two nodes goes down, reads and writes won't fail since I'm forced to define RF=node count. Quorum reads and writes would fail otherwise. With a third node, and RF=3, this would not be a problem, right?

   Cheers,

   Jeff

   Posted 9 months ago #
8. 

   thobbs
   Administrator

   Correct, with a third node and RF=3, updates at QUORUM can tolerate the failure of one of the replicas.

   Posted 9 months ago #

RSS feed for this topic

Reply

You must log in to post.