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

不要提前优化

@goodspb 假设, 你有很多万的用户, 这 10w 是日活的话, 那么卡死你们服务器 估计不是这个每分钟一条的请求, 而是客户正常点 app 的请求, 那个比 一分钟一次来的更容易崩... 所以如果他正常用都没崩的话, 你 1 分钟搜集一次 妥妥没问题

V2er 们真的虎，动不动 1 秒 1667 条有什么难度，2 分钟后的 update 操作怎么弄。你们说呀，嘴巴动动真的简单。

楼主我和你说，像你这样的数据，能不 update 就不 update,另外你的 update 让大数据团队也难干活。我建议你是走流水一样的操作，这样主库不开索引 ，只管写。后面弄个几个从库只读，用来做业务查询 ，读写分离。

另外你这量级的话，计算一下数据量，我建议走 DRDS 或者类似的 mysql 集群方案，因为你要考虑到将来你的数据总量实在是太大了。

如果考虑未来增长什么的，最好直接上类 oracle 或者 microsfot sqlserver 方案。数据库成熟 ，能力强尽，只要无脑堆机器 就行。（事实证明自己上 Oracle 在五年成本里和阿里的 DRDS 相比并不贵到哪里去，你看一下 DRDS 的报价就知道了）。

同时可以测一下 Microsoft sqlserver 和 mysql 集群的能力。Sqlserver 能力非常强的。

先算下服务器的价格。
要是公司买不起服务器，你这个架构怎么做都没用。

@594duck 写入不成问题，update 只要能恰当的分库分表也没什么问题，这种情况下没必要搞什么花架子，MySQL 完全可以处理，如果要聚合查询，那就弄个从库单独查就行了

mysql 限定死，服务器没给上限，就算玩出花来也满足不了你的不确定数值的需求啊，今天 20W，明天 200W，后天 2000W 。。。。针对不同的需求选择不同的技术，没必要提前满足。迭代，迭代，迭代！

每分钟 10 万条数据，一天貌似就超过 1 亿条了噢，这已经超出我的认知范畴了。

@rushssss 他这数据量，随便 select 一下超出行数都直接转为全表扫描。

有什么难度吗，本地环境，30 万数据耗时 1min 左右，用的是 on duplicate 插入更新操作

而且时间包含，从 mongo 读 30 万数据的时间

用队列+缓存，一天一用户就 100 条，太容易了。

@Varobjs 内容才几行都不看全的吗？ 10 万插入的数据还要马上 update，光几十万插入性能有什么用

建议你先用土办法做出来试试性能，目测并没有太大压力，24 小时也无所谓

@594duck 1 秒 1667 条数据，如果是一个 sql 语句批量插入，的确没有任何问题啊。
如果是 1667 次插入，那会有问题，如果真是这样，那就是业务设计有问题

建议楼主重新梳理一下业务，是否真的有必要这样操作

优化的核心点是：为什么每分钟要生成一条数据，并且写入数据库？
1 、能不能按需生成而不是定期生成？如果可以，估计数据能少 99%。
2 、能不能汇总后写入数据库？如果可以，还能少写 99%。

两个点优化下来，每秒只用写 10 行。

@xuanbg #36
@qiayue #35

本来的方案是按需生成的，用户进来页面才生成。

但是最近想上一个版本，用户不在界面也要生成（主要他选择了他想定时生成）。
然后他还能看到前 100 条记录。

分库分表

前两天写着玩， 把自己阿里云数据库的数据库内容扩大了下。 如果单线程，1s 最多 6 条数据插入，特别慢。 后来改了用多线程插入，单个插入，1s 100 条左右。 如果再适当优化，速度还会上去

典型的时序数据库负载，推荐 timescale，想省硬盘并且不讨厌 go 就 Influxdb 。

timescale 缺点是硬盘空间占用大，有点是内存占用小，没有不必要的多维度索引开销（表尽量简单），历史数据也可以压缩
influxdb 优点是实时压缩率高，缺点是内存占用多，启动慢，go 写的

不推荐其他监控用的数据库，性能差或者为 k8s 监控特化太多。

也可以去买按次付费的时序存储，不会很贵。