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

给别人打个广告，权限问题可以看一眼 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 ，时序性数据上时序专用库也可以，总之比这个要好，现在这用法再怎么优化也快不起来的

统计，建议扔了 mysql ，你这场景不适合
考虑 hdfs ，clickhouse ，再来 10 倍量也能秒查