Elasticsearch对垒8大竞品技术，谁强谁弱？

青出于蓝，而胜于蓝。

入行Elastic-Stack技术栈很久很久，为了免于知识匮乏眼光局限，有必要到外面的世界看看，丰富自己的世界观。本篇内容从Elastic的竞争产品角度分析探讨。

哪些应用场景下使用Elasticsearch最佳?

哪些应用场景下不使用Elasticsearch最好?

本文仅代表个人的观点，不代表社区技术阵营观点，无意口水之争，限于本人的经验知识有限，可能与读者观点认知不一致。

竞争产品

Elasticseach从做搜索引擎开始，到现在主攻大数据分析领域，逐步进化成了一个全能型的数据产品，在Elasticsearch诸多优秀的功能中，与很多数据产品有越来越多的交叉竞争，有的功能很有特色，有的功能只是附带，了解这些产品特点有助于更好的应用于业务需求。

Lucene是一个搜索的核心库，Elastic也是在Lucene基础之上构建，它们之间的竞争关系是由Lucene本身决定的。

在互联网2.0时代，考验各互联网公司最简单的技术要求，就是看他们的搜索做的怎么样，那时大家的做法几乎一样，都基于Lucene核心库构建一套搜索引擎，剩下的就看各公司的开发者们的水平。笔者有幸在2012年之前，基于Lucene做过垂直行业的搜索引擎，遇到很多问题有必要说一下：

项目基于Lucene包装，业务代码与核心库一起构建发布，代码耦合度很高，每次有数据字段变更，都需要重新编译打包发布，这个过程非常的繁琐，且相当危险。

程序重新发布，需要关闭原有的程序，涉及到进程切换问题。

索引数据定期全量重新生成，也涉及到新旧索引切换，索引实时刷新等问题，都需要设计一套复杂的程序机制保障

每个独立业务线需求，都需要单独构建一个Lucene索引进程，业务线多了之后，管理是个麻烦的事情

当单个Lucene索引数据超过单实例限制之后，需要做分布式，这个原有Lucene是没有办法的，所以常规的做法也是按照某特定分类，拆分成多个索引进程，客户端查询时带上特定分类，后端根据特定分类路由到具体的索引。

Lucene库本身的掌控难度，对于功力尚浅的开发工程师，需要考虑的因素实在太多了，稍微不慎，就会出现很大的程序问题。

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!