Bug描述
self.docstore.get_all_document_hashes()
方法在 _handle_upserts
方法中非常耗时。
但它的返回值仅在 UPSERTS_AND_DELETE 情况下使用。
llama_index/llama-index-core/llama_index/core/ingestion/pipeline.py
第429行:| existing_doc_ids_before=set(self.docstore.get_all_document_hashes().values()) |
版本
0.10.50.post1
重现步骤
抱歉,我不能在这里分享代码。
但基本上遵循以下步骤:
- 使用 doc_store、cache 和 vector_store 创建一个 Ingestion Pipeline,并使用 UPSERTS 策略
- 准备大量文档,在我的情况下为 1.5k+
- 使用 pipeline run 加载所有文档
- 获取一个新文档,并仅使用 pipeline run 加载新文档。
由于 doc_store 中已经有 1.5k+ 个文档,因此get_all_document_hashes
方法将根据 doc store 后端变得非常慢或非常昂贵。
在我的情况下,我使用了 DynamoDB doc_store 和 S3KVStore 支持的 KVDocStore:
在 DynamoDB 的情况下,它需要进行全表扫描
在 S3 后端的情况下,它需要7分钟才能获取所有哈希值。
但这是完全不必要的,因为在 UPSERT 操作期间,我们不需要获取所有文档。
为了解决这个问题,我实现了自己的 doc_store 类,该类从get_all_document_hashes
方法返回空字典,整个管道可以正常工作且性能更好。
1条答案
按热度按时间ggazkfy81#
嘿@headyin!我在这里帮助你解决任何bug、问题或贡献。让我们一起解决这个问题!
为了解决
_handle_upserts
方法中UPSERTS策略期间昂贵的self.docstore.get_all_document_hashes()
调用问题,你可以优化函数,只在每个节点的基础上获取必要的文档哈希值。这可以避免预先获取所有文档哈希值,后端如DynamoDB和S3KVStore可能会特别慢。以下是
_handle_upserts
函数的优化版本:这种方法确保只为每个节点获取必要的文档哈希值,从而避免了昂贵的
self.docstore.get_all_document_hashes()
1(https://github.com/run-llama/llama_index/blob/main/llama-index-legacy/llama_index/legacy/ingestion/pipeline.py)2(https://github.com/run-llama/llama_index/blob/main/llama-index-core/llama_index/core/ingestion/pipeline.py)调用。