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

有分布式要求吗？ 没有就磁盘，有就对象存储
数据库只在你需要大量全文检索的时候再说

你团队是对的，磁盘你怎么管理元数据？

怎么可能直接存磁盘啊, 打算自己造几年轮子啊.

当然是现成的 OSS ，你估计下各种方案最终落地需要的时间

不都是存数据库吗？一本小说 20M,存 oss 咋打开？

oss 对于密集操作，很不友好，网络 IO 开销太大了

@Kinnice 暂时没有分布式要求
@dynastysea 磁盘只要存 章节内容就行了， 章节的元数据存数据库

@MoYi123 用磁盘主要是 方便 和 性能的考虑
@shadowyue oss 其实成本应该比磁盘贵

@13240284671 书少确实存数据库， 但是海量的书存数据库就不合适宜了， 主要是数据库的存储太贵了

什么需求需要存数据库呢？数据库存元数据（名字大小目录之类的），本地盘存实际文本会不会好些

好巧 我的小说文章网（只是一个工具的部分功能）也正在收录，刚发布完。资源来源 pdd 的几十块的 U 盘，大部分格式是 pdf 的，其他是 txt 等，偷个懒我直接传诚通网盘了，直接下载。要兼容这么多格式，工作量太繁琐。
3 天时间一口气发布了 4w 多篇文章。
https://li2345.com/read

暂时没有分布式要求，单机网络开销多大？ 现在网络已经存在性能瓶颈了吗？

我还真做过，我的做法是一本小说压缩后分章节存入 sqlite 。这里有几个原因，第一是可以让细碎的章节文件合并起来，还有是查 sqlite 要比直接从文件系统读取更快，以及当用户阅读一本书的时候，应该是连续的，要把后续章节提前拉到本地做缓存，而不是只把当前章节拉到本地做缓存。当时我抓了压缩后接近一个 T 的小说数据。

sqlite 文件放在 OSS 上进行保存。本地做一个缓存机制，100GB 硬盘可以缓存几万本书，对于小站点来说完全够了。普通的 CC 攻击打不死。

小说网站感觉基本 99%的小说都是在吃灰状态。oss+本地热缓。oss 主要节约时间来着

磁盘存文件，meta 存 mongo ，字段包括书名作者概要及文件路径等等。关键 meta 元素的提取怎么来。

如果全文检索只能都进数据库了吧。

没用过 oss ，认知范围内只会这样。

成熟方案
参考杰奇小说
元数据 mysql 小说 txt 扔硬盘
生成纯静态 html
热文件扔 ssd 什么压力都没有

oss 确实不失是一个好方法，但是在集中密集操作就暴露缺点了，如果我要读完整的一本书的内容， 网络开销太大了

还有就是如果是免费小说那么静态化再加上 CDN 毫无压力， 可是如果是收费呢？

总结： 把磁盘和 oss 的优点集中起来， 既存 oss 又存磁盘， 有没有就好很多 ……^_^

不存数据库的话全文检索又是一个问题。

如果没有全文检索需求的话可以压缩存储，web 场景下 cpu 资源很多都是被浪费了（常年在 20%以下），可以通过压缩利用起来

@abersheeran 能详细说说怎么存的吗，一本小说一个 sqlite 文件 还是 1T 数据全是同一个 sqlite 文件 或者时按照其他规则拆分的？ 压缩算法用的时 zip 吗？ 我之前有尝试用 zip 算法压缩文本 然后存入 sqlite 体积只有原来的四分之一

如果预算够，直接上 oss ，如果做磁盘存储的话，备份是一个很大的问题。小说文件都是小文本，小文件备份效率非常低。
oss 除了费钱以外，其他都挺好的。oss+cdn ，基本上不用这么管。

@ytmsdy OSS 应对密集操作不友好，网络 IO 太高

@815979670 #17 全是一个 SQLite 文件，应该也没啥不妥吧。。

我在隔壁帖，测试了单表 1.3 亿 100 GB 数据，六七年前轻薄本上，还能上万随机读/写事务并发。。


压缩存储，感觉用 zstd 较好？压缩率接近 lzma ，但解压速度快 7 倍。。

可以测试一下，每 N 个章节一起压缩后总大小 S0 ，与整本小说压缩后大小 S1 ，的关系。

选 N 尽量小（只读取一章时，不用浪费太多力气解压更多章节），S0 又尽可能逼近 S1 的（ N 太小，会浪费很多空间，反复存储词典啥的？导致 S0 远大于 S1 。。）


或者试试，行级别的 zstd 压缩插件（ https://github.com/phiresky/sqlite-zstd ），或者页级别的（ https://github.com/mlin/sqlite_zstd_vfs ），或者官方 $4000 的（ https://sqlite.org/purchase/zipvfs ）


对了，中文内容的话，换成 UTF-16 存储，能直接省 1/3 空间。。