Elasticsearch技术方案选型的10个注意点
极客时间编辑部
讲述：丁婵大小：2.46M时长：05:23
目前，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. 检索选型
Elasticsearch 查询 DSL 非常庞大。如果业务场景不需要计算评分，推荐使用过滤器 filter。检索选型前，建议通过 Demo 验证一下是否符合预期。了解如何编写高效查询是一回事，但让它们返回最终用户期望的结果是另一回事。业务实战中，建议花一些时间调整分析器、分词和评分，以便 ES 返回期望正确的命中。
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 可以查看日志文件或其他输入，然后有效地将数据索引到集群中。
以上就是今天的内容，在选型中，建议综合对比性能和稳定性，找适合自己业务场景的最重要。
原文链接：http://t.cn/EMUZw6N
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
卡斯瓦德elk或者说elkk一般用于监控的话，filter应该就够了，如果是用于检索，可能dsl产生的score就是过不去的坎，至于监控，其实可以按时间将不需要的数据去除，不如24小时内保留1分钟，7天内保留15分钟，1月内保留1个小时，再过长就1天几个封顶，当然了这样对于事故追溯会有点影响，感觉elk主要就是数据大数据检索速度快1
收起评论