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 的了

oltp 业务，时间和扫描数据量基本成正比
你这个，扫描数据量上亿，咋个快法？
olap 业务，时间和扫描数据量也是成正比，不过可以通过只扫描必要列、并行扫描多 chunk 并行加速、跳数索引(减少 chunk 数量)、预聚合(无需扫描原始数据)、块压缩(减少 io 时间)等手段来变相超车，减少实际扫描数据量。

分库分表，若依旧单并行顺序执行，不过是把工作拆分，最终时间不变(不考虑 cache)。
若并行查分表，那就是上面的多 chunk 并行加速。

新些的库，比如 polardb ，不开 imci ，只选择并行化，也可以实现相同的效果


mysql ，一些统计性质的聚合函数可以通过索引，能实现类似于“只扫描必要列”的特性

至于你举例这个 sql ，除了有列存优化的库，应该谁跑都差不多才是，都慢