64 GB 内存的机器是非常理想的, 但是32 GB 和16 GB 机器也是很常见的。少于8 GB 会适得其反(你最终需要很多很多的小机器),大于64 GB 的机器也会有问题,
Elasticsearch 分为两部分,一部分是本身的堆内存,另一部分是lucene使用非堆内存,标准的建议是把 50% 的可用内存作为 Elasticsearch 的堆内存,保留剩下的 50%留给lucene;如果不需要对分词字符串做聚合计算(例如,不需要?fielddata?)可以考虑降低堆内存。堆内存越小,Elasticsearch(更快的 GC)和 Lucene(更多的内存用于缓存)的性能越好。
?由于JVM 在内存小于 32 GB 的时候会采用一个内存对象指针压缩技术,所以分配给 Elasticsearch的内存不要超过 临界值?~32GB,设置堆内存为 31GB 是一个安全的选择。
尽可能使用SSD,?基于 SSD 的节点,查询和索引性能都有提升。ES 服务存储容量的主要因素如下:
副本数量:副本有利于增加数据的可靠性,但同时会增加存储成本。默认和建议的副本数量为1,对于部分可以承受异常情况导致数据丢失的场景,可考虑设置副本数量为0。
数据膨胀:除原始数据外,ES 需要存储索引、列存数据等,在应用编码压缩等技术后,一般膨胀10%。
内部任务开销:ES 占用约20%的磁盘空间,用于 segment 合并、ES Translog、日志等。
操作系统预留:Linux 操作系统默认为 root 用户预留5%的磁盘空间,用于关键流程处理、系统恢复、防止磁盘碎片化问题等。
因此,数据在 ES 中占用的实际空间可通过下面公式估算:
实际空间 = 源数据 × (1 + 副本数量) × (1 + 数据膨胀) / (1 - 内部任务开销) / (1 - 操作系统预留)≈ 源数据 × (1 + 副本数量) × 1.45
为保证服务的稳定运行,建议至少预留15%的存储空间,因此建议申请的存储容量为:
存储容量 = 源数据 × (1 + 副本数量) × 1.45 × (1 + 预留空间)
≈ 源数据 × (1 + 副本数量) × 1.67
每个 ES 索引被分为多个分片,数据按哈希算法打散到不同的分片中。由于索引分片的数量影响读写性能、故障恢复速度,且通常无法轻松更改,需要提前考虑。这里给出配置分片数量的一些常用建议:
建议单个分片大小保持在10GB - 50GB之间,您可以据此初步确定 Index 的分片数量。分片不宜过大或过小:过大可能使 ES 的故障恢复速度变慢;过小可能导致非常多的分片,但因为每个分片使用一些数量的 CPU 和内存,从而导致读写性能、内存不足等问题。
当分片数量超过数据节点数量时,建议分片数量接近数据节点的整数倍,方便分片在所有数据节点均匀分布。