想的话，必然是 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 ，除了有列存优化的库，应该谁跑都差不多才是，都慢

建议裸表直接干，扔掉分库分表中间件

真上亿了，有压力了，你会不知道咋优化？

至于上面推荐 parquet 的，最简单也要有 hive ，查也要有 impala/kylin 之类的引擎，不太推荐。greenplum 是个好东西，不过是 pg 体系的，若是你们用 pg 必然优选这个，etl 更简单。
上 es 的，属于屠龙刀杀鸡，查询也存在割裂，需要研发成本，不推荐。
hbase 的，体系很大，若没有已存在的基础设施，也是不推荐。

我提议按日 etl ，有个前提，超过 n 天的数据无法修改。
每次 etl ，要把这个范围内的日期都 drop part 然后重新 insert 。
若你这个 n ，它很大，那每次 etl 运动数据量很恐怖，clickhouse 这个方案也不太行，建议走 cdc 路子

理智点讲，分两种工况

1. 业务正常读写，能正常跑就单表顶多分区，不建议扯太多。分表增加很多管理压力，而不分表只是 ddl 压力、备份恢复压力。当然前提管住手欠的直接无索引查全表。
2. 有范围聚合性统计操作，这类按惯例，etl 一份到 olap 库，典型目标库 doris/clickhouse ，但这个不要做实时，建议按日，业务侧保证不查当日，或者查询业务上区分当日和非当日。极少有业务无法妥协，不妥协那是人的事不是业务的。
3. 若不能妥协，上游“劳资非要任意查不能拆分”，那就要考虑 cdc 链路，若业务存在 update 则不能选择 clickhouse(细碎麻烦很多，虽然都有解法但太麻烦不适合快速落地)，若业务数据量大(日 300w 不算多，稍微多给点资源就当小量)，doris 配 cdc 合并上也吃不消。至于 cdc 也是有延迟的，分钟级的程度，努努力能做到秒级(十几二十几的程度)，资源消耗究极猛

按日 etl 难度不高，落地很快，配个定时跑下 sql 就能完成入仓。

clickhouse 单机 8c64g 配几块机械盘，足够支撑你这丁丁点数据量(我这单点 ck 每天手机号量级写入)

至于 mysql 插入慢，问题可能多方面。根据描述只能建议先切出 adhoc 查询流量，优化查询体验，没法给你解决写性能问题。

顺带一提，mysql 单表亿级别，也不是什么大奸大恶，必须分表。理智点做取舍。个人信奉“分库分表为数据治理最后方案”