ElasticSearch同类产品有：1、Lucene；2、Solr；3、RDBMS；4、OpenTSDB；5、HBase。其中，Lucene 是一个搜索的核心库，Elastic 也是在 Lucene 基础之上构建，它们之间的竞争关系是由 Lucene 本身决定的。
一、ElasticSearch同类产品
1、Lucene
Lucene 是一个搜索的核心库，Elastic 也是在 Lucene 基础之上构建，它们之间的竞争关系是由 Lucene 本身决定的。
在互联网 2.0 时代，考验各互联网公司最简单的技术要求，就是看他们的搜索做的怎么样，那时大家的做法几乎一样，都基于 Lucene 核心库构建一套搜索引擎，剩下的就看各公司的开发者们的水平。笔者有幸在 2012 年之前，基于 Lucene 做过垂直行业的搜索引擎，遇到很多问题有必要说一下：
- 项目基于 Lucene 包装，业务代码与核心库一起构建发布，代码耦合度很高，每次有数据字段变更，都需要重新编译打包发布，这个过程非常的繁琐，且相当危险。
- 程序重新发布，需要关闭原有的程序，涉及到进程切换问题。
- 索引数据定期全量重新生成，也涉及到新旧索引切换，索引实时刷新等问题，都需要设计一套复杂的程序机制保障
- 每个独立业务线需求，都需要单独构建一个 Lucene 索引进程，业务线多了之后，管理是个麻烦的事情
- 当单个 Lucene 索引数据超过单实例限制之后，需要做分布式，这个原有 Lucene 是没有办法的，所以常规的做法也是按照某特定分类，拆分成多个索引进程，客户端查询时带上特定分类，后端根据特定分类路由到具体的索引。
- Lucene 库本身的掌控难度，对于功力尚浅的开发工程师，需要考虑的因素实在太多了，稍微不慎，就会出现很大的程序问题。
2、Solr
Solr 是名列前茅个基于 Lucene 核心库功能完备的搜索引擎产品，诞生远早于 Elasticsearch，早期在全文搜索领域，Solr 有非常大的优势，几乎完全压倒 Elastic，在近几年大数据发展时代，Elastic 由于其分布式特性，满足了很多大数据的处理需求，特别是后面 ELK 这个概念的流行，几乎完全忘记了 Solr 的存在，虽然也推出了 Solr-Coud 分布式产品，但已经基本无优势。
接触过几个数据类公司，全文搜索都基于 Solr 构建，且是单节点模式，偶然出现一些问题，找咨询顾问排查问题，人员难找，后面都迁移到 Elasticsearch 之上。
现在市面上几乎大大小小公司都在使用 Elasticsearch，除了老旧系统有的基于 Solr 的，新系统项目应该全部是 Elasticsearch。
个人认为有以下几个原因：
- ES 比 Solr 更加友好简洁，门槛更低。
- ES 比 Solr 产品功能特点更加丰富，分片机制，数据分析能力。
- ES 生态发展，Elastic-stack 整个技术栈相当全，与各种数据系统都很容易集成。
- ES 社区发展更加活跃，Solr 几乎没有专门的技术分析大会。
3、RDBMS
关系型数据库与 Elasticsarch 相比主要优点是事务隔离机制无可替代，但其局限性很明显，如下：
- 关系型数据库查询性能，数据量超过百万级千万级之后下降厉害，本质是索引的算法效率不行，B+树算法不如倒排索引算法高效。
- 关系型数据库索引最左原则限制，查询条件字段不能任意组合，否则索引失效，相反 Elasticserach 可以任意组合，此场景在数据表关联查询时特别明显，Elasticsearch 可以采用大宽表解决，而关系型数据库不能。
- 关系型数据库分库分表之后多条件查询，难于实现，Elasticsearch 天然分布式设计，多个索引多个分片皆可联合查询。
- 关系型数据库聚合性能低下，数据量稍微多点，查询列基数多一点性能下降很快，Elasticsearch 在聚合上采用的是列式存储，效率极高。
- 关系型数据库侧重均衡性，Elasticsearch 侧重专一查询速度。
4、OpenTSDB
OpenTSDB 内部基于 HBase 实现，属于时间序列数据库，主要针对具有时间特性和需求的数据，进行过数据结构的优化和处理，从而适合存储具有时间特性的数据，如监控数据、温度变化数据等，小米公司开源监控体系 open-falcon 的就是基于 OpenTSDB 实现。
5、HBase
HBase 是列式数据库的代表，其内部有几个致命设计大大限制了它的应用范围：
- 访问 HBase 数据只能基于 Rowkey，Rowkey 设计的好坏直接决定了 HBase 使用优劣。
- 本身不支持二级索引，若要实现，则需要引入第三方。
关于其各种技术原理就不多说了，说说它的一些使用情况。
公司所属物流速运行业，一个与车辆有关的项目，记录所有车辆行驶轨迹，车载设备会定时上报车子的轨迹信息，后端数据存储基于 HBase，数据量在几十 TB 级以上，由于业务端需要依据车辆轨迹信息计算它的公里油耗以及相关成本，所以要按查询条件批量查询数据，查询条件有一些非 rowkey 的字段，如时间范围，车票号，城市编号等，这几乎无法实现，原来暴力的做过，性能问题堪忧。此项目的问题首先也在于 rowkey 难设计满足查询条件的需求，其次是二级索引问题，查询的条件很多。
如果用列式数据库仅限于 Rowkey 访问场景，其实采用 Elastic 也可以，只要设计好 _id，与 HBase 可以达到相同的效果。
如果用列式数据库查询还需要引入三方组件，那还不如直接在 Elasticsearch 上构建更直接。
除非对使用列式数据库有非常苛刻的要求，否则 Elasticsearch 更具备通用性，业务需求场景适用性更多。
延伸阅读：
二、MongoDB是什么
MongoDB 是文档型数据库的代表，数据模型基于 Bson，而 Elasticsearch 的文档数据模型是 Json，Bson 本质是 Json 的一种扩展，可以相互直接转换，且它们的数据模式都是可以自由扩展的，基本无限制。MongoDB 本身定位与关系型数据库竞争，支持严格的事务隔离机制，在这个层面实际上与 Elasticsearch 产品定位不一样，但实际工作中，几乎没有公司会将核心业务数据放在 MongoDB 上，关系型数据库依然是名列前茅选择。
