图片格式错误 重新补一下

陕西电信 4g 城区测速
[]( https://imgse.com/i/pAYdSOI)

vivo Y300Pro 除了 CPU 差点 其他都不错，6500mah ，父母没有高帧率使用场景 够用了 vivo 系统 也是第一梯队的

@Rrrrrr 首发肯定原价了，不着急就等等 肯定能便宜，着急的话也可入 毕竟 IQOO 子品牌 不会太贵

目前 iQOO 13 手机部分配置如下：

性能：高通骁龙 8 至尊版处理器 + 自研电竞芯片 Q2

散热：单层主板 | 全新散热架构和 VC 散热板

屏幕：2K BOE Q10 纯直屏（首发京东方最新发光材料）

电池：6100-6150mAh± | 120W 私有协议闪充 + 100W PPS 公版闪充 | 旁路充电 + 高功率亮屏快充

功能：单点超声波指纹 | USB3.X | IP68 | 大尺寸 X 轴马达

设计：iQOO 13 厚度是旗舰系列历史最薄 | 直边大 R 角中框 | 前置挖孔大小优化 | 大尺寸对称双扬

外观：预计采用直屏 + 窄边框 + 金属中框设计 | 类似 OriginOS 视觉展示机型

影像：vivo 旗舰同款主摄、广角，折叠屏同款的长焦人像，蓝厂旗舰同款算法和调试

就看价格了
来源： https://www.ithome.com/0/800/745.htm

高速吹风机，
买之前 我现在的吹风机 30 多一个 你凭什么卖四五百
买之后，真香

1. 多个蜘蛛写入 SQLite 如果小说是以 每本小说都是一个 SQLite 的维度存储时，这不是问题。
如果存储多本小说 或者 同一个 SQLite 文件有多个线程写入，可以通过 批量写入的方式实现， 我前年测试 SQLite 写入性能 15w 数据耗时 5.13 s ，完全可以满足需求

2. SQLite 只是小说内容部分的存储方案，项目中 会员信息或者其他操作 还是 mysql/pgsql

@ShuA1 SQLite 可以并发查询 而且性能很高，只是不能并发写，对于小说这种 只在后台更新，前端用户并发阅读的 特别合适，甚至很多项目都用 SQLite 做缓存

抖音 快手 经常有一些 山寨 app 的推广，刷 xx 时间可以提现多少钱，类似于 pdd 那种 先给提现几毛钱 或者几分钱，接着要刷够 100 或者 200 才能提现（实际达不到 不可能提现）。

反正老一辈人犟得很，不让他装他又不听，装的话 抖音 装一个山寨 app 一个山寨 app 繁衍十几二十个 app ，就这么乱起来了

@abersheeran 那确实挺合适，小说更新和不会再修改 并发读取又是 sqlite 的强项

realme 算了吧 给家里买了两台，做工太糙了

@wxf666 没必要 存储的日志从设计上考虑，只允许通过这个程序读取，所以只要能实现 压缩存储、按时间检索展示就行

@wxf666 其实也没有分析一说，就是一些普通的运行日志，只有出现故障后根据时间戳检索，在展示的时候解压显示就行

我记得开发过程中有一个 ”铁律“：不要自己 ”发明“ 加密算法，包括但不限于 两次 md5 这种 将已知的加密算法连续使用多次，它们并不会提升安全性，如果需要更高的安全性，请直接使用加密等级更高的算法

29 楼更正一个错误 DuckDB 汇总数据是 200ms 0.2 秒

@wxf666 忘了 @了 看 29 楼

DuckDB 挺早就注意到了，出于两个考虑没有考虑使用：
1. 项目的开发使用的是 Go 语言，主流的 Go-duckdb 库 ( https://github.com/marcboeker/go-duckdb) 依赖 CGO （无法跨平台编译 这个对我很重要），有一个不依赖 CGO 的 ( https://github.com/scottlepp/go-duck) 但目前只有 8 个 Star 不太敢用在项目中。

2. SQLite 发展时间很长，经过了时间的检验，并且官方也提到了对损坏的数据库文件也尽可能的提供了读取的支持，无论从性能、兼容性 、生态 等多方面考虑，它仍然很能打 并且在我这个场景中够用。而 DuckDB 我自己做一些新技术探索时也尝试过 性能确实可以（ 2000w 行 csv ，就纯 csv 没索引那种，汇总数据特别快 只用了 0.2 毫秒），但毕竟是一个新东西，可能 一两年后的项目中会考虑使用吧（让子弹飞一会）。

日志存储倒不是流式存储，项目中会有一个专门写日志的组件，不管哪里的日志都丢给 这个组件，先缓存起来，再按照一定的规则批量写入 SQLite 落盘（我之前测试过 SQLite 批量写入性能 https://www.dbkuaizi.com/archives/154.html 15w 数据耗时 5.13 s ），所以写入不存在问题。

@wxf666 谢谢 回复非常有参考价值，我计划用 sqlite 存日志，配合压缩使用 目前未压缩数据一个月有 400G 左右，压缩后体积应该能小压缩到 35% ~30% 左右

第一次了解到外置压缩字典的用法，对于高度重复，量又大的日志文件应该很有用（任务单次日志输出 3MB ），之前我还在担心每行独立压缩，压缩率可能不高的问题