@wzwmeme #76

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

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

@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 随机读取测试。。

@wuhao1 #69

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

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


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

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

@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)

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

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

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

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

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


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

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

@iamtuzi3333 #66

1. 《数据太过分散，不方便后续读取维护》是啥意思呢。。

这个测试的主键类似于（设备 ID ，时间戳），如果你要查今天所有设备的数据，可以：

```sql
SELECT *
FROM data
JOIN generate_series(1, 500) 设备
WHERE 设备 ID = 设备.value
AND 时间戳 BETWEEN '今天' AND '现在'
```

我觉得单表数据过大，需要担心的是 B+ 树层级过高，每次读取需要再耗费一个 IO 。。



2. 测试中，我也是用了类似《先缓存写入的行，一定数量后再刷写回数据库》方法，提高写事务速度的。

设定缓存最多 1W 行，平均每设备 20 行，每 5 行一个 4K 页，即每设备 16KB ，

所以就能参考 16KB 随机写速度了。。

@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 固态）

@wuhao1 #56

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

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


@wuhao1 #58

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

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

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

@abersheeran #53

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

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

@winglight2016 #48

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



@wuhao1 #49

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

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

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

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

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



@niubee1 #50

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

@dreamk #12

挪到，不是双重存储。。否则挪用公款，就是变出两份钱财的意思吗。。

redis 不是有 AOF 、RDB 机制吗？重启也不会丢数据呀。。

@niubee1 #44

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

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

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

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

@excxapp 如果每个请求，都要去 redis 判断一下，是否登出了，

为何不把 JWT 里的内容，挪到 redis 里，拿不到就是登出呢？

这样，每个网络请求能更小，带宽需求更低呀？

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

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

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

@sagaxu #22

1. 那这就是偷懒，所需要付出的代价了。。


2. 为啥不所有会话共享一个语句缓存池呢。。肉眼可见，能减少 90% 内存需求呀。。


3. 是 MySQL 等不想接管硬盘吗？原理上应该差不多呀。。都是 页偏移 x 页大小 定位？


4. 传统公司应该不咋用 MySQL 吧？

两年前，我在 [另一个帖子]( /t/889443#reply21 ) 测试过树状数据的获取，这货多个测试中，比 SQLite 都慢 2 ~ 10 倍。。

不敢想其他更复杂的请求，MySQL 会拉跨成啥样了。。


5. 这些 log 都是顺序写，不咋读？（恢复数据时读？）感觉完全可以放到另一个盘。。


6. 按理说，阻塞并发写，应该不影响并发读呀（只要不是当前读）。。可 MySQL 的读性能，就如第 4 点所说。。

前几天，[另一个帖子]( /t/1075881#reply65 )测试，SQLite 在写事务时，其他线程读事务，应该能吃满 IO 性能。具体是，单表 1.3 亿 100 GB 数据，还能 4.7W 读事务 / 秒。

但也如你所说，此时 ACID 弱化 / 舍弃，如持久性不完全，断电时可能会丢失几秒钟数据。另外，写事务是串行化隔离，读事务是快照隔离。


7. 好奇行锁、间隙锁，实现原理是啥呢。。我在 21 楼瞎猜，是锁列表？或者 B+ 树节点上锁？

要是 SQLite 加上多事务并行写，并且在同进程内，免去网络开销，这得有多爽啊。。

@mayli #39

简单算了下，大部分时候，还是 OSS + zstd 划算？再加上 CDN ，能进一步减少流量部分的花费？

除非只存了 100 ~ 200 GB ，且每月点击数过亿，此时用服务器较为划算？



1. 我查了下啊哩云的价格（不太熟悉，有错的还请指出）：

OSS：
- 存储：0.12 元 / GB / 月
- 流量：0.50 元 / GB
- 请求：0.01 元 / 万次（每月 <= 2000W 次时免费）

服务器：
- 存储：0.50 元 / GB / 月
- 流量：0.80 元 / GB


2. 如 22 楼所说，14000 章小说，词典 + 分章节压缩 36.6 MB ，平均每章 2.68 KB 。加上网络传输 TCP/IP 头部、握手、响应头部等杂七杂八开销，算 3KB 好了。

如果是 gzip 压缩传输，平均每章 4.02 KB ，加上乱七八糟两三百字节，算 4.3 KB 好了。


3. 则每月费用为（ P 为每章平均网络包大小，C 为每月点击次数（万次），S 为每月存储大小（ GB ））：

- 服务器：( P x C / 2^20 ) x 0.8 + 0.5 x S

- OSS：( P x C / 2^20 ) x 0.5 + 0.12 x S + max(C - 2000, 0) x 0.01


4. 画图后，是这样：

https://i.imgur.com/v4Jrz40.gif

- X 轴：C 值（ 0 - 6.7 亿次）
- Y 轴：S 值（ 0 - 1000 GB ）
- Z 轴：每月费用（ 0 - 3000 元）
- 红色：服务器 + gzip
- 黄色：OSS + gzip
- 蓝色：OSS + zstd
- 绿色：服务器 + zstd

@neoblackcap #29 试了一下，vscode 也是局部重绘的？

https://i.imgur.com/Z0e181z.gif

@neoblackcap #21

> 对图形渲染有要求的需求，都是得用即时模式。

这个怎么理解呢？


浏览器渲染，比这些客户端复杂吧。。可浏览器也是局部重绘的呀？

《开发工具》里，甚至有《突出显示需要重新绘制的区域》的选项。。

而且滚动条拉太快，下方的画面，会是一堆白色框框，还未渲染出来呢。。

如果一直是全屏重绘，滚动条拉到哪，绘制量不都差不多吗？上方能 60 Hz 刷新，下方咋就出白框框了呢。。


另外，前几年 老 Edge 浏览器，不是更被谷歌使绊子，油管视频上方放特殊元素，就变得卡顿，耗电激增吗？

如果一直是全屏重绘，增加这点绘制量，咋会让 老 Edge 这么吃亏呢。。

@815979670 #37

总感觉，要依赖外部程序解压缩，才能查看原文，有点麻烦。。

正常原文存储，每天凌晨归档至 DuckDB ，可行吗？

如果怕 DuckDB 还不够稳定，可能丢数据，那就再 lzma 压缩一份，文件系统上归档？



@mayli #36

切分后，怎么存放、提供访问呢？

1. 直接按范围下载原文，并 gzip 传输，是不可行的。因为如 22 楼所说，独立每章 gzip --best 压缩，整书只能压到 40%。（ zstd 配合小字典压缩，都能有 25%）

2. 按章切分 + 字典压缩 + 存 OSS 提供访问的话，好像有个请求费比较贵。。服务器的话，存储和流量又比较贵。。