问下站内大神们 成千上万的小说-存储方案

@wxf666 没必要 存储的日志从设计上考虑，只允许通过这个程序读取，所以只要能实现 压缩存储、按时间检索展示就行

@wxf666 上千万部小说，按照常年下 txt 小说的经验来说，完本的 txt 文件均值在 5M 左右，按照 1500 万本计算，纯文本的体积就有 73 TB ，如果按照 50%的完本率乘个系数来算的话，预估至少 50TB 。但是实际上活跃的小说只有其中一部分，可以将大多数的内容放到 OSS 的低频存储里去，用一个电梯算法来做冷热数据的替换。这样成本会低一些

@niubee1 #42 如果是整本存储，那肯定是 UTF-16 + lzma 压缩最舒服了，从 22 楼看，能压到 18%（即 9 ~ 13 TB ）

但这不适合在线阅读，因为没法任意章节跳转。。而且看几章就弃书，也要下全本的话，成本太高了。。

对于在线阅读，你们会怎么提供服务呢？

@wxf666 一般来说还是分章节用小文件存储，oss 什么的，压缩什么的无所谓的，因为事实上大部分小说阅读网站也不提供小说内部全文检索，搜索主要针对的元数据，那就是数据库的故事了。分章节存还有一个好处是可方便冷热分区存，以便节省费用，根据自己的经验，很大部分小说的后 1/3 章节甚至 1/2 的章节，大多数人都会弃书，所以绝大部分内容都可以放到低频存储里去，只要电梯算法设计合理，可以节省很多成本

@niubee1 #44

这个小文件，是请求服务器获得吗？还是走 OSS + CDN 呢？还是。。？

啊？压缩的话，能节省 75% 的存储需求呀？放 OSS 里，就是每年节省 37.5 TB ，算下来就是 5.5W 元了呀。。

额。。这咋和全文搜索，联系上了。。

是诶，还能通过区分冷热数据，进一步省钱。。但冷数据好像不足 64KB ，也按 64KB 算，应该要多个章节合起来存了。。

直接无脑 cloudflare r2

@dzdh 楼主没说是不是收费，要不要加密，不加密可以，加密的话 cloudflare r2 就不适合了

lz 这需求都说不清楚怎么还负责存储方案了？存储方案首先看的是读写需求，只要满足这两块，剩下的考虑才是成本，用最便宜的存储就可以。

小说网站一般都是按章节浏览，所有按全本文件存储的方式都不合适，除非是专门做全本下载的。

最后，成千上万本小说，这个数据量太小了，根本不值得讨论性能、速度这些问题。

@niubee1 收费，免费都有， 所以就按收费来 ， 免费的收费为 0 ，加密这个之前搞过不过算法也在 js 里 可以破解， 后面索性不加密了，哈哈
@winglight2016 是的 按章节 收费，也有按本收费 的，看大神回复的 很多都是 按整本 （适合免费小说的 方案 ，付费的确实 不适合。
oss 看起来确实不失为一个好的方案， 但应用下来， 在应对 密集操作 就是灾难， 网络 io 太大，请求一整本书的时候会很慢， 不得已需要将书存到缓存来缓解这种缺点

@wuhao1 一直很好奇你一直在说 IO 密集操作，但是就我所知，小说这类文件存到 OSS 上后就只需要读就行了，还有啥密集的 IO 操作？

@winglight2016 #48

楼主有说，存章节内容。如果每本书 5000 章，那就是考虑怎么存 5000W 小文件了。。



@wuhao1 #49

我回复了很多，全是按章节来考虑的，甚至连成本都算了，并画动态图进行比较。

我也很好奇，你说的《网络 IO 太大》是啥意思呢？

是说，缓存整本书，需要发起几千个网络请求吗？

你每次并发 100 下载，一分钟内都能下完了吧。。

或者，你按 10 章 / 文件来保存，只需要几百个请求就行了呀？



@niubee1 #50

同好奇他说的《 IO 密集》是啥意思。。几千小文件，下到内存里，解压合并不就好了吗。。

@niubee1 #47 rclone 挂载到本地 自己加密 关键是大量 IO 操作请求次数都收费的

@815979670 #17 一本小说一个 sqlite ，方便缓存热点小说，全部小说的基本信息有一个独立的数据库。

@abersheeran 那确实挺合适，小说更新和不会再修改 并发读取又是 sqlite 的强项

如果你是打算自己做个笔趣阁之类的盗版小说网站，我倒是有一个不道德的点子。你把网络小说拆章节存到 telegraph 上。

@wxf666
@niubee1
是这样的 ， 比如 为了某种需求 ， 需要对整本书 做一些操作， 比如 拆章 ， 将之前 3000 字一章的 拆成 1500 字（甚至更少）左右 1 章 ， 那么就需要先将整本书读完， 然后在做操作， 如果是存 oss 那么读整本书的等待时间， 就很煎熬了。

先预处理文本，然后按热度做阶梯式存储

@biubiuF 目前是 第一次读整本书的时候存 redis 缓存， 后面的访问都是访问 redis ，但是 第一次也还是很慢

@abersheeran 有没有基于 telegraph 的 key-value 存储, 就不能指定 key ，但是至少可以存个 key-index

我觉得还是得看这些文件存储以后具体会有什么样的操作吧，根据实际的情况去选择。
如果是一个“小说”的“系统”，我觉得不会是某一种存储方案。
文件的基本信息需要放到关系型数据库里，文件本身其实我是倾向于放到对象存储里面，根据文件总量、单个文件大小、并发量还有能够接受的延迟，去选择具体的对象存储。
单纯从使用上说我从 S3, MinIO, Ceph 这三个里面去选，因为 api 基本兼容，后面不管换啥，代码都不需要修改。