1. 从“能爬到”到“能用上”结构化存储到底卡在哪很多人学爬虫卡点根本不在“怎么把网页抓下来”。请求库用熟了、解析库写顺了真正让人头疼的是下一步抓下来的东西怎么存我见过太多人爬了一堆数据最后全塞进一个 txt 文件里字段之间用逗号或者竖线硬拼等到要分析的时候才发现——数据里本身就有逗号一拆就乱或者存成 JSON结果几万条数据每次读取都要全量加载内存直接爆掉。这就是“数据结构化存储”要解决的问题。它不是一个新工具而是一整套思路把爬虫抓到的、半结构甚至无结构的原始内容按照预先设计好的字段和类型落到一个能被查询、能被更新、能被程序稳定读取的容器里。这个容器可以是关系型数据库可以是文档数据库也可以是一张规整的 CSV 表关键不在于用什么而在于“结构”二字——字段清晰、类型明确、关系可追溯。这一章我打算把这件事讲透。适合两类人看一类是刚学完请求和解析、正准备把数据落地的爬虫新手另一类是用过数据库但没系统想过“爬虫场景下该怎么设计存储”的开发者。我会从存储方案怎么选、表结构怎么设计、批量写入怎么提速、去重怎么做、增量更新怎么处理这几个角度把我在实际项目里踩过的坑和总结出来的做法都摊开讲。全程不堆概念只讲能直接抄去用的东西。2. 先想清楚存什么再决定往哪存2.1 三种主流存储方案的适用边界爬虫数据的结构化存储绕不开三类选择关系型数据库、文档型数据库、文件型存储。它们不是谁替代谁的关系而是各自有明确的适用场景。选错了后面每一步都别扭。关系型数据库典型代表是 SQLite、MySQL、PostgreSQL。它的核心优势是强 schema——建表时字段和类型就定死了写入时不符合结构的数据直接报错。这对爬虫来说其实是好事因为爬虫最怕的就是数据脏。你抓了一万条商品信息结果有三百条价格字段是空的、两百条标题里混进了 HTML 标签如果没有强约束这些脏数据会悄悄混进去等到分析时才发现返工成本极高。关系型数据库还天然支持事务、索引、联表查询适合字段固定、需要复杂查询的场景比如电商商品、招聘岗位、房产信息这类。文档型数据库典型代表是 MongoDB。它不要求固定 schema每条记录可以有不同的字段。这听起来很自由但自由是有代价的——查询和聚合会比 SQL 麻烦一些而且容易因为字段不统一导致后期数据难以对齐。它适合什么场景字段经常变、嵌套结构复杂的情况。比如你爬的是某个内容平台的帖子有的帖子有图片、有的有视频、有的有投票结构差异很大硬塞进关系表就得建一堆关联表这时候文档库就舒服很多。文件型存储主要是 CSV 和 JSON Lines。CSV 适合最终交付给非技术人员、或者要导入 Excel 做分析的场景JSON Lines每行一个 JSON 对象适合作为爬虫的中间落地格式写入快、追加方便、不怕程序中断。但文件存储的硬伤是不支持并发写、不支持按条件查询、数据量大了之后检索效率极低。所以我的建议是——文件存储只做“临时中转”或“最终导出”不要拿它当主存储。下面这张表可以帮你快速判断存储类型适合的数据特征查询能力写入速度典型场景关系型数据库字段固定、需要关联查询强中等商品、岗位、房产文档型数据库字段多变、嵌套结构中等较快帖子、评论、日志CSV / JSONL结构简单、一次性导出无极快中间落地、数据交付2.2 为什么我优先推荐从 SQLite 起步新手最容易犯的错是一上来就装 MySQL、配用户权限、开远程连接结果光环境就折腾半天爬虫本身还没写几行。我的建议很直接本地开发和小规模爬取先用 SQLite。SQLite 是一个文件型的关系数据库不需要单独启动服务Python 标准库自带sqlite3模块一行import就能用。它同样支持建表、索引、事务、SQL 查询语法和 MySQL 高度相似。你用它把整套存储逻辑跑通等数据量真的上来了、需要多进程并发写了再把建表语句和写入逻辑平移到 MySQL改动量非常小。注意SQLite 的并发写入能力很弱同一时刻只允许一个写操作。如果你的爬虫是多线程或多进程同时写库SQLite 会频繁报database is locked。这种情况下要么改成单线程写入、要么换 MySQL。2.3 字段设计爬虫表结构最容易忽略的三件事建表看起来简单但爬虫场景有几个特殊点新手经常忽略。第一一定要留一个“原始数据”字段。不管你解析出多少结构化字段都建议额外存一列原始 HTML 或原始 JSON。原因很简单解析规则是会变的。今天你按某个 CSS 选择器提取价格明天对方页面改版了你发现之前存的价格全是错的但原始数据还在就能重新解析一遍不用重新爬。这一列可以设成 TEXT 类型存压缩后的内容也行。第二时间字段要区分“发布时间”和“抓取时间”。很多人只存一个时间结果分不清这条数据是内容本身的时间还是你抓到它的时间。增量爬取时你需要用“抓取时间”来判断哪些是新的做数据分析时你又需要“发布时间”。两个都要有类型用 DATETIME 或时间戳整数。第三给去重字段加唯一索引。爬虫最怕重复数据同一个页面被爬了两次、或者列表页翻页时出现重叠都会导致重复入库。解决办法是找一个能唯一标识这条记录的字段比如商品 ID、文章 URL 的哈希值给它建 UNIQUE 索引写入时用INSERT OR IGNORESQLite或INSERT IGNOREMySQL重复数据自动跳过不用在代码里手动判断。3. 建表与写入把数据稳稳落进库里3.1 一张爬虫表的完整建表示例光说原则不够直接看一张实际能用的表。假设我们爬的是某类商品信息字段包括标题、价格、链接、发布时间、抓取时间、原始数据CREATE TABLE IF NOT EXISTS products ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, price REAL, url TEXT NOT NULL, url_hash TEXT NOT NULL UNIQUE, publish_time DATETIME, crawl_time DATETIME DEFAULT CURRENT_TIMESTAMP, raw_data TEXT ); CREATE INDEX IF NOT EXISTS idx_publish_time ON products(publish_time);这里有几个设计点值得说。url_hash是对 URL 做哈希后的值用它做唯一索引而不是直接用 URL是因为 URL 可能很长索引长文本效率低哈希后固定长度查询更快。price用 REAL 而不是 TEXT是为了后面能做数值比较和排序。crawl_time设了默认值插入时不用手动传数据库自动填当前时间。publish_time单独建了索引因为增量爬取时经常要按这个字段筛选。3.2 批量写入为什么逐条插入是性能杀手新手写存储最常见的写法是循环里一条一条INSERT。数据量小的时候没感觉一旦上万条速度慢到让人怀疑人生。原因在于每次INSERT都是一次独立的事务数据库要写磁盘、更新索引、提交事务开销极大。正确的做法是批量写入。SQLite 用executemanyMySQL 用executemany或拼多值INSERT。核心思路是把多条记录攒成一个批次一次性提交。实测下来批量写入比逐条插入快几十倍甚至上百倍。import sqlite3 conn sqlite3.connect(spider.db) cursor conn.cursor() # 假设 items 是一个字典列表 items [ {title: 商品A, price: 19.9, url: http://example.com/a, url_hash: hash_a}, {title: 商品B, price: 29.9, url: http://example.com/b, url_hash: hash_b}, ] sql INSERT OR IGNORE INTO products (title, price, url, url_hash) VALUES (:title, :price, :url, :url_hash) cursor.executemany(sql, items) conn.commit() conn.close()INSERT OR IGNORE配合url_hash的唯一索引重复数据会被自动忽略不会报错中断。这一点在增量爬取时特别有用——你不需要先查一遍数据库判断是否存在直接写让数据库帮你挡重复。3.3 事务与提交什么时候 commit 最合适批量写入时commit的时机很关键。如果你每写一条就 commit 一次等于没批量如果你攒了一万条才 commit中途程序崩了这一万条全丢。我的经验是按批次 commit批次大小控制在 500 到 1000 条。这样既保证了写入效率又不会因为一次崩溃丢失太多数据。另外写入过程中如果某条数据格式有问题比如价格字段传了个字符串进去整批可能都会失败。稳妥的做法是在批量写入前做一次数据清洗把明显不合规的记录挑出来单独处理不要让一条脏数据拖垮整批。提示SQLite 默认每次操作都会自动开启事务用executemany时它会自动包裹在一个事务里。如果你手动控制事务记得在批量写入前BEGIN写完后COMMIT出错时ROLLBACK。4. 去重、增量与更新让存储经得起反复跑4.1 去重的三个层次与选择去重这件事不同层次的做法成本差别很大。最粗的一层是按 URL 去重。同一个 URL 只抓一次这是最基本的。实现方式就是上面说的唯一索引。但问题是很多网站同一个内容会有多个 URL带不同参数、不同分页路径按 URL 去重挡不住。第二层是按业务主键去重。比如商品有商品 ID文章有文章 ID这个 ID 在网站内部是唯一的用它去重比 URL 准。但前提是你能从页面里稳定提取到这个 ID。第三层是按内容指纹去重。把标题、正文等关键字段拼起来做哈希内容相同就认为是重复。这一层最彻底但计算成本也最高而且容易误伤——两篇标题相同但内容不同的文章会被误判。我的建议是优先用业务主键没有业务主键再用 URL内容指纹只在特殊场景下用。4.2 增量爬取怎么知道哪些是新的增量爬取的核心问题是这次跑怎么只抓上次之后新增的内容有两种常见思路。一种是基于时间。记录上次爬取的最后发布时间这次只抓发布时间晚于这个值的内容。这要求目标网站的内容列表是按时间排序的而且你能拿到准确的发布时间。优点是逻辑简单缺点是如果网站时间格式不统一、或者有内容被重新编辑导致时间变化就会漏抓或重复抓。另一种是基于已存 ID 集合。先把数据库里已有的 ID 全部读出来放进一个集合爬列表页时遇到 ID 已在集合里的就跳过。这种方式不依赖时间更可靠但每次都要把全量 ID 加载到内存数据量特别大时比如上百万条会占不少内存。折中方案是只加载最近一段时间的 ID或者用布隆过滤器做概率性判断。实际项目里我通常两种结合先用时间做粗筛减少列表页的翻页量再用 ID 集合做精筛确保不重复入库。4.3 数据更新已存在的记录要不要覆盖有些场景下数据是会变的。比如商品价格今天 19.9明天可能变成 29.9。这时候你需要的不是“跳过重复”而是“更新已有记录”。SQLite 和 MySQL 都支持UPSERT语法。SQLite 用INSERT ... ON CONFLICT ... DO UPDATEMySQL 用INSERT ... ON DUPLICATE KEY UPDATE。以 SQLite 为例INSERT INTO products (title, price, url, url_hash, crawl_time) VALUES (:title, :price, :url, :url_hash, CURRENT_TIMESTAMP) ON CONFLICT(url_hash) DO UPDATE SET price excluded.price, crawl_time excluded.crawl_time;excluded是 SQLite 的关键字代表“本次想要插入的那条记录”。这段 SQL 的意思是如果 url_hash 已存在就把价格和抓取时间更新成新值。这样你既能保留历史记录的唯一性又能让价格保持最新。但要注意如果你需要保留价格变化的历史就不能直接覆盖而应该单独建一张价格变更表每次变化追加一条记录。这属于数据建模的范畴取决于你的分析需求。5. 从 SQLite 到 MySQL什么时候该换、怎么换5.1 触发迁移的三个信号SQLite 不是不能用在大数据量上但它有几个明确的瓶颈。当你遇到下面这些信号时就该考虑迁移到 MySQL 或 PostgreSQL 了。第一个信号是并发写入报错。前面提过SQLite 同一时刻只允许一个写操作。如果你的爬虫开了多线程每个线程都往同一个库写就会频繁遇到database is locked。虽然可以通过设置超时时间缓解但治标不治本。第二个信号是数据量超过千万级且查询变慢。SQLite 单表几百万条没问题但到了千万级以上加上复杂查询性能下降会很明显。MySQL 在索引优化、查询缓存、分区表方面成熟得多。第三个信号是需要多台机器同时访问。SQLite 是本地文件没法跨机器共享。如果你的爬虫跑在多台服务器上或者需要让其他服务读取数据就必须换成支持网络访问的数据库。5.2 迁移时最容易踩的兼容性坑从 SQLite 迁到 MySQLSQL 语法大体相似但有几个坑几乎每个人都会踩。自增主键的写法不同。SQLite 是INTEGER PRIMARY KEY AUTOINCREMENTMySQL 是INT AUTO_INCREMENT PRIMARY KEY。直接复制建表语句会报错。时间默认值不同。SQLite 用DEFAULT CURRENT_TIMESTAMP没问题MySQL 也支持但 MySQL 对 DATETIME 字段的默认值有版本差异老版本只允许 TIMESTAMP 类型设默认值。稳妥做法是在代码里显式传时间不依赖数据库默认值。字符串拼接和函数名不同。SQLite 的||拼接在 MySQL 里默认不生效除非开启 PIPES_AS_CONCAT 模式MySQL 用CONCAT()。日期函数也不一样SQLite 用datetime(now)MySQL 用NOW()。INSERT OR IGNORE在 MySQL 里是INSERT IGNOREON CONFLICT在 MySQL 里是ON DUPLICATE KEY UPDATE。这些都要改。我的做法是把建表语句和写入 SQL 单独抽成一个模块SQLite 和 MySQL 各写一份通过配置切换。这样迁移时只改这一个模块业务代码不动。5.3 连接池多线程爬虫的必备配置用 MySQL 时如果每个线程都新建一个连接连接数会迅速耗尽数据库直接拒绝服务。正确做法是用连接池。Python 里常用的是DBUtils的PooledDB或者直接用 SQLAlchemy 的连接池。连接池的核心参数是池大小maxconnections。设太小线程抢连接会阻塞设太大数据库承受不住。经验值是池大小略大于你的并发线程数比如 10 个线程就设 12 到 15。另外要设置blockingTrue让连接不够时线程等待而不是直接报错。from dbutils.pooled_db import PooledDB import pymysql pool PooledDB( creatorpymysql, maxconnections15, hostlocalhost, userspider, passwordyour_password, databasespider_db, charsetutf8mb4 ) conn pool.connection() cursor conn.cursor() # ... 执行 SQL ... cursor.close() conn.close() # 注意这里是归还连接到池不是真正关闭注意pool.connection()拿到的连接用完必须close()否则连接不会归还池很快就被占满。这个close()是归还不是断开别被名字误导。6. 几个真实场景里的存储决策复盘6.1 列表页与详情页分开存很多爬虫是两级结构列表页给出标题和链接详情页才有完整信息。新手容易把两级数据混在一张表里结果列表页抓到的字段和详情页抓到的字段对不上表里一堆空列。更清晰的做法是分两张表一张存列表页的轻量信息标题、链接、列表页位置一张存详情页的完整信息通过链接关联。这样即使详情页还没抓列表页数据也已经落库了不会丢。两张表用 URL 或业务 ID 关联查询时 JOIN 一下就行。6.2 图片和文件不要存进数据库有人喜欢把图片二进制数据直接存进数据库的 BLOB 字段。除非数据量极小否则强烈不建议。数据库存二进制会让库体积迅速膨胀备份和迁移变得极慢查询性能也受影响。正确做法是图片下载到本地或对象存储数据库里只存文件路径或 URL。这样数据库保持轻量文件管理也更灵活。6.3 日志表记录每次爬取的元信息一个容易被忽略但很有用的做法是单独建一张爬取日志表记录每次爬取任务的开始时间、结束时间、抓取条数、成功条数、失败条数、失败原因。这张表不存业务数据只存任务元信息。它的价值在于当数据出现问题时你能快速定位是哪次任务出的问题而不是对着一堆业务数据干瞪眼。CREATE TABLE IF NOT EXISTS crawl_log ( id INTEGER PRIMARY KEY AUTOINCREMENT, task_name TEXT, start_time DATETIME, end_time DATETIME, total_count INTEGER, success_count INTEGER, fail_count INTEGER, fail_reason TEXT );这张表结构简单但实际排查问题时能省下大量时间。我现在的习惯是每个爬虫任务跑完都往这张表写一条时间长了还能看出哪些站点不稳定、哪些时段失败率高。7. 存储性能调优的几个实操开关7.1 SQLite 的 PRAGMA 设置SQLite 默认配置偏保守为了数据安全牺牲了不少性能。在爬虫这种“写入密集、对偶尔丢几条不敏感”的场景下可以适当调整 PRAGMA 参数来提速。PRAGMA journal_mode WAL; PRAGMA synchronous NORMAL; PRAGMA cache_size -64000;journal_mode WAL开启预写日志模式允许读写并发能显著减少database is locked的概率。synchronous NORMAL降低同步频率写入更快代价是极端情况下如断电可能丢最后几条数据。cache_size设成负数表示以 KB 为单位-64000就是 64MB 缓存减少磁盘 IO。这几个设置我在本地爬取时基本都会开实测写入速度能提升好几倍。但如果是生产环境、数据不能丢synchronous还是保持默认的FULL更稳妥。7.2 索引不是越多越好索引能加速查询但会拖慢写入。每建一个索引每次插入都要更新索引树。爬虫场景下写入频繁索引过多会明显拖慢入库速度。我的原则是只给真正会用于查询和去重的字段建索引。比如url_hash用于去重必须有唯一索引publish_time用于增量筛选建普通索引其他字段除非有明确查询需求否则不建。7.3 批量写入的批次大小怎么定批次大小没有标准答案取决于单条记录的大小和数据库配置。太小事务开销占比高太大内存占用高、失败回滚成本大。我的经验区间是 500 到 1000 条一批。你可以做个简单测试分别用 100、500、1000、5000 条一批跑同样的数据量看总耗时选最快的那个区间。大多数情况下 500 到 1000 就是甜点区。8. 写在最后存储是爬虫的“下半场”爬虫这个事抓取是上半场存储是下半场。上半场拼的是请求和解析的技巧下半场拼的是数据工程的基本功。我见过太多项目抓取部分写得花里胡哨存储部分一塌糊涂最后数据没法用等于白爬。结构化存储的核心就三句话字段设计要留后路原始数据、双时间字段写入要批量加去重方案选择要看场景而不是看流行。SQLite 起步、MySQL 扩展、文件做中转这套组合能覆盖绝大多数爬虫项目的需求。最后分享一个我自己的习惯每次设计一张新表之前先问自己三个问题——这条数据以后要怎么查会不会重复会不会变把这三个问题想清楚表结构基本就不会出大问题。至于具体的 SQL 语法和参数调优那都是可以查文档解决的真正难的是想清楚数据该怎么组织。