1. 问题描述

在调用LightRAG的/graph/entity/edit接口，进行百万级节点数据更新的时候，出现了更新一段时间后降速的问题，上传速度从0.1秒/条，降速到2秒/条。查看日志发现是每上传几条后，后端显示：

lightrag  | DEBUG: [] Inserting 1 records to entity_chunks
lightrag  | DEBUG: [] Process 1 KV writting 313606 records to entity_chunks

其中313606正是LightRAG挂载的KV文件kv_store_entity_chunks.json中节点数！更新 1 个实体，触发了 全量重写。怀疑是每次更新时，程序读取整个文件 → 修改内存中的 1 条数据 → 把整个文件写回磁盘。导致上传速度受限于磁盘读写，变得特别慢。以前只进行了上传操作，没有遇到过这个情况。

2. 原因及解决方案

前期工作开展时，未考虑在后续大量数据节点的情况下的数据维护，图省事配置KV存储方式为json，在LightRAG的配置文件.env中有如下配置：

LIGHTRAG_KV_STORAGE=JsonKVStorage
LIGHTRAG_DOC_STATUS_STORAGE=JsonDocStatusStorage

可能就是这个原因导致了更新节点时回去全量重写。

修改为Redis存储：

LIGHTRAG_KV_STORAGE=RedisKVStorage
LIGHTRAG_DOC_STATUS_STORAGE=RedisDocStatusStorage

REDIS_URI=redis://xxxx:xxxx
REDIS_SOCKET_TIMEOUT=30
REDIS_CONNECT_TIMEOUT=10
REDIS_MAX_CONNECTIONS=100
REDIS_RETRY_ATTEMPTS=3

启动了一个没有配置密码的Redis容器，将IP和端口信息写入.env中，重新启动了一个新的LightRAG容器，此时容器会自动进行数据迁移，等待一段时间后启动成功，此时再去上传更新数据，速度就很稳定了，也不会出现突然全量重写的情况。

或许大概解决了这个问题吧。以后部署这些数据库的时候，要考虑清楚以后的维护情况，不然中途修改还是太刺激了。新启动的LightRAG还需要进一步测试验证其功能都正常。