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

@Ta 05-26 22:19发布,05-27 00:43修改 3248点击

需求:

  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. 因此考虑分块压缩。简单测试下,不同块大小压缩与整体压缩率关系图(以第四点那本小说为基准)

    img

    在块大小为6 MB时:

    • 对整体压缩率的影响逐渐变小。若一章节约3000字,这个块大小大约对应1000章,可能方便后面管理
    • 读取某一章,只需6 MB内存,顺便也可缓存该块的1000
    • 修改某一章导致的重新压缩,最大只会占用100+ MB内存
  6. 不足1000章的小说,将以原文形式存在数据库中

暂时想到这些

回复列表(12)
  • @Ta / 07-02 02:50 / /
  • @Ta / 05-27 00:20 / /

    @神的孩子全跳舞,逛逼乎看到的,似乎要严打盗版了?想着屯一些,万一以后用得上呢
    img

  • @Ta / 05-27 00:30 / /
    我之前入库,mysql,一个表没几天塞了几十个G,啥事没用
  • @Ta / 05-27 00:36 / /

    @echo醉老仙,几十G。。这是爬了多少啊

  • @Ta / 05-27 00:41 / /

    @echo醉老仙,如果采用UTF-16编码,并7z压缩存储,估计你可以减少80%的空间占用

  • @Ta / 05-27 00:43 / /

    改下标题,目的更明确些

  • @Ta / 05-27 05:31 / /

    为何要爬小说,这玩意我数据库好多g.感觉小说真鸡儿多.感觉累赘就删了

  • @Ta / 05-27 07:07 / /

    @20263,看到新闻说(见2楼),500多作家、十几个平台、全国各地协会,联名请求封杀盗版,觉得以后可能有用,就想先屯着呗

  • @Ta / 05-27 07:13 / /

    @无名啊,可以存国外网盘啊

  • @Ta / 05-27 07:28 / /

    放心封杀不了的,霉国那么注重版权,网上照样不是盗版满天飞?只是获取的门槛提高了而已
    而且中国还有几个主打免费的呢就是广告多点
    小尾巴我就菜鸡一枚 https://18sui.net炮兵学院

  • @Ta / 05-27 16:55 / /

    @20263,有啥国外网盘嘛?

    其实觉得还不如自己买硬盘存靠谱,毕竟后面真被封杀了,本地也容易做个阅读站,或者配合“阅读”App使用啥的

  • @Ta / 05-27 17:01 / /

    @布偶,我听说在美国下盗版后果很严重?

    今天又看见央视新闻和新华社提及此事,总觉得会打击盗版了

    1653642009857.jpeg

    Screenshot_2022-05-27-16-59-58-072_com.ss.android.ugc.aweme.lite.jpg

添加新回复
回复需要登录