waw...
well, transactional or "transactional", whether it's a nice feature to
have or just a "selling point". Bottom line, For some applications
Compass can be very appealing, for other Solr will be the choice. In the
last several years I've integrated both in different applications and
gained from both. Do you own math based on your needs, requirements and
personal preferences. But if someone asks a questions, then it's always
nice to get several opinions from different experiences.
peace,
Uri
Fuad Efendi wrote:
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