Hi, Well, I thought I would jump here as the creator of Compass (up until this point, the discussion was great and very objective).
Compass is here for about 5/6 years now (man, how time passes). Concentrating on the transactional implementation it provides, there have been changes to it along the years. The funny thing about that, by the way, is that the first implementation based on Lucene 1.9 was a combination of Lucene NRT and how it handles segments in the latest Lucene version. I will try and focus on the latest implementation, which uses latest Lucene IndexWriter features. Lucene IndexWriter provides the ability to prepare a commit point, and them commit it. The idea is that most of the heavy operations and things that might go wrong are done on the prepare phase, with the commit basically just updating the segments file. In its nature, its very close to what databases do with their 2 phase commit implementation (though, admittedly, the second phase probably has higher chances of 2 phase success). What Compass does, with its transactional integration with other transactional mechanisms, like JTA, is the ability to act as an XA Resource, and use the IndexWriter prepare and commit within the appropriate XA resource phases. Ultimately thought, even XA is not 100% safe, for example, what happens when you have 5 resources, all gone through the prepare phase, and the 4th failed in the commit phase ... (simplified example, but proves the point). Another point, is how Compass handles transactions. Basically, it has what I call transaction processors. The read committed one provides just that, a read committed transactional isolation level (you do changes, you see them while within the transaction, other see them when you commit the transaction). It does come with its overhead compared with other paradigms of how to use Lucene, but it gives you other things that a lot of people find good. There are other transaction processors that work differently, each with its own use case (heavy indexing, non real time search, async indexing, and so on). At the end, its really hard to compare Compass to Solr. One evident difference is the fact that Solr is more geared to be a Server solution, while Compass at being more embeddable. There are difference in features that each provides, and each comes with its own benefits. I think the rest of the mails on this thread have already covered that very objectively. In any case, you, the user, should use the right tool for the job, if it happens to be either Compass or Solr, I wish you all the best (and luck) at succeeding in it. Shay Minutello, Nick wrote: > > > > Ultimately... You're right, to some extent, the transaction > synchronisation isn't ideal for sheer throughput if you many small > transactions (as Lucene benefits from batching documents when you > index...). However, the subindex feature gives you decidedly more > throughput since the locking is at the subindex level. > >>> It is just blatant advertisement, trick; even JavaDocs remain > unchanged... > Such sneaky developers.... > While I suspect its changed a bit since you last looked, I only ever > used the local tx synch support, and not terribly interested in arguing > the point... > > -N > > > -----Original Message----- > From: Funtick [mailto:f...@efendi.ca] > Sent: 26 January 2010 02:44 > To: solr-user@lucene.apache.org > Subject: RE: Solr vs. Compass > > > > Minutello, Nick wrote: >> >> Maybe spend some time playing with Compass rather than speculating ;) >> > > I spent few weeks by studying Compass source code, it was three years > ago, and Compass docs (3 years ago) were saying the same as now: > "Compass::Core provides support for two phase commits transactions > (read_committed and serializable), implemented on top of Lucene index > segmentations. The implementation provides fast commits (faster than > Lucene), though they do require the concept of Optimizers that will keep > the index at bay. Compass::Core comes with support for Local and JTA > transactions, and Compass::Spring comes with Spring transaction > synchronization. When only adding data to the index, Compass comes with > the batch_insert transaction, which is the same IndexWriter operation > with the same usual suspects for controlling performance and memory. " > > It is just blatant advertisement, trick; even JavaDocs remain > unchanged... > > > Clever guys from Compass can re-apply transaction log to Lucene in case > of server crash (for instance, server was 'killed' _before_ Lucene > flushed new segment to disk). > > Internally, it is implemented as a background thread. Nothing says in > docs "lucene is part of transaction"; I studied source - it is just > 'speculating'. > > > > > Minutello, Nick wrote: >> >> If it helps, on the project where I last used compass, we had what I >> consider to be a small dataset - just a few million documents. Nothing > >> related to indexing/searching took more than a second or 2 - mostly it > >> was 10's or 100's of milliseconds. That app has been live almost 3 >> years. >> > > I did the same, and I was happy with Compass: I got Lucene-powered > search without any development. But I got performance problems after few > weeks... I needed about 300 TPS, and Compass-based approach didn't work. > With SOLR, I have 4000 index updates per second. > > > -Fuad > http://www.tokenizer.org > > -- > View this message in context: > http://old.nabble.com/Solr-vs.-Compass-tp27259766p27317213.html > Sent from the Solr - User mailing list archive at Nabble.com. > > > =============================================================================== > > Please access the attached hyperlink for an important electronic > communications disclaimer: > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > > =============================================================================== > > > > -- View this message in context: http://old.nabble.com/Solr-vs.-Compass-tp27259766p27323885.html Sent from the Solr - User mailing list archive at Nabble.com.
