Hello Yonik, that's very interesting, I'm working since some time on the Infinispan based Lucene Directory, have you seen my announcement on dev-lucene? I didn't dare to cross-post. Again the link: http://www.jboss.org/community/wiki/InfinispanasaDirectoryforLucene
It's an implementation to distribute the index to a dynamic cluster, and Infinispan enables autodiscovery even on the cloud. I'm only focusing on the Directory and LockManager; the Directory is working but needs yes some polishing and profiling, while I can trust the LockFactory for having survived some good stress tests and performing well already. I didn't know about ZooKeeper, and in my plans the index sharding would have been transparent to Lucene; It shouldn't be hard to have non-transparent sharding on top of it i you need that, and the low level distribution is totally configurable. It's also nice it can scale down to zero-nodes, persisting the in memory distributed state to something else (some plugins provided, like JDBC or S3 stores). Regards, Sanne 2009/12/4 Yonik Seeley <yo...@lucidimagination.com>: > I hereby dub Solr 1.5 "The Cloud Edition"! > (of course anyone else may also dub it anything else they so choose ;-) > > There's lots of prototyles and great work floating around that aim to > increase the practical scalability and ease of cluster management of > Solr. I did some brainstorming myself of how we could use zookeeper > on the flight to ApacheCon US last month, and had a number of > discussions with various people while there. I'm going over those > notes and adding some stuff to a new wiki page: > > http://wiki.apache.org/solr/SolrCloud > > Of course the main issue is at https://issues.apache.org/jira/browse/SOLR-1277 > And there is already another wiki page > http://wiki.apache.org/solr/ZooKeeperIntegration > > I started a new page for myself because I'm not sure we're all in sync > yet and didn't want to get into competitive editing :-) > Anyway, I think this is going to be a big enough issue with > potentially a ton of discussion, and we should perhaps use the mailing > lists for general design discussions rather than forcing everything > into a single JIRA issue (which doesn't deal well with huge threads). > > -Yonik > http://www.lucidimagination.com >
