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

不应该存目录，然后去检索吗

@wuhao1 如果是你说的这样子的需求的话，如果要简化你的程序开发的话，上 TiDB 这类分布式数据库来存，会简单很多，而且你的内容有付费内容，这样的内容在 OSS 上加密的话效率太低，存数据库的话，就不用在数据库加密，有人访问的时候临时加密输出就行了。或者自己搞实体机组分布式文件系统譬如 ZFS ，或者上 Ceph 。但是运维成本就很高。

上数据库利于后期的 SEO 优化， 及后期的迭代更新。 文件会麻烦很多。
直接 pgsql 吧，all In one

@wuhao1 感觉你的需求描述来说不像是 X 趣阁 这类盗版站，那就很有意思了，国内还有新站？啥项目？好好奇

@abersheeran #53

为啥不全部小说，放一个 SQLite 里呢？热点小说 / 章节，也会被系统缓存那几个页面的呀？

比如说，你就算在机械硬盘上放数据库，反复 SELECT * FROM data WHERE id = 1 ，也能几万 QPS 呀？（机械硬盘 4K 随机读写，才几百噢）

@wuhao1 #56

边看边拆可以吗？为啥要一下子拆完呢。。是为了能快速跳转，拆后的章节？

那服务器预先计算每章字数、每行字数？客户端就可以迅速决定，拆分后新章节包含哪些行，分布在哪些章节文件了呀。。


@wuhao1 #58

为啥不整书压缩（ 100 MB -> 18 MB ），放 OSS 呢？是怕 OSS 被刷流量吗？

如果是付费书，可以压缩时加密码呀。。要解压，需从服务器拿密码啥的。。

但话说，不是付费用户，你不给 URL ，应该也行了吧。。

@niubee1 #62

1. 访问服务器时，为啥还要加密输出呢？是怕用户简单抓包，就分析出响应结构吗？还是。。？

2. OSS 上存加密压缩包，付费用户访问接口拿密码，可行吗？

3. 为嘛不选 SQLite 呢？隔壁帖子测试，单表 1.3 亿 100 GB 数据，还能有 4.7W QPS 呀？（六七年前轻薄本 + 低端 SATA 固态）



@ShuA1 #63

为嘛不选 SQLite 呢？隔壁帖子测试，单表 1.3 亿 100 GB 数据，还能有 4.7W QPS 呀？（六七年前轻薄本 + 低端 SATA 固态）

@wxf666 因为没必要，你这个简化的模型就是一个 key:(小说,章节) -> value:内容
的存储，没有关系，没有 join ，不需要 acid 。
直接 oss/s3/文件完事，你可以测试下 oss/文件系统，完全满足。
sqlite 100GB 数据库维护起来挺费劲的。

@wxf666 目前的方案就是 采用 oss 存储章节内容， 遇到密集操作整本书的时候巨慢，单章的读写没什么问题，目的就是要生成一本新的书，所以边看边拆不现实，再说边看边拆，不好控制需要不断记录拆的位置然后要截断的位置，不如全本全局的拆。我们目前并没有压缩内容，读取内容更方便。


@niubee1 就是普通的 付费小说 平台，类似与阅文，点众这样的

其实可以搞成 oss 和磁盘共存 （某一项用做备份，需要密集操作 调磁盘，效率高，一般的章节读写 oss 磁盘都可以。

@wxf666 SQLite 只有单并发， 而且后期扩展也麻烦。pg 可以 all in one ， 一个数据库解决应用和小说存储的问题。

@ShuA1 SQLite 可以并发查询 而且性能很高，只是不能并发写，对于小说这种 只在后台更新，前端用户并发阅读的 特别合适，甚至很多项目都用 SQLite 做缓存

@wuhao1 你算一下你们内容的的总量是多少， 如果是 TB 级别的内容的话，SQLite 单机肯定撑不住，那就要群集方案，那都要分布式群集了，那还不如用现成的成熟方案，不然你还打算自己 DIY 一个 SQLite 作为 backend 的群集出来？没有必要吧。
加密的话，因为我经常爬小说，所以，习惯使然

另，付费小说平台在国内还有得赚么？还是是在国外搞？

@815979670 小说也并不是单并发写入，需要考虑：
1. 多蜘蛛写入
2. 单蜘蛛的情况， 后台其他操作写入/注册会员写入

1. 多个蜘蛛写入 SQLite 如果小说是以 每本小说都是一个 SQLite 的维度存储时，这不是问题。
如果存储多本小说 或者 同一个 SQLite 文件有多个线程写入，可以通过 批量写入的方式实现， 我前年测试 SQLite 写入性能 15w 数据耗时 5.13 s ，完全可以满足需求

2. SQLite 只是小说内容部分的存储方案，项目中 会员信息或者其他操作 还是 mysql/pgsql

@mayli #68 我在 40 楼也认为，放 OSS 更合适。

但确实又有其他人说，要上 TiDB 、PostgreSQL 、甚至存硬盘 等，

所以就想问问，SQLite 会碰到啥困难，满足不了啥需求。。

毕竟这货资源占用真的小，性能也真的很强，挺诱人的。。

（除了多线程并行写事务。但并发写还不错，一亿数据还能上万并发写）


> 《 sqlite 100GB 数据库维护起来挺费劲的》

具体是什么场景费劲呢？备份迁移吗？还是。。？

@wuhao1 冷热存储呗，长期没用的就放 oss ，热门小说就放磁盘，放缓存 设置一个 ttl 。

@ShuA1 #70

你们爬小说，每秒会爬多少章节，写入多少行数据库呢？

PostgreSQL 一亿数据时，能支持多少并发写呢？资源占用如何？

隔壁贴测试 SQLite ，1.3 亿 100 GB 数据时，仍能 1W 随机写事务 / 秒，占用 16 MB 内存。

但并行写确实是 1 。可我觉得，还是有办法扬长避短：

1. 专门一个线程，处理写事务，每秒能写上万行。其他爬虫线程，爬好数据后，传给该线程的队列。
2. 每个爬虫线程，每爬 1000 章 / 一本书，申请互斥锁，平均花 0.1 秒写入数据后，继续爬。
3. SQLite 官方有个开发了 9 年的 begin-concurrent 分支[^1]，允许多个写事务同时操作不同 4K 页。（类似 Redis 多事务操作不同键）

官方宣称[^2]，AMD 5950X + WAL2 日志 + 同步关闭 + 100W 行 256 MB 数据时，有：

- 三线程，7.2W TPS （每事务一写）
- 八线程，5.4W TPS （每事务一写十读）

但一直没合并到主分支。如果愿意吃螃蟹，可以试试。

[^1]: [SQLite: Begin Concurrent]( https://sqlite.org/cgi/src/doc/begin-concurrent/doc/begin_concurrent.md)
[^2]: [hctree: Thread Test (sqlite.org)]( https://sqlite.org/hctree/doc/hctree/doc/hctree/threadtest.wiki)

@wuhao1 #69

《遇到密集操作整本书的时候巨慢》是网络请求几千个章节慢吗？

@ShuA1 估计会每秒爬几千章，要不你问问他咋做的？


我[以前]( /t/884743#reply12 )用 Python 爬笔趣阁，凌晨 3 ~ 5 点时，每秒能爬 700 章左右。。

包括：单线程协程爬取 + 解析抽取 + 转成 UTF-16 + 全本数据合并 + 多线程 lzma 压缩 + 写入到 TF 卡（在骁龙 636 的手机上 + WIFI 测试的）

@niubee1 #72

请教一下，《 TB 级别的内容的话，SQLite 单机肯定撑不住》是啥意思呢？

1TB 时，QPS 会掉到几百几十的意思吗？

1.3 亿 100 GB 时，没感到有啥性能瓶颈呀。。

（六七年前轻薄本 + 低端 SATA 固态，还能 4.7W 的 QPS ）

---

可惜我手头只有 256 GB 的固态，测试不了。。但我感觉应该没问题？

数据库调整成 8KB / 页，扇出是 612 （ 4K 时 306 ），叶子节点上能存 3 章小说（每章 2.66 KB ，字典压缩后），

那 4 层 B+ 树能存 612 ^ 3 x 3 = 6.88 亿章，总共 1.70 TB 。。

缓存前三层枝干节点，系统需要 (612^0 + 612^1 + 612^2) x 8 / 2^20 = 2.86 GB 内存，

往后每随机读取一章，就和 1.3 亿 100 GB 类似了。也可参考固态 8K 随机读取测试。。

@wzwmeme #76

服务器硬盘和流量，都比 OSS 贵得多诶。。

应该长期没用，放低频 OSS 。热门放 OSS + CDN 。。