>> Why to embed "indexing" as a transaction dependency? Extremely weird idea. There is nothing weird about different use cases requiring different approaches....
If you're just thinking documents and text search ... then its less of an issue. If you have an online application where the indexing is being used to drive certain features (not just search), then the transactionality is quite useful. >> Even if "commit" takes 20 minutes? >> It's their "selling point" nothing more. "they" are not "selling" anything. You will find its an open-source project, and the main guy is quite a smart guy. I've never seen a commit take 20 minutes... (anything taking that long is broken, perhaps in concept) >> Also, note that Compass (Hibernate) ((RDBMS)) use specific "business domain >> model" terms >> with relationships; huge overhead to convert "relational" into >> "object-oriented" (why for? Any advantages?) Perhaps the pros and cons of Object Relational Mapping are for another forum? There is naturally some overhead in Compass's OSEM - but it makes your life easier if you work with the same domain model irrespective of whether something comes from the database or comes from the index. Typically we serve search results from the index - and when clicking on one of the results, we load from db to get the master copy. Moreover, the OSEM does an excellent job of flattening & indexing whatever object hierarchy exists into the flat lucene document - this is great for google-style searches where you want to find, e.g. some product using _anything_ you can remember about it. Using Lucene or Solr, you have to write the code that constructs the lucene document from the object & its relationships. Not an issue if you have a small number of entity types, but rather a pita if you have dozens... Or you eventually write some reflection-based thing.. (i.e. you begin to write a poor-mans implementation of compass OSEM) As mentioned before, they address different kinds of problems.... -Nick -----Original Message----- From: Fuad Efendi [mailto:f...@efendi.ca] Sent: 23 January 2010 05:01 To: solr-user@lucene.apache.org Subject: RE: Solr vs. Compass Of course, I understand what "transaction" means; have you guys been thinking some about what may happen if we transfer $123.45 from one banking account to another banking account, and MySQL forgets to index "decimal" during transaction, or DBA was weird and forgot to create an index? Absolutely nothing. Why to embed "indexing" as a transaction dependency? Extremely weird idea. But I understand some selling points... SOLR: it is faster than Lucene. Filtered queries run faster than traditional "AND" queries! And this is real selling point. Thanks, Fuad Efendi +1 416-993-2060 http://www.linkedin.com/in/liferay Tokenizer Inc. http://www.tokenizer.ca/ Data Mining, Vertical Search > -----Original Message----- > From: Fuad Efendi [mailto:f...@efendi.ca] > Sent: January-22-10 11:23 PM > To: solr-user@lucene.apache.org > Subject: RE: Solr vs. Compass > > Yes, "transactional", I tried it: do we really need "transactional"? > Even if "commit" takes 20 minutes? > It's their "selling point" nothing more. > HBase is not transactional, and it has specific use case; each tool > has specific use case... in some cases Compass is the best! > > Also, note that Compass (Hibernate) ((RDBMS)) use specific "business > domain model" terms with relationships; huge overhead to convert > "relational" into "object-oriented" (why for? Any advantages?)... > Lucene does it behind-the-scenes: you don't have to worry that field > "USA" (3 > characters) is repeated in few millions documents, and field "Canada" > (6 > characters) in another few; no any "relational", it's done > automatically without any Compass/Hibernate/Table(s) > > > Don't think "relational". > > I wrote this 2 years ago: > http://www.theserverside.com/news/thread.tss?thread_id=50711#272351 > > > Fuad Efendi > +1 416-993-2060 > http://www.tokenizer.ca/ > > > > -----Original Message----- > > From: Uri Boness [mailto:ubon...@gmail.com] > > Sent: January-21-10 11:35 AM > > To: solr-user@lucene.apache.org > > Subject: Re: Solr vs. Compass > > > > In addition, the biggest appealing feature in Compass is that it's > > transactional and therefore integrates well with your infrastructure > > (Spring/EJB, Hibernate, JPA, etc...). This obviously is nice for > > some systems (not very large scale ones) and the programming model > > is > clean. > > On the other hand, Solr scales much better and provides a load of > > functionality that otherwise you'll have to custom build on top of > > Compass/Lucene. > > > > Lukáš Vlček wrote: > > > Hi, > > > > > > I think that these products do not compete directly that much, > > > each > > fit > > > different business case. Can you tell us more about our specific > > situation? > > > What do you need to search and where your data is? (DB, > > > Filesystem, > > Web > > > ...?) > > > > > > Solr provides some specific extensions which are not supported > > directly by > > > Lucene (faceted search, DisMax... etc) so if you need these then > your > > bet on > > > Compass might not be perfect. On the other hand if you need to > > > index persistent Java objects then Compass fits perfectly into > > > this > scenario > > (and > > > if you are using Spring and JPA then setting up search can be > > > matter > > of > > > several modifications to configuration and annotations). > > > > > > Compass is more Hibernate search competitor (but Compass is not > > limited to > > > Hibernate only and is not even limited to DB content as well). > > > > > > Regards, > > > Lukas > > > > > > > > > On Thu, Jan 21, 2010 at 4:40 PM, Ken Lane (kenlane) > > <kenl...@cisco.com>wrote: > > > > > > > > >> We are knee-deep in a Solr project to provide a web services > > >> layer between our Oracle DB's and a web front end to be named > > >> later to supplement our numerous Business Intelligence > > >> dashboards. Someone > > from a > > >> peer group questioned why we selected Solr rather than Compass to > > start > > >> development. The real reason is that we had not heard of Compass > > until > > >> that comment. Now I need to come up with a better answer. > > >> > > >> > > >> > > >> Does anyone out there have experience in both approaches who > > >> might > be > > >> able to give a quick compare and contrast? > > >> > > >> > > >> > > >> Thanks in advance, > > >> > > >> Ken > > >> > > >> > > >> > > > > > > > =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
