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.
