ElasticSearch与Solr Cloud对比

智联平台组

原理

Lucene

Lucene 查询原理

ES

基础
elasticsearch之mapping配置
ELK集群核心概念、mapping、查询等介绍

在某种意义上，ES是schemaless的， 在索引doc的时候， 直接指定index/type就可以了，无需对index/type进行任何的设定。实际上， 在index/type被创建的时候，ES会去猜json里面的字段，然后自动生成一份mapping(mapping是对doc中， 各字段的类型的定义， 及索引方式等的解析)。
一旦有了mapping， 就变成schema的了，doc里面已有的字段类型 就不能随意更改了。

架构及原理

Elasticsearch集群搭建及参数详解

Elasticsearch内核解析 - 数据模型篇
Elasticsearch内核解析 - 写入篇
Elasticsearch内核解析 - 查询篇

从Elasticsearch来看分布式系统架构设计

从架构原理上来看，我们需要关注几个方面的工作模式
1. 角色部署方式，是混合部署还是分层部署（Data node和TranserNode）
2.

索引

Elasticsearch－基础介绍及索引原理分析

从设计上，ES在Lunce基础之上，重点还做了

• 分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。
• 实时分析的分布式搜索引擎。
• 可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。

核心思路是：

将磁盘里的东西尽量搬进内存，减少磁盘随机读取次数(同时也利用磁盘顺序读特性)，结合各种奇技淫巧的压缩算法，用及其苛刻的态度使用内存。

需要注意的是：

• 不需要索引的字段，一定要明确定义出来，因为默认是自动建索引的
• 同样的道理，对于String类型的字段，不需要analysis的也需要明确定义出来，因为默认也是会analysis的
• 选择有规律的ID很重要，随机性太大的ID(比如java的UUID)不利于查询

集群

Elasticsearch分布式集群工作原理简介

从用户的角度来看，主节点在ElasticSearch中并没有占据着重要的地位，这与其它的系统(比如数据库系统)是不同的。实际上用户并不需要知道哪个节点是主节点；所有的操作需求可以分发到任意的节点，ElasticSearch内部会完成这些让用户感到不明觉历的工作。在必要的情况下，任何节点都可以并发地把查询子句分发到其它的节点，然后合并各个节点返回的查询结果。最后返回给用户一个完整的数据集。所有的这些工作都不需要经过主节点转发(节点之间通过P2P的方式通信)。

Elasticsearch分布式一致性原理剖析(一)-节点篇
Elasticsearch分布式一致性原理剖析(二)-Meta篇
Elasticsearch分布式一致性原理剖析(三)-Data篇

前人经验

Elasticsearch之es学习工作中遇到的坑（陆续更新）

ES调优
常规基础优化措施
<漫谈ElasticSearch>关于ES性能调优几件必须知道的事
ＥＳ优化总结
elasticsearch三个重要的优化
亿级规模的Elasticsearch优化实战
elasticsearch 性能调优

Solr Cloud

架构及原理

SolrCloud原理介绍
SolrCloud原理（很全面）
SolrCloud初识

SolrCloud相比Solr而言，有了很多的新特性，保证了整个Solr应用的High Availability。

1、集中式的配置信息  使用ZK进行集中配置。启动时可以指定把Solr的相关配置文件上传Zookeeper，多机器共用。这些ZK中的配置不会再拿到本地缓存，Solr直接读取ZK中的配置信息。另外配置文件的变动，所有机器都可以感知到， Solr的一些任务也是通过ZK作为媒介发布的，目的是为了容错，这使得Solr接收到任务，但在执行任务时崩溃的机器，在重启后，或者集群选出候选者时，可以再次执行这个未完成的任务。  
2、SolrCloud对索引分片，并对每个分片创建多个Replication。每个Replication都可以对外提供服务。一个Replication挂掉不会影响索引服务，更强大的是，SolrCloud还能自动的在其它机器上帮你把失败机器上的索引Replication重建并投入使用。  
3、近实时搜索：立即推送式的replication（也支持慢推送），可以在秒内检索到新加入索引。  
4、查询时自动负载均衡：SolrCloud索引的多个Replication可以分布在多台机器上，均衡查询压力，如果查询压力大，可以通过扩展机器，增加Replication来减缓。 
5、自动分发的索引和索引分片：发送文档到任何节点，SolrCloud都会转发到正确节点。 
6、事务日志：事务日志确保更新无丢失，即使文档没有索引到磁盘。  

除此之外，SolrCloud中还提供了其它一些特色功能：

1、可将索引存储在HDFS上  
2、通过MR批量创建索引  
3、强大的RESTful API  
优秀的管理界面：主要信息一目了然，可以清晰的以图形化方式看到SolrCloud的部署分布，当然还有不可或缺的Debug功能。

问题

solr性能问题【翻译】

调优
Solr性能调优
如何大幅优化solr的查询性能(转)
solr查询优化（实践了一下效果比较明显）

一些案例

基于solrcloud大数据平台日志管理系统的设计与实现
基于Solr的多表join查询加速方法

Solr 与 ES 比较

Solr&ElasticSearch原理及应用
ElasticSearch与Solr搜索引擎特性对比

建议

首先从原理上来说，ES和solr都是基于lucene的，所以从本质上来说二者并没有明显的区别，在相关的性能评测中也各有输赢，这是我的了解；
其次，ES相比solr从我们使用来看，ES更多的是用于日志分析或类似复杂SQL查询的场景，因为ES相比solr提供了很多aggragation相关的聚合查询功能，相应的功能如果solr实现的话，会相对比较复杂，灵活性也不够高。ES灵活性虽然高，但很多功能是基于内存计算来实现的，并不是lucene原生支持的，所以对内存和CPU的占用肯定比普通的非聚合类的查询要高；

所以我之前的经验上，用法基本上是ES用于一些离线准实时的日志分析场景，接受偶尔的超时；solr主要用于线上的OLTP类业务，性能上有一定的保证。

而且，我们目前的使用场景，对于ES的Schema-less，还是有一定的依赖的。（这种依赖可能还行，但优化起来会比较麻烦）

如果只是测试，可能目前的场景度不好
1. ES本身就是schema-less的，但Solr需要一定的Schema优化。
2. Solr大部分使用场景都是查询多而写相对少的，ES更注重实时性。
但Solr在数据量稍小的情况下，性能又由于ES。
3. Solr的性能优化，有时候是需要业务端参与的。

这样，很容易出现结果看上去可行，但事实上方案并不可行（如果已经有ES了）。

而且，我们是用到了比较多的ES里面的聚合查询吗？如果用的话，迁移到solr里面成本还是不低的

我的想法是还是要先定位下究竟是哪类查询超时多，如果是因为ES特有的用法超时多的话，迁到solr可能会有提高，但这种提高应该是solr本身限制查询用法造成的。也就是说原来在ES里面方便能查的现在在solr里面查不了了，因为不支持。。。而为了用solr就必须改为solr支持的方式，也就是用lucene支持的比较好的方式，这样性能肯定会有提升。同样的，如果不用solr，而是把ES里面的也进行类似的优化，ES应该也不差。