@xxss0903 #6 这年头，还有这么多支持 XP 的主板、CPU 吗？

超出年限这么多，也不更换吗？不怕机器故障坏掉，数据出错啥的吗？

@fengYH8080 #27 《汇总实时余额 = 上次汇总余额记录 + 上次汇总时间点之后的流水累计余额》，

像上面所说，每天汇总一次的话，23:00 时，当天有 1.66 亿 笔未汇总流水。那计算一次余额的代价，是不是太大了。。



@sujin190 #26 是第二天内，能花无数笔 <= 1W 的钱吗？还是累计最多 1W 的钱？

前者不可接受。后者怎么实现呢？每一笔支出，都检查当天流水吗？像上面所说，23:00 时，当天有 1.66 亿 笔流水，这。。https://i.imgur.com/krir4IG.png

另外，商户看到的余额，也是（已清算 1W 余额 + 当天 1.66 亿笔流水余额）吗。。这。。https://i.imgur.com/krir4IG.png

@fengYH8080 #21 每一笔支出，都需要余额吧？否则咋知道，能否继续花钱呢？


@sujin190 #15 意思是说，只能花已清算账目后余额内的钱吗？

如果每天清算一次，清算后还剩 1W 块，第二天可以花无数笔 < 1W 元的支出？

还是说，23:00 的一笔支出，需要计算（ 00:00 ~ 22:59 的余额 + 已清算余额）>= 支出金额，才能花钱？

按楼主所说，每秒 1000 笔收入 / 支出，那该笔支出，就要算当天 1.66 亿次交易，得出未清算余额？？？


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

@glaz 用高性能机子，直接在数据库上操作，可行吗？


啊哩云的 MySQL 测试[^1]说：

- 1 核 1G 机器，MySQL 能 6200 读 / 秒，1800 写 / 秒。
- 16 核 64G 机器，MySQL 能 7.6W 读 / 秒，2.2W 写 / 秒。

第一种小机子，支持你 2 个类似商户，每秒千次收付款，
第二种大机子，支持你 22 个。。


[^1]: https://help.aliyun.com/zh/rds/support/test-results-of-apsaradb-rds-instances-that-run-mysql-8

@BarackLee #4

1 核 1G 的机器，MySQL 能跑 40W QPS ？

还是 40W Q/Minute ？即，6000 QPS ？

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

不懂就问，`d.set('name', 'tom')` 比 `d['name'] = 'tom'` 好在哪儿呢？

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

@supergeek1 #9
@PRStarDust #11

小米三指划一下屏幕，就能截图了。。

@icaolei #175

查了下，烟民有 3.5 亿，司机有 4.8 亿，B 站月活用户 3.4 亿，应该是同一数量级的呀？

其他文字图片站，带宽需求比视频站小多了，影响应该不大？

@old9 #168 同意。

很多人以码率为准，真看到二十多年前 10 Mbps 的 480p MPEG2 的 DVD ，还看得下去吗？

我挺推崇更小码率，达到更好清晰度的。（是叫《高压》吗？）

@icaolei #167 烟、汽油等税高，好像也没见禁止讨论呀。。

甚至还经常见到，航母是烟友抽出来的这种说法。。

带宽为何就特殊了呢？

@rick13 #76 挖到就挖到呗，烟、汽油等税也高，也没咋样呀。。宽带又能特殊到哪儿去呢

@tool2dx #51
@winterbells #130

对平台来说，转码成本还很高昂吗？

发展了这么久，还没有高质量硬件转码方案吗。。

民用最舒服的，是 Intel 的核显了吧。。能媲美 x265 medium 质量

@frankkly #53

他呼吁提高码率，部门不是有望能多收带宽费吗？

为啥还要他下架呢。。

@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 数据库维护起来挺费劲的》

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