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

@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 主键）