Elasticsearch技术选型方案的10个注意点

【序】elasticsearch具有的快速和高效的即时索引查询优势特点，已经越来越多的使用在很多生产环境下，像电商、车联网、Ai、大数据、高速计算已经成为平台系统的必备组件之一。

目前，Elasticsearch 被广泛使用，也越来越受到欢迎。这不单单是因为它的典型特征，比如易于部署、无需额外的软件即可扩展到数百个节点、内置 RESTful API、上手快、开源、更新快、社区活跃等。更重要的是 Elastic 已经形成了包含 Elasticsearch、logstash、kibana、Beats 等的 Elastic Stack 一体化解决方案。
Metaversant 创始人 Jeff Potts 以 15 年国外经典博客的框架为线索，剔除过时的技术体系、技术栈内容，结合近千万级业务场景和最新 Elastic 技术洞察梳理出 Elasticsearch 方案选型必须了解的 10 件事。
1. 集群规模
Elasticsearch 的优点在于它非常容易扩展，但索引和查询时间可能因许多因素而异。在集群规模层面一方面要考虑数据量，另一方面比较重要的衡量因素是项目 / 产品的指标要求。
要想达到吞吐量和 CPU 利用率的指标要求，建议进行一定量的测试，以确认集群承担的负载和性能瓶颈问题。
2. 节点职责
Elasticsearch 节点可以是主节点（Master），数据节点（Data），客户端 / 路由节点（Client）或某种组合。 许多开发者大规模集群选择专用主节点（至少 3 个），然后选择一些数据和客户端节点。对此，建议职责分离，并针对特定工作负载优化每种类型的节点的分配。
3. 安全
近期，未加任何安全防护措施的 Elastic 安全事件频发。建议在应用程序 API 和 Elasticsearch 层之间以及 Elasticsearch 层和内部网络之间保护 Elasticsearch 集群。
4. 数据建模
在进行数据建模时，建议业务层面使用别名进行检索、聚合操作。这样做的好处是将应用和索引名称隔离，也可以方便的实现跨索引检索。另外，针对数据类型选型，若不指定数据类型的动态映射机制，建议根据业务场景需求，静态的手动指定好每个字段的数据类型。
考虑因素包含但不限于：
是否需要索引； 是否需要存储； 是否需要分词； 是否需要多表关联（nested 类型、join 或者是宽表存储）
是否需要快速响应（keyword 和 long 类型选型）
5. 检索选型
请务必考虑一个完全独立的“监视”集群机制，该机制仅用于捕获有关群集运行状况的统计信息，并在出现问题时提醒开发者。监控的作用是能通过可视化的方式，直观的看到内存、JVM、CPU、负载、磁盘等的使用情况，以对可能的突发情况及早做出应对方案。警报的作用就是异常实时预警。
6. 监控和警报
请务必考虑一个完全独立的“监视”集群机制，该机制仅用于捕获有关群集运行状况的统计信息，并在出现问题时提醒开发者。监控的作用是能通过可视化的方式，直观的看到内存、JVM、CPU、负载、磁盘等的使用情况，以对可能的突发情况及早做出应对方案。警报的作用就是异常实时预警。
7. 节点配置和配置管理
一旦拥有多个节点，就每个节点在软件版本、配置等方面保持同步变得具有挑战性。有许多开源工具可以帮助解决这个问题，比如 Chef 和 Ansible 帮助管理 Elasticsearch 集群。
8. 备份和恢复
对于高可用性的业务系统，数据的备份功能非常重要，它可以恢复误删除的数据。 由于数据的存储可能会涉及多个节点，依赖 OS 级文件系统备份可能会很冒险。推荐使用 Elasticsearch 内置的“ 快照”功能，可以备份索引。
9.API 选型
Elastic 官方支持 API 包含 JAVA、JavaScript、PHP、Python 等等，民间 API（社区贡献）也非常庞大，包括 C++、Go 等 20 多种。对于 API 选型，推荐使用官方 API。因为其版本更新及时、新特性支持适配更新及时。此外，DSL 开发推荐使用的 Kibana 的 Dev-tool，非常高效、方便。
10. 数据接入
将数据索引到 Elasticsearch 很容易。 根据数据源和其他因素，开发者可以自己编写，也可以使用 Elastic 中的 Logstash 工具。Logstash 可以查看日志文件或其他输入，然后有效地将数据索引到集群中。

在选型中，建议综合对比性能和稳定性，找适合自己业务场景的最重要。