关于SolrCloud的索引分片和查询的可增强点

Solr4.0包含了分布式的sorl解决方案solrCloud，可以做sharding切分，每个sharding中节点支持选举算法（leader,replica），在sharding里面支持query的负载均衡。
在集群启动时，就需要声明当shard、collection等信息，启动过程中把集群的状态信息维护在zookeeper节点里。
集群中的任何一台server都可以响应客户端的请求，包括索引操作和查询操作。

对于索引操作，solrCloud提供了简单的分片算法，即根据当前的索引记录的ID值做hash操作，后根据zookeeper中维护的集群的相关状态（Collection,RangeInfo,Range<min,max>）去查找hash值在哪个Range中，找到对应的shard；在该shard中 leader 中建立索引，Leader节点更新结束完成，最后将版本号和文档转发给同属于一个Shard的replicas节点。不过在建立索引时，shard的算法没有考虑到负载均衡，有可能往一个shard中一直插入，所以需要自己考虑进行shard的切分负载均衡。

关于shard切分的算法，这里提出个人的一点想法，简单一点的话可以独立维护Sharding切分管理模块，统计每个sharding的索引数量，根据统计的数量，进行索引分发；并针对每个shard维护BooleamFilter来快速的定位索引ID是否在该shard节点，以供查询用，当然如果整个索引key的量可以放在内存中的话，可以建立hash表存储。以上这种索引管理方式对动态的扩展shard也比较方便。

对于查询操作，如果不指定shard,会到该集群中所有的shard中查找，然后在被查的server中合并，每个shard中会自动的做负载均衡。
这里有值得改进的地方，如果查询参数中带有索引的唯一ID，就可以进行id 的hash算法，找到具体的shard，节省了其他shard的调用开销。

关于集群的动态扩展方面，考虑的还不太全面
集群节点动态的增加没有考虑，比如动态增加shard，或者shard中动态增加一个节点，据我了解，还没有很好的支持。