抖音 快手 经常有一些 山寨 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 ），之前我还在担心每行独立压缩，压缩率可能不高的问题

@wxf666 问一下 压缩后的数据存 text 类型还是 blob 类型？

@abersheeran 能详细说说怎么存的吗，一本小说一个 sqlite 文件 还是 1T 数据全是同一个 sqlite 文件 或者时按照其他规则拆分的？ 压缩算法用的时 zip 吗？ 我之前有尝试用 zip 算法压缩文本 然后存入 sqlite 体积只有原来的四分之一

如果没有全文检索需求的话可以压缩存储，web 场景下 cpu 资源很多都是被浪费了（常年在 20%以下），可以通过压缩利用起来

如果有人用你的开源项目做违法的事情了，你会被请喝茶的，gin-vue-admin 作者就被请过好几次，项目去年被园区的人员拿去做 zp 的管理系统了

蚂蚁金服的 ob 可以考虑一下 我测试安装了一下 mysql 语法都能兼容

感觉 go 更合适，python 做大型项目不太合适

我能想到的是车载导航的安卓系统？每次打火都是 冷启动 会有这个需求？

网盘吧 百度+腾讯+天翼云 上传不限速，这些网盘服务总不能同时倒闭吧

个人习惯 用上一个子版本的最新版 就是第二位版本号 -1 ，然后第三位最新版