新人使用Elasticsearch可以轻松上手,快速构建高可用集群。当第一个Elasticsearch集群建成后,几分钟就可以实现索引和搜索。但是,对于生产环境集群,必须注意几个问题:
-
有多大把握让集群稳定运行?
-
集群的吞吐量是多少?
-
集群性能如何?
-
集群中是否有足够的可用资源,它们是否易于扩展和维护?
-
集群大小合适吗?
每个人在新项目、新架构部署时都应该思考这些问题。在本文中,我们将深入讨论上面提到的性能、ES集群规模问题。并提供一套方法和建议,帮助你确定ES集群的规模,并对环境进行基准测试。
无论我们定义什么样的系统架构,我们都需要对用例以及我们提供的功能有一个清晰的理解,架构也可能受到现有硬件的约束,比如现有的硬件、公司的全球战略等诸多约束。这些都是我们在规模试验中需要考虑的因素。
一、硬件资源如何分配
性能取决于Elasticsearch执行什么任务,在什么平台上运行。对于每个搜索或索引操作,都涉及到以下资源:
1、磁盘存储
-
建议尽可能使用 SSD,特别是那些运行搜索和索引操作的节点。由于 SSD 存储的成本较高,建议使用热温架构来减少支出。
-
在裸机上操作时,本地磁盘才是王道!
-
Elasticsearch 不需要冗余存储(无需 RAID 1/5/10),日志和指标用例通常至少有一个副本分片,这是确保容错性的最低要求,同时又能最大限度地减少写入次数。
2、内存
-
JVM:存储关于集群、索引、分片、段和 Fielddata 的元数据。该项较为理想的设置是可用 RAM 的 50%。
-
OS Cache:Elasticsearch 将使用剩余的可用内存来缓存数据,避免在全文搜索、对文档值执行聚合和排序期间多次读取磁盘,从而实现性能的极大提升。
3、CPU
Elasticsearch 节点具有线程池和线程队列,它们会使用可用的计算资源。在 Elasticsearch 中,CPU 核心的数量和性能决定着数据操作的平均速度和峰值吞吐量。
4、网络
网络性能—带宽和延迟会影响节点之间的通信和集群之间的功能,如跨集群搜索和跨集群复制。
二、根据数据量确定集群规模
对于指标和日志用例,通常要管理大量的数据。因此,根据数据量初步确定Elasticsearch的聚类规模是有意义的。在测试开始时,需要考虑以下问题:
-
每天将索引多大量的原始数据 (GB)
-
数据保留多久
-
在 hot tier 存储多久