@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 提供访问的话，好像有个请求费比较贵。。服务器的话，存储和流量又比较贵。。

@mayli #33
@tushan #34

是整本存 OSS 吗？在线阅读，也要下整本吗。。

对于只看几章，就弃书的用户来说，投入是不是有点高了。。



@815979670 #29

算了，DuckDB 标题也写了，人家自认是 OLAP 类型数据库，应该不适合高并发读写。。

但用来分析你那 400GB 历史日志，应该非常合适。。

别的不知道，但 Flutter 应用，每一帧都是全屏重绘的。不知这点是否有拖慢响应，使得交互有滞后感。。

理由：我以前测试，丢复杂文本进编辑框后，全窗口都会变卡顿。。

按理说，与文本框无重叠的元素，应该不卡顿才对呀。。

（下面是当时测试的，两个 Flutter 应用，录制的 GIF ）

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

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

@infinet #25

要是不换键盘，估计都能磨成粉了吧。。https://i.imgur.com/krir4IG.png

其实网上冲着《字数较多网文》随便搜的，

看了下，这小说连载十来年了，应该换好几套键盘了吧。。



@815979670 #26

我还没试过日志存数据库诶。。

日志可以调整成，边压缩，边流式存到硬盘上吗？

要搜索的话，zstdgrep 就能搜了。。


如果你确实想试试数据库存日志，也推荐你 DuckDB 对比下，

这货是列式数据库，默认就带压缩。同一列相同类型，压缩效果应该也更好些。。

而且功能、计算速度也比 SQLite 丰富/快很多。

就是不知道读写速度，比得上 SQLite 不。。

@sagaxu #20

1. 肯定是 SQL 和 参数分离的呀，现在还有人手动拼接 SQL 和参数的吗。。

分离后，直接查 SQL 的 hash ，就知道是否被解析过，执行计划是否在缓存中了呀。。


2. 是的，考虑到索引主键可能较大，B+ 树层级较高，所以上个回复才说了《(2 + 2) ~ (2 + 3) 次 IO 》。


3. 如果文件系统对读写影响很大，数据库为何不自己接管硬盘分区读写呢？

毕竟，它应该也没用到文件系统啥高级功能吧。。

Q: 还是说，分区大小固定死了，不能灵活调整？
A: 啥公司这么拮据啊，那么关注性能，腾整个盘存数据，都觉得物未尽其用吗。。

Q: 还是说，一分区对应一个表，不确定每个表要多大空间？
A: 所有表在一个分区中，应该没啥问题吧。。


4. 很多公司，不都把数据库，当 kv 库用吗？

上面说的，读写一条数据、并发读写多条数据、扫表等，能覆盖大部分场景了？

把这些做到极致，应该就是很多公司心目中，天底下最好的数据库了吧。。


5. 大佬觉得，是其他什么功能，阻碍了数据库，导致其连固态速度都跟不上呢？（要跟上，就应该做到 100W 随机读写）

是加锁吗？每次读写，都要遍历锁列表？还是这个锁实现，是 B+ 树节点上的？粒度有点大？

还是啥功能呢。。

水印有这么差吗？

不是说，电影院里，像素贼差的偷摄，都能知道哪家电影院、场次、座位泄露的吗？

https://i.imgur.com/F29pmQ6.png https://i.imgur.com/F29pmQ6.png

@sagaxu #17

说错了，扫百万条数据，有 62500 个叶子，78 个第三层枝干（假设主键 20 字节 / 个，每枝干能有 800 主键）

@sagaxu #17

1. 如果解析每个 SQL 很耗时，为何不缓存执行计划呢？

难道相同 SQL ，还会因为参数不同（ SELECT ... WHERE id = ?，参数是 123 或 456 ），执行计划大相径庭？


2. 如果是四层 B+ 树（足够容纳 80 亿行了，缓存前两层代价 10+ MB 内存），算上索引，也才 4 ~ 5 次 IO ，40 ~ 50 us ，应该也不多呀。。

如果要同时请求 64000 个数据，也只要放队列里，提交给 SSD ，就能一次性拿完了呀。。

如果是扫表，在遍历 B+ 树时，就知道会分布在哪些枝干、叶子上。也是放队列里，一次性就能拿完了呀。。

而且一个叶子就有 16 条数据（假设 1K / 条），扫百万条数据，只需 62500 个叶子节点，最差情况也是 62500 个第三层枝干节点，两次队列 20 us （前两层已缓存），应该就能拿到了？


当然，以上是我设想的，理想数据库应有的性能。。达不到，业界就不应该说《数据库没有提升空间了》。。

@815979670 #23

BLOB ，存的是 zstd 压缩后的二进制数据。


噢，如果要全文搜索，存压缩后数据也没关系的。SQLite 的 FTS 支持无内容表，只要你添加/删除时，提供了压缩前的章节内容，就行。

但搜索结果只有 `章节 ID`，还需要回 `章节表` 取数据解压。但搜索服务，一般都会分页呈现结果，所以不会一下子解压几万个章节出来。。

一下子解压几万个章节。。可能也没事？过亿数据，都能四五万随机读并发，命令行里 zstd 用词典，单线程解压那 14000 章节文件，也才 0.9 秒。。还是六七年前的轻薄本了。。

@abersheeran #10
@815979670 #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 ）