Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change 
notification.

The "SolrCloud" page has been changed by YonikSeeley.
The comment on this change is: brainstorming zk schema layout.
http://wiki.apache.org/solr/SolrCloud?action=diff&rev1=2&rev2=3

--------------------------------------------------

  
  In the most basic case though, we will be dealing with indexes built outside 
the cluster.  In these cases, we won't know what documents are in what shards, 
but we still need a way to identify the fact that one shard is simply a replica 
of another shard.
  
+ === Layout ===
+ This represents brainstorming on what the virtual filesystem (i.e. schema) in 
zookeeper could look like.
+ 
+ mycluster/hosts
+ 
+  . 192.168.0.10
+ 
+  . ''#how to identify hosts?  hostname?  IP?''  Hosts may have more than one 
IP - do we want to use multiple?
+ 
+ mycluster/configs/collection1_config/v1/
+ 
+  . solrconfig.xml, schema.xml, stopwords.txt, etc
+ 
+ collections/collection1/
+ 
+  . config=collection1_config    ''#explicitly specified so it allows multiple 
collections to use the same config''
+ 
+ #Have the collection directly point to the shard URLs? (method #1)
+ 
+ /collections/collection1/shards
+ 
+  . localhost:8983/solr/collection1=shardX,shardY,shardZ
+ 
+  . localhost:7574/solr/collection1=shardX,shardZ
+ 
+ #Or perhaps just specify the nodeid (what would that be? localhost:8983? 
localhost:8983/solr?) and make it such that "collection1" is always implied 
because that is the collection name?  Perhaps that could turn out to be too 
limiting though, if someone is trying to do federated search?  Perhaps list the 
nodes belonging to a collection, with the shards each node has? (method #2)
+ 
+ /collections/collection1/nodes/localhost:8983/
+ 
+  . shards/       #the shards that the node localhost:8983 currently has that 
belong to this collection
+ 
+  . X=/solr/collection1  #the relative URL from the nodeid
+ 
+  . Y=/solr/collection1
+ 
+  . Z=/solr/collection1
+ 
+  . # We should be able to record the version of the index (shard), the last 
time it was updated, etc.
+ 
+ # Method #3 could move the shards listing for each node to the model of the 
node itself.
+ 
+ === Other Questions ===
+ Is there a single master (cluster manager, not solr master) per collection, 
or a master for all collections in the cluster?
+ 
  == Resources ==
  http://sourceforge.net/mailarchive/forum.php?forum_name=bailey-developers
  

Reply via email to