elasticsearch为什么搜索快

elasticsearch为什么搜索快

首先ES是基于Lucene这个非常成熟的索引方案，另加上一些分布式的实现：集群，sharding，replication等。

ES的优势主要可以看以下几个方面：
1. 横向可扩展性：只需要增加一台服务器，做一点儿配置，启动一下ES进程就可以并入集群；
2. 分片机制提供更好的分布性：同一个索引分成多个分片（sharding），这点类似于HDFS的块机制；分而治之的方式来提升处理效率，相信大家都不会陌生；
3. 高可用：提供复制（replica）机制，一个分片可以设置多个复制，使得某台服务器宕机的情况下，集群仍旧可以照常运行，并会把由于服务器宕机丢失的复制恢复到其它可用节点上；这点也类似于HDFS的复制机制（HDFS中默认是3份复制）；

当然，也要知道其不足之处：
1. 各节点的一致性问题：其默认的机制是通过多播机制，同步元数据信息，但是在比较繁忙的集群中，可能会由于网络的阻塞，或者节点处理能力达到饱和导致各节点元数据不一致——也就是所谓的脑裂问题，这样会使集群处于不一致状态。目前并没有一个彻底的解决方案来解决这个问题，但是可以通过将工作节点与元数据节点分开的部署方案来缓解这种情况。

2. 没有细致的权限管理机制，也就是说，没有像MySQL那样的分各种用户，每个用户又有不同的权限。所以在操作上的限制需要自己开发一个系统来完成；

总结：不过从优势与不足的对比看，我看还是瑕不掩瑜，是值得一试的技术。

对比性能其实很不好回答，因为没有我还不知道有 benchmark做了很深入的，而且没有偏见的性能对比。 就实时搜索而言(near real time search), feature 实现主要是lucene layer. elasticsearch 比 solr 提前实现这个feature。但是现在solr 也进步了不少，性能差别并没有很大，毕竟底层都是用lucene 和jvm的嘛。 但是因为实现不一样，feature 和 feature 之前性能差别肯定也还是有的。但是不同的use case，性能对比结果也是不一样。而且两个产品都有很多参数可以调试， 结果也就更不一样了。 就我个人的理解，毕竟 elasticsearch 是2010 年后 才出现的项目，设计和实现上也更加考究，也更容易上手。 solr的主要问题是直到 solr cloud, 一直并没有 很好的scale 和 做分布式的办法。solrcloud release之后 bug 又很多。 加之就 elastic 这个产品 stack 而言，search engine 是一块基石。本身产品内部设计架构强调模块化，使得用户很容易在上面搭建自己的扩展插件 (aws plugin 啥的)。然后 kibana前台ui 和 logstash 又给产品找来了很多眼球。我想这是elasticsearch 现在更流行的原因吧。