你的第二句话，好像不太通畅。

以前我们有做过利用 redis 批量写 db 。
拿 redis 当 buffer 用。
逻辑基本是手搓的。redis 只管 SET ，定时会用 SCAN 扫，都是时序数据没有 update 。

不要问为啥不用 kafka ，甲方有安规，kafka 被卡供应了过不去。

1. 少做无用设计
2. 少造轮子。

然后分析场景：
问 1：数据收集到后，是否需要有各种处理和校验
问 2：数据接收到后，时效性要求是什么程度
问 3：数据格式是否是时序型数据，有没有高基数问题
问 4：数据收集后，用来支持什么服务

预先做几个回答
海量打点采集，时效性要求一般都很低，所以此类业务都是入队列(如 kafka ），再攒批次，写列存/写时序库。
秒 10w 行，就得看每行多大了。clickhouse 单机 16 核心写速到 200mb 没啥问题。
至于时序库，这东西有门槛，除非是场景化很强烈，不然都不太推荐选用。尤其是 prometheus/victoriametric ，一旦有高基数，资源占用很难控制。
常规来说，这类数据都是拿来做聚合分析，时序库在一些方向的分析很快，压缩比也很高；列存更通用些，也看设计。

Explorer 卡死，要么是什么软件加了钩子，要么是硬件初始化比如机械盘起转

1. 设备兼容性。你不能要求用户不使用老设备，也不能要求老业务组去升级基础设施（真的会死）
2. 证书轮换，项目各种奇葩部署方式导致证书根本收不上来，难不成每 2 个月就要到七八个项目组二三十个证书轮换点挨个去轮换？
3. OCSP ，Lets encrypt 的 OCSP 经常被墙，导致 ios 用户首次请求直接寄（超时 10s ）。
4. 业务多了，Lets encrypt 的免费单域名不够用，通配解析又存在分发问题（参照第二点）。
5. 安规，你以为买 OV 和 EV 只是个证书？其实买的是审查和设计。

问出这个问题，难道没赶上 Lets Encrypt 更换根证书的时候吗，证书只是运维的一个小部分，没有人天天能盯着这么多东西的。
至于说做好监控，或者自动 acme.sh ，现实情况远比梦里的复杂，你觉得是雇个人天天盯着成本低，还是直接花几千块钱买个证省下一年十几个 (人/日) 成本低。

想的话，必然是 golang ，python ，scala 。
但实际写起来，还是 java 和 nodejs 最熟悉，最终还是会选传统派

啥顺手选啥，选熟悉的，不选(政治)正确的

机器都睡眠了……
你还指望用户进程的 ssh 端口转发活着

快递小哥睡着了，还能派件吗

建议写 c
只会 panic

运维功底差，考虑 windows server
运维功底差，考虑咸鱼买个 黑群晖安装服务，找人代装
运维功底有些，考虑基于 debian 的 openmediavault ，全开源可控

量极大，TrueNAS ，得有运维基础，不好伺候，纯 nas 产品，最好别搞幺蛾子，连 docker 都别折腾

其余，啥都不要

问题不是一个。
1. like 优化的问题，上 ngram 分词索引，限制最短 like 字符串长度，n 越大效果越好，能效很强，n=4 情况下索引大概是 5 倍存储
楼上有 pgtrgm ，这个也是种 ngram 分词索引。
#86 说分词无法解决这种精确问题的，ngram 这种暴力分词手段专门破这种局面，

至于，ocr 的结果要模糊，记得一点，like 不是搜索，搜索要多关键词权重匹配，上 es 最简单

2. 归档数据也要查，这个自己业务上区分查询口，长期的数据归档到列存，clickhouse/doris/hive/iceberg 都行，主要是查询引擎用啥。至于速度，看表设计
哪怕用列存，like 这种场景，该上 ngram 也是要分的，无索引速度上不来必须要成为基础认知

实际业务，一般是交由风控 ban 了客户 ip
至于穿透，硬干的多，水文方案没见几个落地的

先考虑好是计费还是付费，这两个方向的账期、汇率参照点，基准值思考方向不同


计费一般来说和自身成本挂钩，是折算到某个币种上产生固定币种的账单。
预付费和后付费，账期和扣款时间点不同，一般是设计成支持负数的、带币种的钱包，
预付费是充值，后付费是先扣款到负数再充值。
结算时，该扣哪个那是业务考量

汇率按充值时间点计算，这样把汇率复杂度限定在系统边界

至于使用哪个币种，一般是按公司结算账户，或者按成本货币

要不，优化优化文档？
这文档看了不止一圈，也没搞明白 casbin 和 casdoor 咋配合使用

casdoor 的 sdk 只给了登录相关，但页面有模型配置，难不成要用 casbin-jdbc 适配器直接对接？
若是前端鉴权，难不成每个都用 API 发 enforce ？
基于 API 鉴权，前端想要拉取一个列表用于动态路由，没有接口啊。
给的五个 API 分别是，enforce, 批量 enforce ，剩下那仨到底是干啥的？

还有 casdoor 的配置，也太麻烦了，各个配置间有依赖，需要讲究顺序，但文档哪里提了这个东西，暴力的摸索半个小时过去，一套流程都没配置出来

最蠢的是，sdk 都不给 API 文档的，想知道有啥功能还得去翻源码……

加群也是跳来跳去没个回复，

@wxf666 sqlite 这属于单节点玩具 db ，对于并发性 web 服务，是跟不上用的。
并发访问，就成了两种情况，1. 串行排队，2. 程序内实现类似于 db 的 buffer cache

至于 duckdb ，这东西底层是列结构存储，读取需要解压，不适合并发访问，也不适合频繁写入。
duckdb ，和 sqlite 一样也是进程级，对于并发性 web 服务，也是一样的毛病。

#39 做的成本估算，有些细节可以调整。
OSS 和服务器的流量成本均应采纳 CDN 价格，不过按经验上看，CDN 回源也要再算，比较麻烦，流量成本占比低时没啥必要。

最优方案还是 OSS + CDN 存放 zstd 压缩后的文件。zstd 压缩使用小样本预训练词典，词典随客户端下发。
至于传输，zstd 压缩后，不要再计算 gzip 之类的量。

还有，算流量别算那么精确，oss 对于小文件有对齐，2kb 塞进去也会按 4k 计算(标准存储)，而且访问 OSS 是 http 协议，头部塞了一大堆东西，几 kb 的文件算不准的。

至于整本存储，lzma 依然不是优化方案，还是首选 zstd ，新代的压缩算法几乎是全方面碾压老代。
这东西参数很多，把 level 开高压缩比不错，解压速度也可以。


当然，若是私有云自建，这方面有个优秀的方案，HBase + HDFS 。


#77 提到，sqlite 100g 1.3 亿数据，1w 随机写事务，这种测试没用，这数值是 WAL 的数值，而且是无事务写。

顺便再补个，我们做大规模爬虫类任务，是 crawl 爬后存文件丢进 DFS ，再有独立中间件提取再入库。至于入什么库就看情况了，多数是 kafka 。
再有服务消费 kafka 进行分拣、清洗、预先处理，按业务分类入业务库。
所以，什么并发写之类的都不存在。


#77 还有一个，支持多少并发写，占用资源问题。
对于 db ，mysql 也好 pg 也好，并发写并不是大批量导入的最优解，大规模数据导入是靠 batch ，而不是并行。
以我们的经验，mysql 导入 100w 行，字段 50 ，行均大小 5k 左右，单并发写速到 1w/s 不难。


至于题主，大概率是个新入行没做过项目的年轻人，脑子里想的都是不切实际的笑话，甚至还想搞 redis 缓存，也不知道缓给谁看的

oss ，唯一选择。
云上的存储单价，你拉出来列个表。
例如你说的，存到磁盘，吞吐量有多少？吞吐量能到多少？
oss 密集操作网络 IO 开销大，但你考虑过磁盘能吃多少 IOPS 吗，云上的话这个比 OSS 成本要高。
对于这类业务，OSS + CDN 是最优选择，服务器只管授信，流量走 CDN 自然分层，存储有对象存储便宜大碗。

若存储量到 pb 级，可以私有云自建，进一步降低成本。
自建 CDN 源站，存储自建分布式存储，比如 seaweedfs ，小说分块 + 压缩后，都是小文件，不适合 hdfs

非联网的单机 db ，oltp 用 sqlite ，olap 用 duckdb ，都是王者级

若是适配麻烦，postgre 也有 embed 版本，mysql 也有但很难搞不推荐，mysql 试着用 h2 平替，只是兼容性很垃圾。

参见文档： https://dev.mysql.com/doc/refman/8.0/en/numeric-type-syntax.html

是个历史因素，自 8.0.17 已经标记弃用，后续会移除

已知：索引直接命中，直接出 10 行，查询速度 150ms
你得检查下索引命中情况了，150ms 听着是有 SCAN 的速度

后续表数据量上涨：基于网传 2000w 分表原理，多一层 tree ，实际差距大概是 ms 级的，也就是误差不足 1%，且打满 4 层以前速度不会变。

查询 qps 在 100 左右，索引抽 10 行，这种负载堆到 10 亿也没啥

坏道测试其实价值不大，尤其是 dg 这种不标时间的
smart 为主

授权是个麻烦玩意，尤其是既要又要，还不想遵循现有标准，更麻烦了
spring security 就是个超级大一统框架，要啥有啥，要啥都麻烦，毕竟起夜级定制太多，也能理解
小项目，这些都屌用没有，找个新一些热门一些的库按基本流程去掉一切定制想法，差不多就是 OK 的了