@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

@GuLuDaDuiZhang #6
@PrinceofInj #11

到时候企业能让 AI ，根据截图，分析员工多长时间摸鱼，多长时间干活了吗？

https://i.imgur.com/krir4IG.png https://i.imgur.com/krir4IG.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 数据库维护起来挺费劲的》

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

@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 ，应该也行了吧。。