@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 单表亿级别，也不是什么大奸大恶，必须分表。理智点做取舍。个人信奉“分库分表为数据治理最后方案”

@shenjinpeng 大概率业务网关、采集、资源下发
高吞吐下 zgc 省心，下限高。g1 上限更高，下限却不怎样

理论应当框架化，实际自研比重相当大
微服务场景，插件化更重要，让各个服务能尽可能便捷接入。
不过公司内技术垃圾，更推荐丢了煞笔的微服务，

给别人打个广告，权限问题可以看一眼 casbin 这个库，功能比较全面，接入尚且算简单。单点登录(第三方登录)还有它家八竿子打不到的 casdoor ，都挺强悍

不考虑实际应用，暴力破解破万法，但实际这玩意得跑到大道都磨灭了

无论什么要求，降噪耳塞只有 3m ，别的基本不用看

按题目数据量级，大概算下来，一年大概 18 万亿行，磁盘空间应该在 1t 到 2t 之间，写入带宽都喂不满一个单点 ck 配几块机械盘
不过列存嘛，整体结构参考上面 @dlmy 兄弟的描述

就这么点数据，想这么多，又这又那的
这点量都摸不到 doris/ck 单机瓶颈

拿 ck 来说，上面给出 ck 表结构的兄弟，@yjhatfdu2 表排序键有问题，排序优先遵循业务必选条件，再根据基数由低到高。建议调整排序顺序为 country,province,city,time 编码方式里，时间去掉 doubledelta ，追求压缩率平衡不用 lz4 ，改用 zstd(1)差不多就这样了。
你这第一个就是高基数，压缩比会很低，速度上不来

对列存来说，整分区 count 都是 O(1)消耗的元数据查询，看不出性能

至于表分区键选用按日还是按月，需要考虑业务平常查询到底按什么的多些。经常跨度大的就改为按月，反之按日。若是业务有按国家为租户的习惯，那分区把国家带上再按月也合理。
若是还有一些大范围时间内区域统计需求，上 projection 来预计算

bps ，timestamp ，时序性数据上时序专用库也可以，总之比这个要好，现在这用法再怎么优化也快不起来的