Hello all, as some of you already know the Infinispan project includes several integration points with the Apache Lucene project, including a Directory implementation, but so far we had a separate community because of the license incompatibility.
I'm very happy to announce now that both Infinispan and its dependency JGroups are going to move to the Apache License, as you can see from the following blogposts: http://infinispan.blogspot.co.uk/2013/05/infinispan-to-adopt-apache-software.html http://belaban.blogspot.ch/2013/05/jgroups-to-investigate-adopting-apache.html I hope this will benefit both projects and allow more people to use both. # What's Infinispan ? It's an in-memory Key/Value store geared to fast data rather than very large data, with Dynamo inspired consistent hashing to combine reliability and resources of multiple machines. Does not support eventual consistency but supports transactions, including XA. When data gets too large to be handled in JVM heap it can "swap" over to different storage engines, i.e. Cassandra, HBase, MongoDB, JDBC, cloud storage, .. [there is much more but for the sake of brevity I expect this to be most useful to Lucene developers] # What's this state of this Infinispan / Lucene Directory? Basically it stores the segments in the distributed cache: so it provides a quick storage engine, real-time replication without NFS trouble, optionally integration with transactions. This is working quite well, and - depending on your needs and configuration options - it might be faster than FSDirectory or RAMDirectory. In all fairness it's not easy to "defeat" the efficiency of FSDirectory when it's in memory-mapping mode: it might happen in some cases that it will be faster, more or less significantly, but I think the real difference is in the scalability options and the flexibility in architectures. It is generally faster than the RAMDirectory, especially under contention. Support for Lucene 4 was just added recently, so while I think it would be great to have custom Codecs for it, that isn't done yet: for now it just stores the byte[] chunks of the segments. This is not a replacement for Solr or ElasticSearch: it provides just a storage component; it does not solve - among others - the problem of distributed writers. It is used by Hibernate Search. Regards, Sanne --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
