On Thu, Feb 9, 2012 at 5:27 AM, Adeel Qureshi <adeelmahm...@gmail.com>wrote:
> Thanks for the explanation. It makes sense but I am hoping that you can > clarify things a bit more .. > > so now it sounds like in solrcloud the concept of cores have changed a bit > .. as you explained that for me to have 2 cores with different schemas I > will need 2 different collections .. and one good thing about solrcores was > that you could create new ones with coreadmin api or the http calls .. to > create new collections its not that automated right .. > > secondly if collections represent what kind of used to be solrcore then > once i have a collection .. why would i ever want to add multiple cores to > it .. i mean i am trying to think of a reason why it would make sense to do > that. > Hi Adeel, A core is still what it was before: it provides indexing & search for one physical index. The concepts of collections and slices layer on top of it. A core corresponds onto-to-one with a shard. So you have: collection -> slice -> shard = core Each slice contains a subset of the data of the collection. All the shards within one slice are replica's, thus contain the same data. All the actual data/indexes are in the cores. Collections, slices and shards are logical concepts that only exist in ZooKeeper. Thus a collection in itself isn't a physical index, it are only the cores below it that contain actual data. All the cores within one collection will use the same schema (the schema associated with the collection), since they are part of the same logical index. You can still use the coreadmin API to create cores (that's what I've done in my blog), but in SolrCloud a core must always be associated with a [slice in a] collection. Thus when you create a core it either becomes part of an existing collection, or a new collection is created. HTH, Bruno. -- Bruno Dumon Outerthought http://outerthought.org/
