ahhhh, there's a lightbulb. your last paragraph cleared up confusion i was carrying through the responses (and, incidentally, was likely the reason for confusion on the ZK question you couldn't make sense of). i was thinking zookeeper was a separate means of handling things from solrcloud, two entirely different approaches to scaling out. very much helpful to see how off balance i was on that assumption!
thanks shawn- -- *John Blythe* Product Manager & Lead Developer 251.605.3071 | j...@curvolabs.com www.curvolabs.com 58 Adams Ave Evansville, IN 47713 On Fri, Dec 16, 2016 at 3:31 PM, Shawn Heisey <apa...@elyograg.org> wrote: > On 12/16/2016 10:30 AM, John Blythe wrote: > > thanks, erick. this is helpful. a few questions for clarity's sake, but > > first: nope, not using SolrCloud as of yet. > > > > - if i start using SolrCloud i could have my current multi-core setup > > (e.g. "transactions", "opportunities", etc.) exist within the > appropriate > > collection. so instead of dev-transactions i'd have a 'dev' > collection that > > has a 'transactions' core inside of it? > > No. You would not be thinking in terms of cores at all. When your > programs talk to SolrCloud, they will only care about collections. > > Some terminology clarification: Collections are made up of one or more > shards. Shards are made up of one or more replicas. Each shard replica > is a core. One replica for each shard is elected as leader. If there's > only one replica, then there's no redundancy, and that replica becomes > leader. > > For the example you gave, you would have dev-transactions and > prod-transactions collections. Each of these collections might have > shard replicas (cores) on completely different machines in the cloud ... > or they might be on the same machines. During normal operation, you > would never access a core directly. You'd probably only ever do that if > something went very wrong and you needed to take very unusual steps to > fix it or figure out what went wrong. > > > - this seems to be the same with ZK, too? > > No idea what you're asking here. Perhaps it should be obvious, but I > can't figure it out. > > > - i'm totally fine w separate/diff indexing. the demo collection, for > > instance, *has* to be separate from production bc the data has been > > stitched together from various customers' accounts on prod and > blinded so > > that we have avoid privacy issues and can have all the various goodies > > under one demo account rather than separate ones. is the separate > indexing > > happening out of the box w Cloud or something it's even capable of? > > Again, I don't really know what you're asking with "separate indexing". > Different collections are separate from each other, just like cores in > standalone mode. Each collection is linked to a configuration in > Zookeeper, which all of its shard replicas (cores) will use. You could > have all your collections pointing to the same config. Some (or all) of > them could point to completely different configs, too. > > Addressing a later question: You don't have SolrCloud if you don't have > zookeeper. ZK is a requirement. You don't really interact directly > with zookeeper when you're using SolrCloud. It's an administrative > detail in the *setup* of SolrCloud. > > Thanks, > Shawn > >
