Solr vs. Elasticsearch: Who’s the Leading Open Source Search Engine?
This post compares Solr and ElasticSearch. Some of their functionality is similar, but there are great differences in terms of their ease of deployment and scalability.
Join the DZone community and get the full member experience.Join For Free
more than ever, this is the time of cloud and data growth. today’s applications generate data in petabytes and zettabytes while everyone still demands faster and faster performance. however, as the data piles up, searching through all of that information effectively quickly becomes a substantial back end challenge.
in this post, i will compare two of the most popular open source search engines: solr and elasticsearch. both were built on top of the apache lucene open source platform, so several of their functionalities are very similar. however, there are great differences in terms of ease of deployment, scalability, and other functionalities as well.
about apache solr
apache solr is an open source search platform built on a java library called lucene. it offers apache lucene’s search capabilities in a user-friendly way. having been an industry player for almost a decade, it is a mature product with a strong and broad user community. it offers distributed indexing, replication, load-balanced querying, and automated failover and recovery. if it is deployed correctly and then managed well, it’s capable of becoming a highly reliable, scalable, and fault-tolerant search engine. quite a few internet giants such as netflix, ebay, instagram, and amazon (cloudsearch) use solr because of its ability to index and search multiple sites.
the major feature list includes:
- full-text search
- faceted search
- real-time indexing
- dynamic clustering
- database integration
- nosql features and rich document handling (word and pdf files, for example)
elasticsearch is an open source (apache 2 license), distributed, restful search engine built on top of the apache lucene library .
the distributed search engine includes indices that can be divided into shards, and each shard can have multiple replicas. each elasticsearch node can have one or more shards, and its engine also acts as a coordinator to delegate operations to the correct shard(s).
elasticsearch is scalable with near real-time search. one of its key features is multi-tenancy.
the major feature list includes:
- distributed search
- an analyzer chain
- analytical search
- grouping & aggregation
before we begin, let’s check google trends for both products. google trends shows that elasticsearch has a great traction in comparison to solr, but that does not mean that apache solr is dead. although some might think otherwise, solr is still one of the most popular search engines with a robust community and open source support.
installation and configuration
elasticsearch is easy to install and very lightweight compared to solr. the current version (6.2.0) of solr’s distribution package size is around 150 mb while the current version (2.4.0) of elasticsearch distribution package size is only 26.1 mb. in addition, you can install and run elasticsearch within a few minutes.
however, this ease of deployment and use can become a problem if elasticsearch is not managed well. the json-based configuration is easy but if you want to specify comments for each and every configuration inside the file, then it is not for you.
the latest version of solr provides a good set of rest apis that remove the complexities in the previous versions such as when creating custom sharded collections via a collections api, documenting clustering algorithms, and doing custom sharding. overall, if your app is using json, then elasticsearch is a better option. otherwise, use solr since its schema.xml and solrconfig.xml are very well documented.
indexing and searching
solr accepts data from different sources including xml files, comma-separated-value (csv) files, and data extracted from tables in a database as well as common file formats such as microsoft word and pdf. elasticsearch also accepts data from many different sources such as activemq, aws sqs, dynamodb (amazon nosql), filesystem, git, jdbc, jms, kafka, ldap, mongodb, neo4j, rabbitmq, redis, solr, and twitter. there are various plugins available as well.
solr is much more oriented towards text search, while elasticsearch is often used for analytical querying, filtering, and grouping. the team behind elasticsearch is always trying to make these queries more efficient (through methods including the lowering of memory footprint and cpu usage) and improve performance at both the lucene and elasticsearch levels. when comparing both, it’s clear that elasticsearch is a better choice for applications that require not only text search but also complex time series search and aggregations.
both search engines use various analyzers and tokenizers that break up text into terms or tokens that are then indexed. elasticsearch allows you to specify the query analyzer chain, which is comprised of a sequence of analyzers or tokenizers on a per-document or per-query basis. this helps when you have multiple analyzers attached so that the output of one analyzer becomes the input of a second analyzer. in contrast, solr does not support this feature.
you can index both search engines while simultaneously using stopwords and synonyms to match documents. in solr , the join index has to be a single-shard and replicated across all nodes to search inter-document relationships (such as sql joins, for example). in the case of elasticsearch, you can retrieve such related documents using has_children and top_children queries that make it more efficient. this helps to find the parent documents that have child documents that match the criteria. according to some performance tests , elasticsearch may tend to produce better results than solr in terms of indexing.
scalable and distributed
search engines have to deal with large systems with millions of documents. for that matter, the search engines should be replicable, modular, and scalable enough to allow clustering and distributed architecture.
designed for the cloud
elasticsearch is simple to scale and attracts use cases where large clusters are required. solr—in its elasticsearch-like fully distributed solrcloud deployment mode—depends on apache zookeeper . although zookeeper is mature and widely used, it’s ultimately an entirely separate application. solrcloud is designed to provide a highly available, fault-tolerant environment for distributing indexed content and query requests across multiple servers. with solrcloud, data is organized into multiple pieces—shards—that can be hosted on multiple machines. the replicas will help to achieve redundancy as well as scalability and fault-tolerance.
in comparison, elasticsearch has a built-in, zookeeper-like component called zen that uses its own internal coordination mechanism to handle the cluster state. zookeeper is better at preventing inconsistent states from arising due to the split-brain problem in elasticsearch clusters . since elasticsearch is easy to start in a cluster and designed for the cloud, it would be the preferred choice as long as the inconsistent state issue is handled well.
shard splitting and rebalancing
shards are the partitioning unit for the lucene index, and both solr and elasticsearch use them. you can distribute your index by running shards on different machines in a cluster. until a couple of years ago, neither database allowed you to change the number of shards in your index—so if you wanted to add new shards to your existing setup, it was not permitted and you had to do a completely new setup. with the introduction of solrcloud , solr started supporting shard splitting, which allows you to add more shards by splitting existing shards. in comparison, elasticsearch still does not support this and, in fact, actually discourages the practice.
if you have done proper capacity planning, you will know your future growth and the resulting needs for your elasticsearch machines. by adding more machines to your setup, you can use the automatic shard-balancing feature within elasticsearch. this will also help solve the shard-splitting issue.
to prepare your current machine for future sharding and the addition of more machines, you should have multiple shards in the current machines by splitting your index based on the estimated number of future machines required. the advantage is that each machine will have multiple shards, and when you add new machines, elasticsearch will automatically balance the load and move shards to new nodes in the cluster. this automatic shard-rebalancing behavior is not available in solr.
in comparison, solr allows shards to be added (when using implicit routing) or split (when using composite id), but shards cannot be removed. it does allow you to increase the replicas.
in elasticsearch, each index has five shards by default. it does not allow you to change the number of primary shards, but it does allow you to increase the number of replicas. automatic shard rebalancing is useful for horizontal scaling. when a new machine is added, it will automatically rebalance the shards that are available with different machines.
solr has a broad, open-source community. anyone can contribute to solr, and new solr developers or code committers are elected based on merit only. elasticsearch is technically open-source but not fully. all contributors have access to the source code, and users can make changes and contribute them. but final changes are confirmed and done by employees of elastic (the company that runs elasticsearch and other software). therefore, elasticsearch is driven more by a single company rather than a whole community.
solr contributors and committers span multiple organizations while elasticsearch committers are from elastic only. it’s also been observed that solr’s strong community has a healthy project pipeline and many well-known companies that take part. these members also invest in the platform by contributing throughout the entire development and engineering process.
both have great user bases as well as rich developer communities, but elasticsearch is newer in comparison to solr. solr has been around for a much longer period of time, so its ecosystem is well-developed and has a larger user base.
solr scores big here. it is a very well-documented product with clear examples and contexts for api use cases. elasticsearch’s documentation is organized, but it lacks good examples and clear configuration instructions.
for elasticsearch, some examples are written in yaml and some are in json. a number of discrepancies between the code and what is documented on the website have also been observed.
in comparison, solr is consistent and very well-documented. without going deep into code, you can learn much more about indices, sharding, and searching.
so, solr or elasticsearch?
sometimes it’s tough to identify a clear winner. whether you select solr or elasticsearch, you first need to understand your proper use case and future needs. to summarize each of their attributes:
- elasticsearch is more popular among newer developers due to its ease of use. but if you are already used to working with solr, you should stay with it because there is no specific advantage of migrating to elasticsearch.
- if you need to handle analytical queries in addition to searching text, elasticsearch is the better choice.
- if you need distributed indexing, then you need to choose elasticsearch. elasticsearch is the better option for cloud and distributed environments that need good scalability and performance
in summary, both are feature-rich search engines and more or less give the same performance as long as they are designed and implemented well.
Published at DZone with permission of Asaf Yigal, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.