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

[wuhao1]

1.数据库存储
2.磁盘存储
3.oss 存储
4. ？
结合 速度和成本 最好的会是那种方案呢？
个人倾向于磁盘 速度快成本低

团队倾向于 oss

[Kinnice]

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

[dynastysea]

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

[MoYi123]

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

[shadowyue]

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

[13240284671]

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

[wuhao1]

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

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

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

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

[Pitttttt]

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

[rui6ye]

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

[dode]

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

[abersheeran]

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

[abersheeran]

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

[sincw]

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

[elboble]

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

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

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

[baijiahei]

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

[wuhao1]

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

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

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

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

[815979670]

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

[815979670]

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

[ytmsdy]

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

[wuhao1]

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

[wxf666]

@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 空间。。