想爬点小说，数据库该如何设计更省空间？

需求：

1. 自用，侧重于节省空间，不用太高的并发读写
2. 内容包括：书（基本信息、封面图）和章节（章节名、内容主体）
3. 小说会有更新，某些章节可能也会被修改

思考：

1. 出于管理简单目的，选用SQLite

2. 2017年SQLite说“十几KB的小文件存储在SQLite中，读写速度可比文件系统快35%，空间节省20%”，所以封面图和内容主体都存在数据库中
   （应该是不用像inode那样存大量创建/修改/访问时间、权限记录等信息吧）

3. 绝大部分是中文内容，因此采用UTF-16存储（怕小说有emoji之类的，所以不用GBK），应该可比UTF-8节省1/3左右

4. 同一本书的不同章节之间，应该会有更多的相关性，压缩存储应该能省下可观的空间。

   简单测试下，一本一万多章的小说，52.5 MB，用 7z, preset=9e (dict=64M) 压缩后，15.4 MB，压缩率 29.4 %。

   但若以64 MB字典固实压缩整本小说，会有如下不便：

   • 读取/修改某一章，都要全部解压
   • 64 MB字典压缩时，最大会占用800+ MB内存

5. 因此考虑分块压缩。简单测试下，不同块大小压缩与整体压缩率关系图（以第四点那本小说为基准）：

   

   在块大小为6 MB时：

   • 对整体压缩率的影响逐渐变小。若一章节约3000字，这个块大小大约对应1000章，可能方便后面管理
   • 读取某一章，只需6 MB内存，顺便也可缓存该块的1000章
   • 修改某一章导致的重新压缩，最大只会占用100+ MB内存

6. 不足1000章的小说，将以原文形式存在数据库中

暂时想到这些