数据库存储:为什么Pipeline比Feed Export更好？

Question

这是一个关于scrapy的问题.

在数据库中存储项目时,为什么通过管道而不是Feed导出机制实现常规？

Feed Exports - 使用不同的格式和存储输出您的已删除数据

实施刮刀时最常需要的功能之一是能够正确存储刮削数据

项目管道 - 后处理并存储您的已删除数据

项目管道的典型用途是......将已删除的项目存储在数据库中

有什么区别,两者之间的利弊,以及(为什么)管道更合适？

谢谢

Answer 1

这是一个太晚的答案。但我只是花了一整个下午和一个晚上试图了解项目管道和提要导出之间的区别，但记录不充分。我认为这对仍然困惑的人会有所帮助。

TL;DR： FeedExport 旨在将项目导出为文件。它完全不适合数据库存储。

Feed 导出是作为scrapy in 的扩展实现的scrapy.extensions.feedexport。这样，就像scrapy中的其他扩展一样，它依次通过将回调函数注册到一些scrapy信号（open_spider，close_spider和item_scraped）来实现，以便它可以采取必要的步骤来存储项目。

当open_spider, FeedExporter（实际扩展类）初始化提要存储和项目导出器时。具体步骤包括从 a 中获取一个类文件对象，该对象通常是一个临时文件，FeedStroage并将其传递给ItemExporter. 当 时item_scraped，FeedExporter只需将预初始化的ItemExporter对象调用到export_item。当 时close_spider，FeedExporter调用store前一个FeedStorage对象的方法将文件写入文件系统、上传到远程 FTP 服务器、上传到 S3 存储等。

有一组内置的项目导出器和存储。但是正如您从上面的文本中可能注意到的那样，它FeedExporter是设计上与文件存储紧密结合的。使用数据库时，存储项目的常用方法是在它被抓取后立即将其插入数据库（或者您可能需要一些缓冲区）。

因此，使用数据库存储的正确方法似乎是编写自己的FeedExporter. 你可以通过注册回调到scrapy信号来实现它。但不是必须的，使用item pipeline更直接，不需要了解这些实现细节。