Drupal - Search API vs. Apache Solr Search

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.


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:

  • When does the core Drupal search module is worth using?
  • What are the advantages of using Apache Solr over the core search module?

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.

Tags:

Search

Recent Posts