1.数据库存储
2.磁盘存储
3.oss 存储

  1. ？
    结合 速度和成本 最好的会是那种方案呢？
    个人倾向于磁盘 速度快成本低
    团队倾向于 oss

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

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

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

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

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

oss 对于密集操作，很不友好，网络 IO 开销太大了 暂时没有分布式要求 磁盘只要存 章节内容就行了， 章节的元数据存数据库 用磁盘主要是 方便 和 性能的考虑 oss 其实成本应该比磁盘贵 书少确实存数据库， 但是海量的书存数据库就不合适宜了， 主要是数据库的存储太贵了

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

好巧 我的小说文章网（只是一个工具的部分功能）也正在收录，刚发布完。资源来源 pdd 的几十块的 U 盘，大部分格式是 pdf 的，其他是 txt 等，偷个懒我直接传诚通网盘了，直接下载。要兼容这么多格式，工作量太繁琐。3 天时间一口气发布了 4w 多篇文章。 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%以下），可以通过压缩利用起来

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

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

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

＃17 全是一个 SQLite 文件，应该也没啥不妥吧。。我在隔壁帖，测试了单表 1.3 亿 100 GB 数据，六七年前轻薄本上，还能上万随机读/写事务并发。。压缩存储，感觉用 zstd 较好？压缩率接近 lzma ，但解压速度快 7 倍。。可以测试一下，每 N 个章节一起压缩后总大小 S0 ，与整本小说压缩后大小 S1 ，的关系。选 N 尽量小（只读取一章时，不用浪费太多力气解压更多章节），S0 又尽可能逼近 S1 的（ N 太小，会浪费很多空间，反复存储词典啥的？导致 S0 远大于 S1 。。）或者试试，行级别的 zstd 压缩插件（ github.com/phiresky/sqlite-zstd ），或者页级别的（ github.com/mlin/sqlite_zstd_vfs ），或者官方 $4000 的（ sqlite.org/purchase/zipvfs ）对了，中文内容的话，换成 UTF-16 存储，能直接省 1/3 空间。。

相比磁盘存储，为嘛不选 SQLite 数据库呢？感觉优点还行呀：1. 单表 1.3 亿 100 GB 大小时，六七年前轻薄本上，仍能上万随机读/写事务并发。且只占用 16 MB 内存。源码在隔壁帖2. 官方宣称，相比文件系统，10 KB 文件存数据库里，能快 35%，节省 20% 空间。文章你按章节来存的话，假设每章 5000 汉字，UTF-16 存，恰好 10 KB 。3. 支持全文索引，甚至拼音/首字母/多音字。可无限搜索事务同时进行。微信宣称，手机端百万百字聊天记录，搜三字词，只需 0.0029 秒。10 秒全文索引完毕。文章4. 备份迁移时，没有天量小文件烦恼。两周后，SQLite 会发布一个，远程增量同步工具。

＃10 ＃17我用近 14000 章的《带着农场混异界》，试了一下 zstd 的预训练词典，感觉很适合分章节压缩存储，因为 UTF-8 时，整本压缩率 20%，分章节总压缩率也才 22% ~ 28%，还能快速随机选取章节。如果独立压缩章节，总压缩率飙到 38%。1. 压缩后，UTF-16 没有明显优势。所以采取 UTF-8 就好。UTF-8 时 137.4 MB- gzip 压缩 43.5 MB （ 31.7%）- zstd 压缩 28.7 MB （ 20.9%）- lzma 压缩 26.8 MB （ 19.5%）UTF-16 时 96.9 MB ，- gzip 压缩 39.0 MB （少 10.5%，相比 UTF-8 压缩后）- zstd 压缩 27.6 MB （少 3.9%）- lzma 压缩 25.2 MB （少 6.2%）2. 分章节后，所有压缩算法表现都很差。可选择多章节压缩，或分离词典。- gzip 后共 55.6 MB （ 40.5%）- zstd 后共 51.8 MB （ 37.7%）- lzma 后共 52.4 MB （ 38.2 %）3. 只有 zstd 支持预训练词典，且不同词典大小，分章节总压缩率也不同。- 32 KB 词典（压缩后 12.6 KB ），压缩后+词典 39.6 MB （ 28.8%）- 64 KB 词典（压缩后 24.7 KB ），压缩后+词典 37.8 MB （ 27.5%）- 110 KB 词典（压缩后 41.9 KB ），压缩后+词典 36.6 MB （ 26.7%）← 默认词典大小- 128 KB 词典（压缩后 48.7 KB ），压缩后+词典 36.3 MB （ 26.4%）- 256 KB 词典（压缩后 97.8 KB ），压缩后+词典 35.0 MB （ 25.5%）- 512 KB 词典（压缩后 197.2 KB ），压缩后+词典 34.1 MB （ 24.8%）- 1024 KB 词典（压缩后 315.3 KB ），压缩后+词典 33.0 MB （ 24%）- 2048 KB 词典（压缩后 611.2 KB ），压缩后+词典 32.1 MB （ 23.3%）- 4096 KB 词典（压缩后 1164.8 KB ），压缩后+词典 31.2 MB （ 22.7%）- 8192 KB 词典（压缩后 2328.5 KB ），压缩后+词典 32.4 MB （ 23.6%）4. 个人认为，不同场景的选择。- 如果本地收藏，追求极致压缩，每次查看，接受解压全本，应该选 UTF-16 + lzma ，压缩率 18%- 如果本地收藏，但要求快速任意跳转章节，选 UTF-8 + zstd + 大词典，压缩率 23%- 如果对外提供服务，选 UTF-8 + zstd + 小词典，压缩率 27%第三点考虑如下：- 若服务器本地解压，再传给用户，每次选取章节后，再取对应词典压力较小，缓存词典所需内存也少- 若要求客户端先拿词典，再本地解压呈现章节。面对只看几章就弃书的用户，沉没成本较低（ 20 ~ 40 KB ）

问一下 压缩后的数据存 text 类型还是 blob 类型？

＃23BLOB ，存的是 zstd 压缩后的二进制数据。噢，如果要全文搜索，存压缩后数据也没关系的。SQLite 的 FTS 支持无内容表，只要你添加/删除时，提供了压缩前的章节内容，就行。但搜索结果只有 章节 ID，还需要回 章节表 取数据解压。但搜索服务，一般都会分页呈现结果，所以不会一下子解压几万个章节出来。。一下子解压几万个章节。。可能也没事？过亿数据，都能四五万随机读并发，命令行里 zstd 用词典，单线程解压那 14000 章节文件，也才 0.9 秒。。还是六七年前的轻薄本了。。