epugh
commented
2 years ago I was thinking about how to articulate "Why we have multiple Solr and ZK's in Chorus" well, and I think I'm probably NOT going to write a great rationale... But here goes... ;-). Chorus is supposed to model best practices in Solr for ecommerce search, and be a reasonable facisimile of a typical setup. Since in my, admittedly opinoniated, view of the world I only use SolrCloud, I want to start with that. Moving beyond the confines of a single Solr node however has it's own wrinkles, like if you want to do a cross collection join, do you have the other index on your node? Or, how does forwarding access permissions work if you hit one node, and the query is forwarded? Also, I frequently grab Chorus just to demo basic SolrCloud capablities around failover and scaling. Thse are all reasons why I like having the three node Solr, even though "technically" is isn't required for just the basic thrust of Solr. Lastly, as we start doing more stuff like collecting clicks and boosting search on clicks, and start using the node types in Solr 9, we will want multiple nodes.
risdenk
This uses a single node of Solr and ZK to avoid resource issues when only using 4GB for Docker. Its not clear to me why 3 nodes of Solr and 3 nodes of ZK is necessary to demo all the moving pieces. It adds quite a bit of weight when isn't entirely necessary. I can be convinced to leave the 3 nodes - but just putting this out here since it made the deployment a lot simpler.