32

I have been using the Apache Solr Search module in Drupal 6 and am looking at the Search API for a Drupal 7 install. I have seen some discussion here but I am looking for any reasons for choosing one or the other. Anybody go to this presentation?

As per comment, here is a more specific question:

Is there a reason to choose one over the other? If so, why or why not? I have heard there may be complexity issues and/or performance issues with Search API. Is this true?

19
+100

As of 2015, we can compare Search API vs Apache Solr Search modules with the numbers:

                   | Apache Solr Search  | Search API
Posted in:         | 2007                | 2010
Downloads:         | >2k                 | >20k
Reported installs: | >21k                | >64k
Total bugs:        | >1200               | >600
Active bugs:       | >200                | >170
Commits:           | >1.3k               | >1.5k

which indicates the clear choice. Search API was developed 3 years after and it managed to take advantage of its competitor.

Further more, Search API provides a very different and more flexible architecture and it's being maintained more actively. What is more important, it has already support for the newest Drupal 8 and Solr 5.x which Apachesolr doesn't have yet.

Search API started fresh and it's more flexible in its configuration including Views support (for Apachesolr you need the extra module). There are also plenty of modules which extend its functionality.

Secondly to avoid some problems being solved twice by the community due to differences in architecture of these modules, currently there are some combined efforts between these two projects such as:

  • creating the common way to show facets blocks via Facet API (also know as filters),
  • a common schema and solrconfig.xml configuration files,
  • both maintainers worked together and migrated the connection classes from the Apache Solr Search module into Search API.

Source: Battleplan for Search & Solr in Drupal 8 at Acquia

Note, it's not advised to use both modules in the same environment.

For further technical analysis of differences, please check the details below.

Search API

API Overview:

  • Framework for easily creating searches
  • Abstracts from data sources and backend implementations
  • Large ecosystem with extensions, e.g. backends
  • Facet API integration
  • Heavily based on Entity API

    • Provides metadata
    • Used for index and server configurations

Extension features:

  • Search API Autocomplete
  • Attachments
  • Saved Searches
  • Location
  • Pretty Facets Paths
  • Slider (Search API Ranges)
  • and many more.

Basic structure:

Basic Structure of Search API Solr module

Index features:

  • Different datasources
  • One datasource: entities
  • Based on Entity API:

    • Each property can be indexed
    • Properties of related entities can be indexed

How to configure your index - fields:

How to configure your index - fields in Search API Solr

Search API Views:

  • Full Views support
  • Display any property of an entity
  • Use any indexed field as filter, argument or sort
  • Most code based on Entity API's views integration
  • By default: data retrieved via entity load

    • Can be bypassed ("Retrieve data from Solr" setting in server)
  • Alternative: Search API pages

Search API Recipes:

  • CRUD hooks for indexes and servers
  • Hooks for adding

    • data sources
    • backends
    • data alterations
    • processors
  • Hook fired when indexing items

  • Hook fired when executing a search

Apachesolr

Extension features:

  • Attachments (no media support, custom coding for attachments to other entities)
  • Location (Apachesolr geo, Apachesolr location)

Apachesolr Recipes:

  • Open Source Enterprise Search Platform
  • Apache Foundation
  • Full-text search, highlighting, faceted search, clustering, rich document handling
  • Distributed
  • Replication/scalable
  • Java
  • REST HTTP and answers in XML/JSON and some others
  • Not Relational

Source: Search API vs Apachesolr slideshow


See also:

  • Awesome write-up, thanks! Question 1: why is it advised not to use both modules in the same environment? Question 2: Are the performance differences between the modules negligible at this point (I understand Search API w/solr can now index multiple fields, so entity load is no longer required for displaying e.g. thumbnail image with search results)? – Jordan Magnuson Jun 13 '15 at 20:17
  • @JordanMagnuson 1. You don't use both modules at the same time, because they're not compatible much and most of the websites are dealing only with one Solr search instance, so it doesn't make sense to use both, unless you don't mind to duplicate the work. For example when you need to create some search view, both modules offer separate integration with views module, so you'd need to create two views. – kenorb Jul 3 '15 at 17:18
  • @JordanMagnuson 2. I'm not sure about the performance, I've never had any specific one and probably it changes every version (I was using Apachesolr quite long time ago). If you're using views and facets, you usually use views cache mechanism, so you don't care about processing time much and of course memcached, APC/XCache, etc. The performance really depends on the site structure and how modules interact each other. – kenorb Jul 3 '15 at 17:21
  • Funny that Search API is more used, yet Acquia itself recommends using Apache Solr module docs.acquia.com/acquia-search/search-api#animated – AlxVallejo Jul 14 '15 at 20:27
  • @AlxVallejo I think they recommend it for production, because they have stable and well written Apachesolr config files to support their Acquia Cloud (shared) Solr instances (that's the only reason I guess) and given that Search API was actively in the development state, so the involved risk included that the config files would need to be updated more often. They recommended it to our (large) project as well, but after a short time of playing around and checking our requirements, we changed their recommendation to Search API. They didn't have stable config files, however we provided our own. – kenorb Jul 16 '15 at 8:48
23

I've tried using both and I can say this: it depends on your situation.

Currently, the stable 7 release of the ApacheSolr Integration module can only index nodes. So if you have non-node entities that you need to index, you have to use the still in progress multientity patch for it. ApacheSolr Integration can store a lot of different data of content when configured properly.

The Search API does index entites and has a lot of wonderful stuff written for it. However, Search API only fetches the id of the data you are searching for. This means to load any more data other than the ID will require an entity_load, hitting your database or whatever caching layer you put in place. For search-heavy sites, this might not be the most optimized solution.

Here is a great presentation given at drupalcon chicago about the ApacheSolr Integration module, minute 16 for mentions to Search API.

  • awesome overview. exactly what I wanted to know. thanks! – hross Nov 15 '11 at 22:25
  • If this successfully answered your question can you please flag it as the answer? Thanks! – LSU_JBob Nov 15 '11 at 22:29
  • 1
    For those of you wondering, multientity is now in the dev branch of apache solr integration, so it should be out with the next beta. – LSU_JBob Dec 28 '11 at 6:15
  • 2
    For those reading this thread.. One mitigating factor on performance is the Search API allows indexing and retrieval of node data now. There is a performance discussion here. – hross Jan 24 '12 at 18:27
  • 1
    This answer is out of date, take a look at drupal.org/node/1999392 search_api_solr now has multisite options, also allows returning of not just the NID. Massive growth in search_api_solr's install base in 2014 overtaking apachesolr's D7 use. – Duncanmoo Dec 11 '14 at 8:15
2

I wouldn't suggest solr for multilingual search. Depends how important the search is multilingual solr search can be really time consuming.

The setup can be painful. For multilingual search your language has to be supported by solr. There are grammatical rules that has to be set for your language. Also you need java and solr installed so you can't use cheap shared hosting.

If you are developing a search engine, you might want to use it. If you are calculating the development resources then Payd google site search might be a better option! I even am a co-maintainer for gss modulep

  • Why is that? Any benchmarks? – giorgio79 Oct 16 '12 at 9:47
  • 1
    Ou I am sorry, I ment the setup can be painful. For multilingual search your language has to be supported by solr. There are grammatical rules that has to be set for your language. Also when I looked into it the modules where in devel status and needed more work to get things working. But it is the fastest search engine. So you have to ask yourself, how important is the search feature for you. Also you need java and solr installed so you can't use cheap shared hosting. – ram4nd Oct 17 '12 at 12:02
  • This --> bitnami.com/stack/solr/installer , makes it fairly easy for Windows users. – coderama May 16 '15 at 8:01
1

I think you really have to try both and make an informed decision. But consider strongly that apachesolr still does not have a beta for Drupal 8.

In Search API you cannot combine entities on the same SearchAPI index. So Profiles, Users, Nodes are on different indexes. There is a module to allow multiindex searches, it did not cover my needs, but YMMV. If you have many content types and many fields on the same index, the index definition can become quite unwieldly. (NB SearchAPI D8 reports to support multi index searching)

Apachesolr allows editing of fields on a per content basis which may be easier, but does not have the ability to add related content to a document, in fact expect to have to write some custom code to include information from field collections, references and some other fields. Apachesolr D7 does not support ajax, unless you use views, but using views you lose facets. That said ... modifying the information stored in the index is fairly easy if you are happy coding in hooks.

The idea of searching for entity ids and then rendering each one individually (can be used by both modules) would seem to be a performance nightmare, but, if you cache your entity displays it might well be more efficient than rendering from the solr response.

0

One of the things that I had to come to Apache Solr compared to Search API was having a multi select filter search. With Search API it seemed impossible. Solr seemed to have this option.

0

I would mention Multi-Site support: SearchAPI does not have multi-site support (using the same SOLR index to store multiple sites contents). Apachesolr, instead allow to: 1. index multiple sistes contentents in the same SOLR index 2. filter the results by a particular site 3. perform a search only on the local site filtering out results from other sites

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.