[ 
https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13700329#comment-13700329
 ] 

Otis Gospodnetic edited comment on SOLR-4998 at 7/4/13 8:27 PM:
----------------------------------------------------------------

I am not sure what naming "conventionS" Solr code is using.  I know most people 
are inconsistent and so code (in general, not referring specifically to Solr 
here) is also often inconsistent.  Here we see this inconsistency leads to a 
lot of confusion.  I think it's great Anshum initiated this. My personal 
preference would be to:
* pick the terminology that makes sense and is easy to explain and understand
* adjust BOTH code and documentation to match that, even if it means renaming 
classes and variables, because it's only going to get harder to do that if it's 
not done now.

OK, here is another attempt:

# A Cluster has Collections
# A Collection is a logical index
# A Collection has as many Shards as "numShards"
# A Shard is a logical index subset
# There are as many physical instances of a given Shard as the Collection's 
"replicationFactor"
# These physical instances are called Replicas
# Each Replica contains a Core
# A Core is a single physical Lucene index
# One Replica in each Shard is labeled a Leader
# Any Replica can become a Leader through election if previous Leader goes away
# Each Shard has 1 or more Replicas with exactly 1 of those Replicas acting as 
the Leader

I think this is it, no?

Visually, by logical role:
||shard 1||shard 2||shard 3||
|leader 1.1|leader 2.1|leader 3.1|
|replica 1.2|replica 2.2|replica 3.2|
|replica 1.3|replica 2.3|replica 3.3|
|replica 1.4|replica 2.4|replica 3.4|
|replica 1.5|replica 2.5|replica 3.5|

So we would say that the above Collection has:
* 3 Shards
* 5 Replicas
* in each Shard 1 Replica *acts as* a Leader

If we ignore roles then this same Collection has the following physical 
structure:

|replica 1.1|replica 2.1|replica 3.1|
|replica 1.2|replica 2.2|replica 3.2|
|replica 1.3|replica 2.3|replica 3.3|
|replica 1.4|replica 2.4|replica 3.4|
|replica 1.5|replica 2.5|replica 3.5|

Yes/no?

                
      was (Author: otis):
    I am not sure what naming "conventionS" Solr code is using.  I know most 
people are inconsistent and so the code is also often inconsistent.  Here we 
see this inconsistency leads to a lot of confusion.  I think it's great Anshum 
initiated this. My personal preference would be to:
* pick the terminology that makes sense and is easy to explain and understand
* adjust BOTH code and documentation to match that, even if it means renaming 
classes and variables, because it's only going to get harder to do that if it's 
not done now.

OK, here is another attempt:

# A Cluster has Collections
# A Collection is a logical index
# A Collection has as many Shards as "numShards"
# A Shard is a logical index subset
# There are as many physical instances of a given Shard as the Collection's 
"replicationFactor"
# These physical instances are called Replicas
# Each Replica contains a Core
# A Core is a single physical Lucene index
# One Replica in each Shard is labeled a Leader
# Any Replica can become a Leader through election if previous Leader goes away
# Each Shard has 1 or more Replicas with exactly 1 of those Replicas acting as 
the Leader

I think this is it, no?

Visually, by logical role:
||shard 1||shard 2||shard 3||
|leader 1.1|leader 2.1|leader 3.1|
|replica 1.2|replica 2.2|replica 3.2|
|replica 1.3|replica 2.3|replica 3.3|
|replica 1.4|replica 2.4|replica 3.4|
|replica 1.5|replica 2.5|replica 3.5|

So we would say that the above Collection has:
* 3 Shards
* 5 Replicas
* in each Shard 1 Replica *acts as* a Leader

If we ignore roles then this same Collection has the following physical 
structure:

|replica 1.1|replica 2.1|replica 3.1|
|replica 1.2|replica 2.2|replica 3.2|
|replica 1.3|replica 2.3|replica 3.3|
|replica 1.4|replica 2.4|replica 3.4|
|replica 1.5|replica 2.5|replica 3.5|

Yes/no?

                  
> Make the use of Slice and Shard consistent across the code and document base
> ----------------------------------------------------------------------------
>
>                 Key: SOLR-4998
>                 URL: https://issues.apache.org/jira/browse/SOLR-4998
>             Project: Solr
>          Issue Type: Improvement
>          Components: SolrCloud
>    Affects Versions: 4.3, 4.3.1
>            Reporter: Anshum Gupta
>
> The interchangeable use of Slice and Shard is pretty confusing at times. We 
> should define each separately and use the apt term whenever we do so.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to