深度测试：指定DoC ID对ES写入性能的影响

在[[使用python批量写入ES索引数据]]中已经介绍了如何批量写入ES数据。基于该流程实际测试一下指定文档ID对ES性能的影响有多大。

一句话版

指定ID比不指定ID的性能下降了63%，且加剧趋势。

以下是测评验证的细节。

百万数据量

索引默认使用1分片和1副本。

指定ID写入

执行完写入程序，后台显示耗时：
'Total Time Spent: ', 225.49，据此计算吞吐量为4444/s。

索引速度监控截图显示约4550条每秒：

不指定ID写入

执行完写入程序，后台显示耗时：
'Total Time Spent: ', 214.52，据此计算为4672/s。
后台索引的性能监控显示，写入速度约是4750条每秒，比写ID时略高5%。

千万级数据量

索引创建多个分片

此时我们指定要写入的索引为3个分片，也是1份副本。
代码里添加的内容是：

# 定义要创建的索引及其设置，包括主分片数为3  
create_index_body = {  
    "settings": {  
        "index": {  
            "number_of_shards": 3,  # 设置主分片数为3  
            "number_of_replicas": 1  # 设置副本数为1，可以根据需要调整  
        }  
    }  
} 

# 创建索引  
if not es.indices.exists(index="my_index"):  
    es.indices.create(index="my_index", body=create_index_body) 
1
2
3
4
5
6
7
8
9
10
11
12
13

指定ID

后台显示耗时：
'Total Time Spent: ', 1465.45，据此计算写入速度平均6825/s。
索引速度约6700条每秒。

不指定ID

后台显示耗时：
'Total Time Spent: ', 1434.30，计算为6973/s。
监控趋势展示，约7016条每秒。

优势似乎不明显。
我们继续追加1000万条数据，此时id使用随机生成的字符串。

追加1000万数据

从写入机制考虑，应该原始索引有存量数据才对性能有影响，我们追加写入1000万数据进行验证，且使用随机生成的uuid。

指定文档ID

1000万到2000万：程序耗时1778.45秒。
最终通过ES查询索引元数据观察到索引操作累计耗时是1215秒。
其余的时间多是python程序自身运行的占用。
2000万到3000万：程序耗时1904.99秒；索引累计耗时2026秒。
3000万到4000万：程序耗时1904.99秒；索引累计耗时2026秒。
4000万到5000万：程序耗时1904.99秒；索引累计耗时2026秒。
那么，最后1000万数据实际入库索引速度是11025/s。

不指定文档ID

1000万到2000万：程序耗时1446.72秒；索引操作耗时1112秒。
2000万到3000万：程序耗时1458.31秒；索引累计耗时1672秒。
3000万到4000万：程序耗时1497.03秒；索引累计耗时2232秒。
4000万到5000万：程序耗时1475.83秒；索引累计耗时2788秒。
那么，最后1000万数据的实际索引速度是17985/s。

最终，测试集群已经有一个亿的数据：

统计以上数据趋势看图。

• 不指定ID的运行效率基本恒定
• 指定ID的运行效率逐步下降了约33%

• 索引速度的差距稳步拉开！！

总结

综上，指定ID写入对性能的负面影响随着数据量增长而增大。数据显示在5000万级别性能已损失了63%。

这是虚拟机环境的模拟，具体计算指定ID对性能的影响是复杂的，因为它取决于上述多个因素以及你的软硬件环境。

据ES官方的性能调优指南：在为具有显式 id 的文档编制索引时，Elasticsearch 需要检查同一分区内是否已经存在具有相同 id 的文档，这是一项成本很高的操作，而且随着索引的增加，成本会越来越高。

可以预见的是当索引变大到某一程度时指定ID的性能可能会断崖式下跌而非缓慢下降。

与君共赏

《题西林壁》
  宋·苏轼
横看成岭侧成峰，远近高低各不同。
不识庐山真面目，只缘身在此山中。
1
2
3
4