Sharding based on terms will help, in the sense that it minimises the cardinality of the inverted index, however there is a good presentation at ElasticSearch why term sharding has problems. Its hard to balance which kills gather-scatter (or map reduce) performance, and the network bandwidth requirements are higher.

Even so, the 3 problems here are the number of query terms, one for each principal the user has, the time it takes to process a single term in a query, and the number of principals per document. If each document had one principal the query operation would be a first order problem relative to the number of principals a user has. Since docs can have many principals its a second order problem in the index, which makes it too expensive for real time searching in real use cases. (think 1s response not 2ms). We could has all the principals together but that would raise the cardinality up to order n*(n-1)*….(n-t) where n is the total number of principals and t is the number held per user/document. n could easily be 1M and t 500 in medium size system. In practice the cardinality would be unlikely to ever reach the predicted, but its still going to be big. In Sakai 2 there was a perfect organization of content that made the responses dense. Content was organized into groups and, in general users who where members of those groups had access to all the content in those groups, so you could simply use a single read principal on each Lucene doc to generate a suitably dense result set. The case were a single user had more principals than Lucene could cope with hasn’t happened (yet), and when it does, there is a simple solution. Make a special principal for that set of groups, and add it to all documents that appear in any one of those groups. Unfortunately in Sakai OAE, there is no organising principal, and hence all documents already have 10s of principals and user already have hundreds. I think most systems are more like Sakai 2 in this respect.

Your Blog post seems to indicate that things like the transaction log are not complete and https://issues.apache.org/jira/browse/SOLR-2700 is being worked on. Nice to see, as ever in Solr, that there is lots of review and verification before anyone is prepared to say its done. I feel quite safe taking 4.0-SNAPSHOTS because of that.

Do you have a feeling for when its going to be safe to use the NewSolrCloud in production for mere mortals ?

Also is the replication by pushing segments, or is it incremental per document ?

The other problem is that (IIUC) the ServiceLoader pattern was intended for simple services that either dont need to connect to the environment they are working within or explicitly have initialization as part of the SPI. Where the SPI is agnostic about initialization and context, leaning towards pure IoC like patterns it falls to the SPI implementation to acquire context through out of band or other means. What would be really nice is to see a RFC that enabled a SPI implementation to be a declaratively managed component, living in a separate bundle, where it gained access to a protected set of SPI and support classes within the SPI consumer bundle. I think I am right in saying that would require the declarative service manager to pre-bind to the SPI consumer classloader before instancing the SPI implementation, so that the SPI classes from the correct classloader were already available?

It is good to see Aries addressing these issues and looking at RFC 167 it certainly looks like its going to address the ServiceLocator pattern, which continues to be the bain of anyone integrating 3rd part components in OSGi. Its almost become a standard pattern in my code bases to set the context classloader to the bundle classloader in advance of performing initialisation of anything not designed for OSGi.