每一分钟写入 10 万行数据，有啥好的方案吗？

@goodspb #19
一分钟十万条，多久删除记录？
感觉你这个数据库存储文件很快就会过 PB 的样子……

感觉什么业务模型都在楼主脑子里 然后有价值的数据和业务模型啥也没说……

@realpg #61 多久之后删除还没思考好，反正只保留当前时间往后推算的 100 条数据，其余的可以删除

@goodspb #63
仔细看了下你的全部回复并整理到一起
你这需求难度真心不大
只要数据来源层和写入数据库这两方面都可控


比如用时序数据库，改造查询报表部分，反正就 100 条数据，不要依赖 SQL 语法，直接取出全部数据用算法去计算汇总

用 KV 替代时序数据库也可以，同样改造报表部分

如果保留 MYSQL 本身，可以改变入库操作，采用 UPDATE 式入库替换掉 INSERT 入库（类似用逻辑实现 MYSQL 模拟时序库，代码方便改用代码，代码不方便处理用触发器） ，然后存储设备用高 IOPS 的 NVME 盘，或者干脆引擎用 TiDB，三副本全用 NVME 盘

方案多得是，但是更细节的东西，以及生产数据，就不是随便上网问一嘴就可以白给的了

应该是带 compaction 的 lsm tree 系的数据存储场景

"有一个业务，如果用户开启了就需要每分钟给他生成一条数据。所以 10 万是我看实际用户量的预估值"

数据应该是每个客户定制生成的吧，客户和客户之间的数据应该不是共享的吧。 这种需求一般就不写库，根据每个客户的 ID 对应一个缓存文件（你这个 1 分钟 1 条数据，1 天也就 60*24 很少的数据量）， 直接写缓存文件， 取的时候根据用户 ID 取对应文件。 写数据 /更新业务直接微服务上容器，自动扩展，如果 1 个容器可以同时更新 5W 个用户数据，后续用户大了，动态部署这个微服务。文件直接用企业级的 NAS 也可以用云运营商的云盘文件也可以。这个开发完，直接加钱买机器就可以扩容。

有个东西叫时序数据库, 对于这种有明显时间特征的数据很适用, 不过时序数据库一般对 update 不友好, 可以先入 MQ , 处理完成后入时序数据库

搜索一下「时序数据库」和「列存数据库」

mysql 分库分表不行吗

防火墙日志，目前存在了 MYSQL 中，一秒 1000 条左右，1C1G2T 虚拟机

具体要看啥数据啊 日志型的分表完全没压力啊

@snoopygao 你敢查么。

存谁都敢，查一下试试看，特别刺激。你这应用和 zabbix 一样。zabbix 就是出了名的写优化读等死。

@csl1995 #55 老哥的回答真的懂行。这其实是有个算法，我们粗暴的归在如果超出 1000 基本就走全表了。 所以他这程序 update 一次那真叫刺激。

@594duck #73
你这个归纳显然是有问题的
不信你弄个百万行的表试试……

我这里最暴躁的一台 MYSQL，单机……

https://imgur.com/Zu24WLu

这个 TPS 主库换好机器单库也基本能抗住了，就是稳定性比较差。而分库分表之后就应该没压力了呀

优化业务吧，从单个用户的数据入手；

@realpg 写,和 update 最多的表有多宽。目前库有多大。什么配置

@594duck #78

自己拼的垃圾服务器 从我机房堆里翻出来的

读写密集的数据库是全 int 表，不存在字符串，字段数极多

主要业务场景是 INSERT 进来，受限于数据不是本机软件生成，一个 INSERT 只有一条记录一次 commit，所以写查询比 delete 查询数量多，delete 都是按有效期一次删一片

基本 insert 进来的数据有效期是一天，大量分表，没分库。分表依据是基于应用逻辑的，而不是基于数据的算法分表，所
以表行数不均匀，比较少的表几十万行，比较多的 800 万行左右。

数据每天增加的量大致差不多，insert 时间不分散到每个小时，而是按一定逻辑分散。

insert 进来的数据要保存 72 天，之后删除，删旧的，保持数据库内基本保存 73 天的有效数据

删除是我自己写的分布式删除脚本，分散到一天 24 小时除了备份数据时间段的每时每刻

update 是表内数据的主要逻辑，基本主要操作都是 update 一条表记录为一个临时状态值占用，而不是用事务行锁。

存储配置是 数据盘 8 NVME 盘 RAID10 高性能的数据中心级 NVME
机器是洋垃圾二代 E5 双路，配 1.5TB RAM