I was make a comparison of both technologies (SOLR AND Hibernate Search) and i see many things are eguals. Anyone could told me when i must use SOLR and when i must use Hibernate Search?

Im my project i will have:
1. Queries for indexed fields (Strings) and for not indexed Fields (Integer, Float, Date). [In Hibernate Search on in SOLR, i must search on index and, with results of query, search on database (I can't search in both places ate same time).]
I Will Have search like:
"Give me all Register Where Value < 190 And Name Contains = 'JAVA' "

2. My client need process a lot of email (20.000 per day) and i must indexed all fields (excluded sentDate ) included Attachments, and performance is requirement of my System

3. My Application is multiclient, and i need to separate the index by client.

In this Scenario, whats the best solution? SOLR or HIbernateSearch

I See SOLR is a dedicated server and has a good performance test. I don't see advantages to use hibernate-search in comparison with SOLR (Except the fact of integrate with my Mapped Object)

Please, open my eyes to see other advantages of Hibernate Search

Thanks for Help

Hi Anderson,
welcome to a long chat:) I'm working since years with both Solr and Hibernate Search as a consultant on search solutions. While I like Solr and have installed that with satisfaction some times, I'm recommending Search more often and for this reason I've ended up contributing lots of patches to it, so I might be a bit biased now as I feel it is a bit mine too. But being just a contributor, the fact I spend my time in improving it should be a good evidence I really believe it's good.

So in short when do I recommend Solr: when a machine will be dedicated to it, there's no interaction with a database, and it is interesting to have an XML interface. It's especially good when these conditions are met, and the indexes don't change very often making an almost-search only system.
Hibernate Search works as well in these situations, it will just take an additional simple step to configure and (currently) needs a database, so when nothing more is required Solr is not a bad choice. Also Search does not contain an XML network server.

Looking into performance, they are both using Lucene as search technology, so query time on a single node will always be very close. They both scale linearly on extra nodes to perform searches, they both use a single-master-write approach to apply changes. Actually Search doesn't need one, it will work fine on a single node too: reference only, no XML parsing, and is able to show fresh results after a change as soon as the change is committed. They actually even share some code, as Search integrates Solr's analyzers which are very interesting: all the cool stemming and phonetic matches you see documented in Solr can be used easily in Search too (one annotation - declaratively - on the relevant property).

Hibernate Search is mapping nice POJOs and is able to get you POJOs back as search results (handy for any kind of presentation layer), apply changes to them and figure out the changes needed to go in both index and database, so when your application does anything on your data, or you think in future it might begin to do something, it's just much easier to update and maintain as it's primary goal is to keep DB&indexes in synch, transactionally. The chance for mismatches is kept at a minimum by design and you'll always be able to rebuild a correct index from a trusted database source. With Solr it's your own problem how you keep data consistent: you can rebuild the index from a database, but when you apply a change to the database you'll have to wait for next index update, or start it yourself.
In Java I really prefer to deal with a POJO than with XML; as I said before if all you need is XML results from a nearly immutable database, Solr is your choice.


Yes with both solutions you have to index the numerical value as mixed queries are not fully supported. Some degree of database-level filtering is available in Search, but the recommended strategy is to index both properties. Both provide the notions of filters, in Search you have parametric filters which can boost performance.
Search has a very nice additional advantage: you can always fall back to SQL or HQL if the query you make is more about relations than index. It's more flexible, you don't have to index it all, and the results are of the same kind, avoiding much code.


As I said before they share a great deal of technology and design, I expect them to perform similarly, and 20,000 emails a day is easy to match for both of them. If you need the new emails to be searchable immediately, you have to go for Search as it can be setup to expose realtime changes. Both frameworks are being actively developed and getting more and more performance improvements, I never ran a speed comparison, but Search can avoid XML processing and make some clever use of Hibernate's caches, or balance the load between the index and database to have them both working for you, each one on the kind of work they were designed for.


Both solutions have several options to implement this, no problems either.

Generally I consider it simpler to use Search, and easier to maintain, when requirements change there's no code repetitions around. It's very simple to use for me because I have used Hibernate before, it might be a drawback if you dont know it yet, but it's always good to learn it :-) Having database query options is always good, with Solr you could of course write your own code to query the database but then you'll have to convert it to other representations, you have mismatches, more code to change for each requirement change.
I don't know on what nice news the Solr team is working on, but the Search roadmap is exciting: soon it will use a clustered replicated in memory index and drop the current limitation of a single writing master node.

I understand the disadvantage about Solr is that when schema is changed, there are a couple of stuff to change (on top of hbm and the entity classes) such as:
- mapping entities
- solr's schema.xml
Manual reindex of all the records is required for all the records to reflect the new schema.

However for Search, a manual reindex of all the records is also necessary, right? I understand that Search internally accessed the db and retrieve the managed objects. Thus, despite the indexed file may contain a different schema as the db (which i assumed that manual reindex is required), one can still search without manually reindexing?
Could you highlight what should be done if the schema changes?

Another question:
Hibernate Search could only be employed if Hibernate/JPA was used. else it's not applicable?

In your point of view, what is the key disadvantage of solr that one is strongly encouraged to use Hibernate search?

Hi,

this might not be a direct answer to your question, but maybe it helps you to make a decision.
First of all:

• Do you create some sort of Email instances and do you want to keep them in a database?
• If so, do you want to use a ORM (speak Hibernate) to handle this mapping from object world to database tables

From your previous posts I am not so sure what your architecture is and whether you just want xml responses or whether you would prefer managed entities as response. If your answer is "no" to any of the two questions above your choice is Solr.

If you are using Hibernate which is as you say a requirement for using Hibernate Search you have the choice between Solr and Hibernate Search. However, personally I would in this case most probably use Search (warning, I am biased ;-)), since there was a reason for you to choose a ORM framework in the first place. If you use Hibernate and Solr you will have to manually create your Solr indexing xml files from the retrieved managed objects. That seems to me like an overhead. Again, it might depend on your usecase and architecture constraints.

If you change your Email instance (or generally the data you want to be searchable) you will have to re-index in both cases (Search or Solr), since you need to get your data and index into sync. Of course you can change your data without updating your indexes, but that's probably not such a good idea.

Generally you have to be careful with your terminology. It seems you are using "schema" in multiple meanings/context. Solr works via HTTP sending different types of xml files across the wire. It makes sense to speak of indexing schema as the xml request you are using for indexing. Search is much more object/entity centric and if you mention schema in this context I am thinking of the underlying database schema defined by your Hibernate mapping. Last but not least, in terms of Lucene it does not make sense to speak of a schema in the index. The data structure of a Lucene index is centered around a Lucene Document which can contain arbitrary key/value pairs. As a concrete example, say you are adding a new property to your Email entity which means you have to change your Hibernate mapping and hence the database schema. However, if this new property doesn't have to be searchable you might not have to rebuild the Lucene index.

I hope this helps you making a decision.

--Hardy

Sorry, think I forgot to indicate that i was borrowing this thread to further my understanding..


Yes, Search uses Hibernate mapping. Thus, if I dont use Hibernate or JPA, will Search work? I supposed not.
If my current system uses JDBC connections, can I generate the hbm file and write the configuration file, then can apply Search?


Cool. Thanks!


Since the underlying lucene index is arbitrary key/value pairs. I was wondering the possibility of using Search to index and Solr to retrieve or vice visa?

No.


There is Hibernate Tools to generate mapping files from an existing database schema. Once you have Hibernate running you would have to add the Search specific annotations.


Why would you do that? It does not make sense.