Apache Solr vs Elasticsearch

Posted 朝晖

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Apache Solr vs Elasticsearch相关的知识,希望对你有一定的参考价值。

http://solr-vs-elasticsearch.com/

Apache Solr vs Elasticsearch

The Feature Smackdown


API

FeatureSolr 6.2.1ElasticSearch 5.0
Format XML, CSV, JSON JSON
HTTP REST API 技术分享 技术分享
Binary API 技术分享 技术分享 SolrJ 技术分享 TransportClient, Thrift (through a plugin)
JMX support 技术分享 技术分享 ES specific stats are exposed through the REST API
Official client libraries 技术分享 Java Java, Groovy, php, Ruby, Perl, Python, .NET, javascript Official list of clients
Community client libraries 技术分享 PHP, Ruby, Perl, Scala, Python, .NET, Javascript, Go, Erlang, Clojure Clojure, Cold Fusion, Erlang, Go, Groovy, Haskell, Java, JavaScript, .NET, OCaml, Perl, PHP, Python, R, Ruby, Scala, Smalltalk, Vert.x Complete list
3rd-party product integration (open-source)技术分享 Drupal, Magento, Django, ColdFusion, Wordpress, OpenCMS, Plone, Typo3, ez Publish, Symfony2, Riak (via Yokozuna) Drupal, Django, Symfony2, Wordpress, CouchBase
3rd-party product integration (commercial)技术分享 DataStax Enterprise Search, Cloudera Search, Hortonworks Data Platform, MapR SearchBlox, Hortonworks Data Platform, MapR etc Complete list
Output技术分享 JSON, XML, PHP, Python, Ruby, CSV, Velocity, XSLT, native Java JSON, XML/html (via plugin)

Infrastructure

FeatureSolr 6.2.1ElasticSearch 5.0
Master-slave replication 技术分享 Only in non-SolrCloud. In SolrCloud, behaves identically to ES. 技术分享 Not an issue because shards are replicated across nodes.
Integrated snapshot and restore Filesystem Filesystem, AWS Cloud Plugin for S3 repositories, HDFS Plugin for Hadoop environments, Azure Cloud Plugin for Azure storage repositories

Indexing

FeatureSolr 6.2.1ElasticSearch 5.0
Data Import DataImportHandler - JDBC, CSV, XML, Tika, URL, Flat File [DEPRECATED in 2.x] Rivers modules - ActiveMQ, Amazon SQS, CouchDB, Dropbox, DynamoDB, FileSystem, Git, GitHub, Hazelcast, JDBC, JMS, Kafka, LDAP, MongoDB, neo4j, OAI, RabbitMQ, Redis, RSS, Sofa, Solr, St9, Subversion, Twitter, Wikipedia
ID field for updates and deduplication 技术分享 技术分享
DocValues 技术分享 技术分享 技术分享
Partial Doc Updates 技术分享 技术分享 with stored fields 技术分享 with _source field
Custom Analyzers and Tokenizers 技术分享 技术分享 技术分享
Per-field analyzer chain 技术分享 技术分享 技术分享
Per-doc/query analyzer chain 技术分享 技术分享 技术分享
Index-time synonyms 技术分享 技术分享 技术分享 Supports Solr and Wordnet synonym format
Query-time synonyms 技术分享 技术分享 especially via hon-lucene-synonyms 技术分享 Technically, yes, but practically no because multi-word/phrase query-time synonyms are not supported. See ES docs and hon-lucene-synonyms blog for nuances.
Multiple indexes 技术分享 技术分享 技术分享
Near-Realtime Search/Indexing 技术分享 技术分享 技术分享
Complex documents 技术分享 技术分享 技术分享
Schemaless 技术分享 技术分享 4.4+ 技术分享
Multiple document types per schema 技术分享 技术分享 One set of fields per schema, one schema per core 技术分享
Online schema changes 技术分享 技术分享 Schemaless mode or via dynamic fields. 技术分享 Only backward-compatible changes.
Apache Tika integration 技术分享 技术分享 技术分享
Dynamic fields 技术分享 技术分享 技术分享
Field copying 技术分享 技术分享 技术分享 via multi-fields
Hash-based deduplication 技术分享 技术分享 技术分享 Murmur plugin or ER plugin

Searching

FeatureSolr 6.2.1ElasticSearch 5.0
Lucene Query parsing 技术分享 技术分享 技术分享
Structured Query DSL 技术分享 技术分享 Need to programmatically create queries if going beyond Lucene query syntax. 技术分享
Span queries 技术分享 技术分享 via SOLR-2703 技术分享
Spatial/geo search 技术分享 技术分享 技术分享
Multi-point spatial search 技术分享 技术分享 技术分享
Faceting 技术分享 技术分享 技术分享 Top N term accuracy can be controlled with shard_size
Advanced Faceting 技术分享 技术分享 New JSON faceting API as of Solr 5.x 技术分享 blog post
Geo-distance Faceting 技术分享 技术分享
Pivot Facets 技术分享 技术分享 技术分享
More Like This 技术分享 技术分享
Boosting by functions 技术分享 技术分享 技术分享
Boosting using scripting languages 技术分享 技术分享 技术分享
Push Queries 技术分享 技术分享JIRA issue 技术分享 Percolation. Distributed percolation supported in 1.0
Field collapsing/Results grouping 技术分享 技术分享 技术分享
Query Re-Ranking 技术分享 技术分享 技术分享 via Rescoring or a plugin
Index-based Spellcheck 技术分享 技术分享 技术分享 Phrase Suggester
Wordlist-based Spellcheck 技术分享 技术分享 技术分享
Autocomplete 技术分享 技术分享
Query elevation 技术分享 技术分享 技术分享workaround
Intra-index joins 技术分享 技术分享 via parent-child query 技术分享 via has_children and top_children queries
Inter-index joins 技术分享 技术分享 Joined index has to be single-shard and replicated across all nodes. 技术分享
Resultset Scrolling 技术分享 技术分享 New to 4.7.0 技术分享 via scan search type
Filter queries 技术分享 技术分享 技术分享 also supports filtering by native scripts
Filter execution order 技术分享 技术分享 local params and cache property 技术分享
Alternative QueryParsers 技术分享 技术分享 DisMax, eDisMax 技术分享 query_string, dis_max, match, multi_match etc
Negative boosting 技术分享 技术分享 but awkward. Involves positively boosting the inverse set of negatively-boosted documents. 技术分享
Search across multiple indexes 技术分享 it can search across multiple compatible collections 技术分享
Result highlighting 技术分享 技术分享
Custom Similarity 技术分享 技术分享 技术分享
Searcher warming on index reload 技术分享 技术分享 技术分享 Warmers API
Term Vectors API 技术分享 技术分享

Customizability

FeatureSolr 6.2.1ElasticSearch 5.0
Pluggable API endpoints 技术分享 技术分享 技术分享
Pluggable search workflow 技术分享 技术分享 via SearchComponents 技术分享
Pluggable update workflow 技术分享 技术分享 via UpdateRequestProcessor 技术分享
Pluggable Analyzers/Tokenizers 技术分享 技术分享
Pluggable QueryParsers 技术分享 技术分享 技术分享
Pluggable Field Types 技术分享 技术分享
Pluggable Function queries 技术分享 技术分享
Pluggable scoring scripts 技术分享 技术分享
Pluggable hashing 技术分享 技术分享 技术分享
Pluggable webapps 技术分享 技术分享 技术分享 [site plugins DEPRECATED in 5.x] blog post
Automated plugin installation 技术分享 技术分享 技术分享 Installable from GitHub, maven, sonatype or elasticsearch.org

Distributed

FeatureSolr 6.2.1ElasticSearch 5.0
Self-contained cluster 技术分享 技术分享 Depends on separate ZooKeeper server 技术分享 Only Elasticsearch nodes
Automatic node discovery 技术分享 ZooKeeper 技术分享 internal Zen Discovery or ZooKeeper
Partition tolerance 技术分享 The partition without a ZooKeeper quorum will stop accepting indexing requests or cluster state changes, while the partition with a quorum continues to function. 技术分享 Partitioned clusters can diverge unless discovery.zen.minimum_master_nodes set to at least N/2+1, where N is the size of the cluster. If configured correctly, the partition without a quorum will stop operating, while the other continues to work. See this
Automatic failover 技术分享 If all nodes storing a shard and its replicas fail, client requests will fail, unless requests are made with the shards.tolerant=true parameter, in which case partial results are retuned from the available shards. 技术分享
Automatic leader election 技术分享 技术分享
Shard replication 技术分享 技术分享
Sharding 技术分享 技术分享 技术分享
Automatic shard rebalancing 技术分享 技术分享 技术分享 it can be machine, rack, availability zone, and/or data center aware. Arbitrary tags can be assigned to nodes and it can be configured to not assign the same shard and its replicates on a node with the same tags.
Change # of shards 技术分享 Shards can be added (when using implicit routing) or split (when using compositeId). Cannot be lowered. Replicas can be increased anytime. 技术分享 each index has 5 shards by default. Number of primary shards cannot be changed once the index is created. Replicas can be increased anytime.
Shard splitting 技术分享 技术分享
Relocate shards and replicas 技术分享 技术分享 can be done by creating a shard replicate on the desired node and then removing the shard from the source node 技术分享 can move shards and replicas to any node in the cluster on demand
Control shard routing 技术分享 技术分享 shards or _route_ parameter 技术分享 routing parameter
Pluggable shard/replica assignment 技术分享 Rule-based replica assignment 技术分享 Probabilistic shard balancing with Tempest plugin
Consistency Indexing requests are synchronous with replication. A indexing request won‘t return until all replicas respond. No check for downed replicas. They will catch up when they recover. When new replicas are added, they won‘t start accepting and responding to requests until they are finished replicating the index. Replication between nodes is synchronous by default, thus ES is consistent by default, but it can be set to asynchronous on a per document indexing basis. Index writes can be configured to fail is there are not sufficient active shard replicas. The default is quorum, but all or one are also available.

Misc

FeatureSolr 6.2.1ElasticSearch 5.0
Web Admin interface 技术分享 bundled with Solr 技术分享 Marvel or Kibana apps
Visualisation Banana (Port of Kibana) Kibana
Hosting providers WebSolrSearchifyHosted-SolrIndexDepotOpenSolrgotosolr FoundObjectRocketbonsai.ioIndexistoqbox.ioIndexDepotCompose.ioSematext Logsene


Thoughts...

I‘m embedding my answer to this "Solr-vs-Elasticsearch" Quora question verbatim here:

1. Elasticsearch was born in the age of REST APIs. If you love REST APIs, you‘ll probably feel more at home with ES from the get-go. I don‘t actually think it‘s ‘cleaner‘ or ‘easier to use‘, but just that it is more aligned with web 2.0 developers‘ mindsets.

2. Elasticsearch‘s Query DSL syntax is really flexible and it‘s pretty easy to write complex queries with it, though it does border on being verbose. Solr doesn‘t have an equivalent, last I checked. Having said that, I‘ve never found Solr‘s query syntax wanting, and I‘ve always been able to easily write a custom SearchComponent if needed (more on this later).

3. I find Elasticsearch‘s documentation to be pretty awful. It doesn‘t help that some examples in the documentation are written in YAML and others in JSON. I wrote a ES code parser once to auto-generate documentation from Elasticsearch‘s source and found a number of discrepancies between code and what‘s documented on the website, not to mention a number of undocumented/alternative ways to specify the same config key. 

By contrast, I‘ve found Solr to be consistent and really well-documented. I‘ve found pretty much everything I‘ve wanted to know about querying and updating indices without having to dig into code much. Solr‘s schema.xml and solrconfig.xml are *extensively* documented with most if not all commonly used configurations. 

4. Whilst what Rick says about ES being mostly ready to go out-of-box is true, I think that is also a possible problem with ES. Many users don‘t take the time to do the most simple config (e.g. type mapping) of ES because it ‘just works‘ in dev, and end up running into issues in production. 

And once you do have to do config, then I personally prefer Solr‘s config system over ES‘. Long JSON config files can get overwhelming because of the JSON‘s lack of support for comments. Yes you can use YAML, but it‘s annoying and confusing to go back and forth between YAML and JSON. 

5. If your own app works/thinks in JSON, then without a doubt go for ES because ES thinks in JSON too. Solr merely supports it as an afterthought. ES has a number of nice JSON-related features such as parent-child and nested docs that makes it a very natural fit. Parent-child joins are awkward in Solr, and I don‘t think there‘s a Solr equivalent for ES Inner hits.

6. ES doesn‘t require ZooKeeper for it‘s ‘elastic‘ features which is nice coz I personally find ZK unpleasant, but as a result, ES does have issues with split-brain scenarios though (google ‘elasticsearch split-brain‘ or see this: Elasticsearch Resiliency Status).

7. Overall from working with clients as a Solr/Elasticsearch consultant, I‘ve found that developer preferences tend to end up along language party lines: if you‘re a Java/c# developer, you‘ll be pretty happy with Solr. If you live in Javascript or Ruby, you‘ll probably love Elasticsearch. If you‘re on Python or PHP, you‘ll probably be fine with either. 

Something to add about this: ES doesn‘t have a very elegant Java API IMHO (you‘ll basically end up using REST because it‘s less painful), whereas Solrj is very satisfactory and more efficient than Solr‘s REST API. If you‘re primarily a Java dev team, do take this into consideration for your sanity. There‘s no scenario in which constructing JSON in Java is fun/simple, whereas in Python its absolutely pain-free, and believe me, if you have a non-trivial app, your ES json query strings will be works of art. 

8. ES doesn‘t have in-built support for pluggable ‘SearchComponents‘, to use Solr‘s terminology. SearchComponents are (for me) a pretty indispensable part of Solr for anyone who needs to do anything customized and in-depth with search queries. 

Yes of course, in ES you can just implement your own RestHandler, but that‘s just not the same as being able to plug-into and rewire the way search queries are handled and parsed. 

9. Whichever way you go, I highly suggest you choose a client library which is as ‘close to the metal‘ as you can get. Both ES and Solr have *really* simple search and updating search APIs. If a client library introduces an additional DSL layer in attempt to ‘simplify‘, I suggest you think long and hard about using it, as it‘s likely to complicate matters in the long-run, and make debugging and asking for help on SO more problematic. 

In particular, if you‘re using Rails + Solr, consider using rsolr/rsolr
instead of sunspot/sunspot if you can help it. ActiveRecord is complex code and sufficiently magical. The last thing you want is more magic on top of that. 

---

To conclude, ES and Solr have more or less feature-parity and from a feature standpoint, there‘s rarely one reason to go one way or the other (unless your app lives/breathes JSON). Performance-wise, they are also likely to be quite similar (I‘m sure there are exceptions to the rule. ES‘ relatively new autocomplete implementation, for example, is a pretty dramatic departure from previous Lucene/Solr implementations, and I suspect it produces faster responses at scale).

ES does offer less friction from the get-go and you feel like you have something working much quicker, but I find this to be illusory. Any time gained in this stage is lost when figuring out how to properly configure ES because of poor documentation - an inevitablity when you have a non-trivial application. 

Solr encourages you to understand a little more about what you‘re doing, and the chance of you shooting yourself in the foot is somewhat lower, mainly because you‘re forced to read and modify the 2 well-documented XML config files in order to have a working search app.

---

EDIT on Nov 2015: 

ES has been gradually distinguishing itself from Solr when it comes to data analytics. I think it‘s fair to attribute this to the immense traction of the ELK stack in the logging, monitoring and analytic space. My guess is that this is where Elastic (the company) gets the majority of its revenue, so it makes perfect sense that ES (the product) reflects this.

We see this manifesting primarily in the form of aggregations, which is a more flexible and nuanced replacement for facets. Read more about aggregations here: Migrating to aggregations

Aggregations have been out for a while now (since 1.4), but with the recently released ES 2.0 comes pipeline aggregations, which let you compute aggregations such as derivatives, moving averages, and series arithmetic on the results of other aggregations. Very cool stuff, and Solr simply doesn‘t have an equivalent. More on pipeline aggregations here: Out of this world aggregations

If you‘re currently using or contemplating using Solr in an analytics app, it is worth your while to look into ES aggregation features to see if you need any of it.



Resources



Contribute

If you see any mistakes, or would like to append to the information on this webpage, you can clone the GitHub repo for this site with:

git clone https://github.com/superkelvint/solr-vs-elasticsearch

and submit a pull request.



Popular books related to Search

技术分享
 
技术分享
 
技术分享
 
技术分享
 
技术分享
 
技术分享
 
技术分享
 
技术分享
 
技术分享 技术分享 技术分享 技术分享

 


以上是关于Apache Solr vs Elasticsearch的主要内容,如果未能解决你的问题,请参考以下文章

Apache Solr vs Elasticsearch-feature

搜索引擎SOLR VS Elasticsearch(2019技术选型参考)

Apache-solr

Elasticsearch VS Solr

lucene vs solr 评分

日期出现在Accumulo vs Solr吗?