Elasticsearch 技术选型，Elasticsearch 面试题

题记

Elasticsearch 目前被广泛使用，也越来越受到欢迎。一些传统的行业甚至婚庆公司都已经在使用Elasticsearch。
人们喜欢Elasticsearch，不单单因为它的典型特征：

1、易于部署；
2、无需额外的软件即可扩展到数百个节点；
3、内置RESTful API，上手快；
4、开源+更新快+社区相当活跃。

更重要的是Elastic已经形成了包含Elasticsearch、logstash、kibana、Beats等的Elastic Stack一体化解决方案。

在大家使用Elasticsearch作为备用选型方案期间，被问到最多的问题之一是：

Elasticsearch作为解决方案需要注意什么？

本文以15年国外经典博客的框架为线索，剔除过时的技术体系、技术栈内容，结合近千万级业务场景和最新Elastic技术洞察重新梳理出：Elasticsearch方案选型必须了解的10件事。

1、集群规模

Elasticsearch的优点在于它是非常容易扩展。但，索引和查询时间可能因许多因素而异。在集群规模层面一方面要考虑数据量，另一方面比较重要的衡量因素是项目/产品的指标要求。

要想达到吞吐量和CPU利用率的指标要求，建议进行一定量的测试，以确认集群承担的负载和性能瓶颈问题。

测试工具推荐：Apache Jmeter。

网上会有很多的一线互联网公司等的“他山之石”，但，方案仅供参考，需要自己结合业务场景、硬件资源进行反复测试验证。

2、节点职责

Elasticsearch节点可以是主节点（Master），数据节点（Data），客户端/路由节点（Client）或某种组合。 大多数人大规模集群选择专用主节点（至少3个），然后选择一些数据和客户端节点。

建议：职责分离，并您针对特定工作负载优化每种类型的节点的分配。

例如，通过分离客户端和数据节点提升性能。 客户端节点处理传入的HTTP请求，这使得数据节点为查询提供服务。

这并不是绝对的，有大量网友在社区反馈，分离客户端节点并没有提升性能，因实际场景而异，大规模数据增量的业务场景，职责分离必然是大势所趋。

3、安全

近期，未加任何安全防护措施的Elastic安全事件频发。建议在应用程序API和Elasticsearch层之间以及Elasticsearch层和内部网络之间保护您的Elasticsearch集群。

1、6.3+版本之后，xpack插件已经集成到Elastic产品线。（收费）
2、加一层Nginx代理，能防止未经授权的访问。
3、其他选型推荐：search-guard，readonlyRest等。

“裸奔的风险非常大”，进阶阅读：你的Elasticsearch在裸奔吗？

4、数据建模

4.1 使用别名

业务层面使用别名进行检索、聚合操作。

别名的好处：
1、将应用和索引名称隔离；
2、可以方便的实现跨索引检索。

4.2 数据类型选型

若不指定数据类型的动态映射机制，比如：字符串类型会默认存储为text和keyword两种类型，势必会增加存储成本。
建议：针对业务场景需求，静态的手动指定好每个字段的数据类型。

考虑因素包含但不限于：
1、是否需要索引；
2、是否需要存储；
3、是否需要分词；
4、是否需要聚合；
5、是否需要多表关联（nested类型、join或者是宽表存储）；
6、是否需要快速响应（keyword和long类型选型）
……
此处的设计时间不能省。

5、检索选型

Elasticsearch查询DSL非常庞大。如果业务场景不需要计算评分，推荐使用过滤器filter。因为基于缓存，更高效。
查询相关的API包含但不限于：

• match/multi_match
• match_phrase/match_phrase_prefix
• term/terms
• wildcard/regexp
• query_string

选型前，建议通过Demo验证一下是否符合预期。

了解如何编写高效查询是一回事，但让它们返回最终用户期望的结果是另一回事。

业务实战中，建议花一些时间调整分析器、分词和评分，以便ES返回期望的正确的命中。

6、监控和警报

请务必考虑一个完全独立的“监视”集群机制，该机制仅用于捕获有关群集运行状况的统计信息，并在出现问题时提醒您。

监控作用：能通过可视化的方式，直观的看到内存、JVM、CPU、负载、磁盘等的使用情况，以对可能的突发情况及早做出应对方案。

警报作用：异常实时预警。

ES6.X xpack已经集成watcher工具。它会监视某些条件，并在满足这些条件时提醒您。

举例：当某些状态（例如JVM堆）达到阈值时，您可以采取一些操作（发送电子邮件，调用Web钩子等）。

如果你的业务场景是：几乎实时地将数据写入Elasticsearch并希望在数据与某些模式匹配时收到警报，则推荐使用ElastAlert。

https://github.com/Yelp/elastalert

7、节点配置和配置管理

一旦拥有多个节点，就每个节点在软件版本、配置等方面保持同步变得具有挑战性。

有许多开源工具可以帮助解决这个问题。推荐：Chef和Ansible帮助管理Elasticsearch集群。

Ansible可以自动执行升级和配置传播，而无需在任何Elasticsearch节点上安装任何其他软件。

当前可能看不到对自动化的巨大需求，如果要从小规模开始发展，并且希望能够快速发展的话，一个使用Ansible编写的常见任务库可以使你在几分钟内从裸服务器转到完全配置的Elasticsearch节点，无需人工干预。

增量索引的管理推荐：rollover + curator + crontab，6.6版本的新特性：Index Lifecycle Management(索引生命周期管理），推荐尝鲜使用。

8、备份和恢复

经常被问到的问题1“ES中误删除的数据（delete或者delete_by_query）能恢复吗？”
——答案：如果做了备份，是可以的。如果没有，不可以。

问题2：“迁移节点，直接data路径原封不动拷贝可以吗？”
——答案：不可以，不推荐。推荐使用reindex或其他工具实现。

对于高可用性的业务系统，数据的备份功能非常重要。 由于数据的存储可能会涉及多个节点，依赖OS级文件系统备份可能会很冒险。

推荐使用Elasticsearch内置的“快照”功能，可以备份您的索引。

9、API选型

Elastic官方支持API，包含：JAVA、Java Script、.net、PHP、python、Ruby。
Elastic民间API（社区贡献）非常庞大：C++、Go等20多种。

API选型推荐使用：官方API。

原因：
1）版本更新及时、
2）新特性支持适配更新及时。

http://t.cn/EMUzubT

http://t.cn/EMUzubH

DSL开发推荐使用的Kibana的Dev-tool，非常高效、方便。

10、数据接入

将数据索引到Elasticsearch很容易。 根据数据源和其他因素，您可以自己编写，也可以使用Elastic中的Logstash工具。

Logstash可以查看日志文件或其他输入，然后有效地将数据索引到集群中。

其他大数据组件或开源项目也有类似的功能，举例：

kafka-connector，flume，canal等。

选型中，不一棵树上吊死，综合对比性能和稳定性，找适合自己业务场景的最为重要。

小结

安装和运行开箱即用的Elasticsearch集群非常简单。 使其适用于你的实际业务场景并满足你的性能指标非常不容易。

希望这个列表能助力你的Elastic方案选型，为选型扫清障碍。

期待反馈交流心得！

参考：http://t.cn/EMUZw6N