只说 1000w 数据点，还得考虑这 1000w 条是什么格式。
json? kv? 还是什么
写入是流写还是批写
写入时效性要求是多少。
机器内存 32g ，网卡呢，1000w 行数据若是大点，千兆网卡必爆的。

那你就 clickhouse 呗，4c32g 能跑很多东西了。
小内存建议缩缩参数，参考 altinty 的手册

https://kb.altinity.com/altinity-kb-setup-and-maintenance/configure_clickhouse_for_low_mem_envs/

300w 个商品，1000 个客户，sku 总计 30 亿以上，你比 amazon 规模还大。
淘宝十几年，估计也就这数量级吧
都这规模了，要不去硅谷挖几个人吧
哈哈哈哈

不太长看 v2 ，许久后回复。

redis 和 db 异构，必然得面临数据不一致的问题。
redis 是 KV 型存储，没有足够的描述结构。

我们当时的方案，是有个针对的，就是只用 redis 存储 IOT 报文，业务上没有 update/delete ，纯 insert ，所以只是针对 key 设计就够了。

没有用 kafka 主要还有个问题，业务侧有明细数据查询的时效性需求，给的指标是端到端不超过 2s(从 iot 网关开始计算，实际上是不合理需求，但甲方爸爸……)。kafka 其实是守不住 2s 的，所以用了大把的 redis 写。
数据 set ，数据对应的一级索引 hset 。
设计两个 key 就行，然后有 batch 任务每隔多久来扫走并删除相应数据（ redis 最多存 2 个时间窗口，batch 扫走第二个，删掉第一个）

至于你们领导的想法，那是扯淡，完全置数据复杂度于不顾。数据库不可用，两个思想方向：
1. 保证数据库高可用，既然 sql server ，那成熟的 always on 体系砸就是了。
2. 若是真的没法保证（成本因素 or 技术难题），数据库不可用就该让他不可用，保证 RPO=0(数据恢复点，就是不能丢数据不能错数据)，然后才是尽量缩短 RTO(业务恢复时间)
不然，照着主库能挂然后靠 redis 来缓解，那么面临的必然是时间段内的数据不一致，

返回 10w ，零散对象就是多。
在任何有必要优化的专门点位，使用原生 JDBC API 来针对性优化，是完全正确且合乎情理的。
所以，遇到此类问题别和框架死磕，直接动用更底层的原始 API 就好。

请参考存储的 321 原则

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

以前我们有做过利用 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 缓存，也不知道缓给谁看的