You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by David Smiley <ds...@apache.org> on 2025/10/15 22:21:34 UTC
The state of PRS -- "experimental"
SolrCloud's "PRS" (Per Replica State) mode offers a variation on how
replica state is tracked, affecting how state is stored in ZooKeeper and
certainly affecting SolrCloud code. It solves a many-replica scalability
problem of large collections. Coincidentally, that is exactly the achilles
heel of disabling the Overseer, however PRS didn't go far enough in its
approach (IMO) as there is still replica information in state.json. I love
the conceptual idea / direction of PRS but not the implementation, which is
complex -- complexified further by being bolted onto the existing code
instead of green-field. If we are to imagine making any serious
improvements like this to how a collection's state is structured in
ZooKeeper, I can't imagine realistically doing such work with PRS
existing. I think such work would start with removing PRS without
concern/burden of compatibility.
Thankfully, PRS is rather invisible to our users -- it's not documented in
the ref guide. I think only Full Story is using it. So it's de
facto "experimental" right now and is subject to change... **and removal**.
FWIW I'd love to help design its replacement, but that's not the subject of
this post/thread.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
Re: The state of PRS -- "experimental"
Posted by Jan Høydahl <ja...@cominvent.com>.
Would a SIP with title "Scalable cluster state management" be appropriate for this topic? Where one could lay out the problems faced by current Overseer, state.json and enumerate a roadmap for improvement.
It would obviously discuss the existing implementations of removing Overseer and the PRS code, their weaknesses and proposals for solutions (whether it is incremental or greenfield).
I'm not involved in deployments at this kind of scale myself, so I don't have much to bring to the table.
Jan
> 16. okt. 2025 kl. 00:21 skrev David Smiley <ds...@apache.org>:
>
> SolrCloud's "PRS" (Per Replica State) mode offers a variation on how
> replica state is tracked, affecting how state is stored in ZooKeeper and
> certainly affecting SolrCloud code. It solves a many-replica scalability
> problem of large collections. Coincidentally, that is exactly the achilles
> heel of disabling the Overseer, however PRS didn't go far enough in its
> approach (IMO) as there is still replica information in state.json. I love
> the conceptual idea / direction of PRS but not the implementation, which is
> complex -- complexified further by being bolted onto the existing code
> instead of green-field. If we are to imagine making any serious
> improvements like this to how a collection's state is structured in
> ZooKeeper, I can't imagine realistically doing such work with PRS
> existing. I think such work would start with removing PRS without
> concern/burden of compatibility.
>
> Thankfully, PRS is rather invisible to our users -- it's not documented in
> the ref guide. I think only Full Story is using it. So it's de
> facto "experimental" right now and is subject to change... **and removal**.
>
> FWIW I'd love to help design its replacement, but that's not the subject of
> this post/thread.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: The state of PRS -- "experimental"
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
Is there a JIRA about PRS removal? I'm -1 on this until we prove why it
must be removed.
PRS introduced because of improved performance and improved stability of
cluster operations over the non-PRS mode. Until we prove that there's
something better available now, I see no reason why this should be removed.
> Calvin, I recommend that you switch away from PRS and instead in Solr 10
disable the Overseer.
In absence of benchmarks, I see no reason to follow your recommendation. My
recommendation would be to try out all options available in Solr and use
whatever works best for you.
> So it's de-facto "experimental" right now and is subject to change...
**and removal**.
I find no evidence that this is an "experimental" feature. Neither in code,
nor in documentation. Can you please point me in the right direction?
On Fri, 17 Oct 2025 at 06:57, David Smiley <ds...@apache.org> wrote:
> Calvin, I recommend that you switch away from PRS and instead in Solr 10
> disable the Overseer. In doing so, you will continue to have the benefit
> of decentralized state updates (a shared characteristic of both
> schemes), which is likely desirable for so many replicas you have in
> aggregate. You didn't say if you have any large collections (>200
> replicas); if you do then probably don't disable the Overseer yet.
>
> Thanks for pointing out that line in the ref guide. I propose to the
> developer community that I remove that from the ref guide in Solr 10 to
> discourage users from enabling a system that is likely to change without
> regards to backwards compatibility.
>
> ~ David
>
> On Wed, Oct 15, 2025 at 7:01 PM Calvin Smith <ca...@lucasfilm.com>
> wrote:
>
> > PRS is documented in the ref guide:
> >
> >
> https://solr.apache.org/guide/solr/latest/deployment-guide/collection-management.html#create-parameters
> >
> > I know this because I started using it recently (for a new solrcloud
> > cluster that I'm working on that will have hundreds of collections),
> having
> > discovered it through https://searchscale.com/blog/prs/.
> >
> > I didn't realize that it was experimental and might be removed.
> >
> > Best,
> > Calvin
> >
> > On Wed, Oct 15, 2025 at 3:23 PM David Smiley <ds...@apache.org> wrote:
> >
> > > SolrCloud's "PRS" (Per Replica State) mode offers a variation on how
> > > replica state is tracked, affecting how state is stored in ZooKeeper
> and
> > > certainly affecting SolrCloud code. It solves a many-replica
> scalability
> > > problem of large collections. Coincidentally, that is exactly the
> > achilles
> > > heel of disabling the Overseer, however PRS didn't go far enough in its
> > > approach (IMO) as there is still replica information in state.json. I
> > love
> > > the conceptual idea / direction of PRS but not the implementation,
> which
> > is
> > > complex -- complexified further by being bolted onto the existing code
> > > instead of green-field. If we are to imagine making any serious
> > > improvements like this to how a collection's state is structured in
> > > ZooKeeper, I can't imagine realistically doing such work with PRS
> > > existing. I think such work would start with removing PRS without
> > > concern/burden of compatibility.
> > >
> > > Thankfully, PRS is rather invisible to our users -- it's not documented
> > in
> > > the ref guide. I think only Full Story is using it. So it's de
> > > facto "experimental" right now and is subject to change... **and
> > removal**.
> > >
> > > FWIW I'd love to help design its replacement, but that's not the
> subject
> > of
> > > this post/thread.
> > >
> > > ~ David Smiley
> > > Apache Lucene/Solr Search Developer
> > > http://www.linkedin.com/in/davidwsmiley
> > >
> >
>
Re: The state of PRS -- "experimental"
Posted by David Smiley <ds...@apache.org>.
Calvin, I recommend that you switch away from PRS and instead in Solr 10
disable the Overseer. In doing so, you will continue to have the benefit
of decentralized state updates (a shared characteristic of both
schemes), which is likely desirable for so many replicas you have in
aggregate. You didn't say if you have any large collections (>200
replicas); if you do then probably don't disable the Overseer yet.
Thanks for pointing out that line in the ref guide. I propose to the
developer community that I remove that from the ref guide in Solr 10 to
discourage users from enabling a system that is likely to change without
regards to backwards compatibility.
~ David
On Wed, Oct 15, 2025 at 7:01 PM Calvin Smith <ca...@lucasfilm.com>
wrote:
> PRS is documented in the ref guide:
>
> https://solr.apache.org/guide/solr/latest/deployment-guide/collection-management.html#create-parameters
>
> I know this because I started using it recently (for a new solrcloud
> cluster that I'm working on that will have hundreds of collections), having
> discovered it through https://searchscale.com/blog/prs/.
>
> I didn't realize that it was experimental and might be removed.
>
> Best,
> Calvin
>
> On Wed, Oct 15, 2025 at 3:23 PM David Smiley <ds...@apache.org> wrote:
>
> > SolrCloud's "PRS" (Per Replica State) mode offers a variation on how
> > replica state is tracked, affecting how state is stored in ZooKeeper and
> > certainly affecting SolrCloud code. It solves a many-replica scalability
> > problem of large collections. Coincidentally, that is exactly the
> achilles
> > heel of disabling the Overseer, however PRS didn't go far enough in its
> > approach (IMO) as there is still replica information in state.json. I
> love
> > the conceptual idea / direction of PRS but not the implementation, which
> is
> > complex -- complexified further by being bolted onto the existing code
> > instead of green-field. If we are to imagine making any serious
> > improvements like this to how a collection's state is structured in
> > ZooKeeper, I can't imagine realistically doing such work with PRS
> > existing. I think such work would start with removing PRS without
> > concern/burden of compatibility.
> >
> > Thankfully, PRS is rather invisible to our users -- it's not documented
> in
> > the ref guide. I think only Full Story is using it. So it's de
> > facto "experimental" right now and is subject to change... **and
> removal**.
> >
> > FWIW I'd love to help design its replacement, but that's not the subject
> of
> > this post/thread.
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
>
Re: The state of PRS -- "experimental"
Posted by Calvin Smith <ca...@lucasfilm.com>.
PRS is documented in the ref guide:
https://solr.apache.org/guide/solr/latest/deployment-guide/collection-management.html#create-parameters
I know this because I started using it recently (for a new solrcloud
cluster that I'm working on that will have hundreds of collections), having
discovered it through https://searchscale.com/blog/prs/.
I didn't realize that it was experimental and might be removed.
Best,
Calvin
On Wed, Oct 15, 2025 at 3:23 PM David Smiley <ds...@apache.org> wrote:
> SolrCloud's "PRS" (Per Replica State) mode offers a variation on how
> replica state is tracked, affecting how state is stored in ZooKeeper and
> certainly affecting SolrCloud code. It solves a many-replica scalability
> problem of large collections. Coincidentally, that is exactly the achilles
> heel of disabling the Overseer, however PRS didn't go far enough in its
> approach (IMO) as there is still replica information in state.json. I love
> the conceptual idea / direction of PRS but not the implementation, which is
> complex -- complexified further by being bolted onto the existing code
> instead of green-field. If we are to imagine making any serious
> improvements like this to how a collection's state is structured in
> ZooKeeper, I can't imagine realistically doing such work with PRS
> existing. I think such work would start with removing PRS without
> concern/burden of compatibility.
>
> Thankfully, PRS is rather invisible to our users -- it's not documented in
> the ref guide. I think only Full Story is using it. So it's de
> facto "experimental" right now and is subject to change... **and removal**.
>
> FWIW I'd love to help design its replacement, but that's not the subject of
> this post/thread.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>