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 可以查看日志文件或其他输入,然后有效地将数据索引到集群中。

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

发表评论

电子邮件地址不会被公开。 必填项已用*标注