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

两个简单的方案
1. 多个数据库来分担写入
2. 写到 csv 文件里，再用 LOAD DATA LOCAL INFILE 语句把数据载入到表中。

@realpg

过份的谦虚是对人的藐视。

8 NVME 盘 RAID10 高性能的数据中心级 NVME，二代 E5 双路，配 1.5TB RAM 。这配置叫垃圾？

我别的不说你这配置，按照 DELL R730 计价，少说 10 万一台。按照阿里云计价。没有。

从数据层面 来看也就是说你的表最多的一个也就 800 万行。在你的超强配置下并且充分 的利用了优化，撑住。

@realpg 另外我很好奇，什么样公司的机房的垃圾库存有如此牛的机器当垃圾存在。而且既然当垃圾了还能够当生产系统用

同时我也很好奇你的备份方案是什么样的。

大数据团队是怎么和你对接数据的。你这么频繁的加库加表，大数据团队也撑的住折腾。

请教请教。

@594duck #83 二代 E5 双路，你看看 E5 现在出到几代，就知道是不是洋垃圾了……

@realpg #80 1.5TB RAM 开机自检得多久……

@goodspb 我看了一圈下来，只需要前 100 的话，不要用什么 mysql 了，直接 redis，每条数据给一个 2 小时 expire time 完事儿。随便 update 。整体来说你这个降级也就在一两千万条数据，redis 轻轻松松。你这个典型的 in memoy db 的需求用 mysql 不是给自己找不痛快。

这里是需要拆解需求吗 后面的 2 分钟后更新增加了算法的时间复杂度(菜逼理解大佬别骂我)

怎么感觉刚刚才在知乎上看到这个问题

@privil 对数据库来说多核 没有高主频有用。所以哪怕是二代 E5 高主频带来的优势更强。

另外我还是很好奇你怎么做备份怎么和大数据团队对接，以二代 E5 的寿命来看，你简直是在玩火。如果一理有问题挂了，你又找不出同样的洋垃圾，你带给公司的灾难身为前运维总监我是不敢想象的。

这用啥数据库 直接打 log 好了
这啥需求 不能在查看时候再算过去 100 条记录？

@privil #85
如果不按 ESC 中断自检层 MEMTEST 的话，要很久很久很久很久
如果按 ESC 中断自检层 MEMTEST，做普通内存自检，大概 7-30 分钟，时间比较不定，可能是某些内存有响应不好的问题
这机器基本不重启的……


@594duck #83
公司是数据中心啊
都是按需买的
机房里扣除形象项目 政府项目啥的 90%是垃圾服务器在跑应用……


@594duck #83
大数据团队？不存在的。这只是我的一个自己的小私活而已。

备份方案？应用层备份。每时每刻分布式备份，以及后半夜备份。因为应用特性导致非工作时间的直接操作性业务压力极低极低，不是关闭服务，是没啥人用了，加班的以及圈子开源部分测试 /研发团队在实际使用。后半夜有 2 小时，所有分布式任务全部停止，只保留对零星用户的服务，同时 MYSQLDUMP

@594duck #89
找不出洋垃圾？我机房现在 E5 二代 /一代的服务器大概有六千多台，每个月还新采购 100 台左右

腾讯什么的 CDN 转包那边甚至全是 1366 平台居多，2019 年 6 月份以后新增加节点才大肆上 2011 的机器

1366 的机器而论，大部分出厂日期是 2009-2010 年，我这边 2016-2017 左右采垃圾然后用于生产环境，这批机器，基本到 2020 年左右才开始逐渐影响应用的故障率稍微多一点，所以开始演进往 2011 平台走，现在新采购以 2011 为主，偶尔赶上大批量极其便宜的 1366 还会搞一些，反正自己应用很多用得上的地方

至于你说的寿命，你对硬件寿命真的，一无所知……而且你对捡垃圾这个行业也一无所知。
用 E5 二代平台的原因，主要是内存便宜。1.5TB 是这一代的内存极限，低于这个的也满地，因为廉价内存而已。
DELL 的十三代平台，垃圾渠道已经开始流通了，最大的阻碍是 D4REG 和 D4LRDIMM 内存太贵而已


比如吧 你现在天天看的国内大视频网站，他们最大的分发是廉价采购的多重转包的资源回收，这部分，基本全是在用 1366 的机器在跑（因为成本低）。


比如，我现在机房有一个小项目，某知名视频站的大概 80Gbps 的分发，16 个机柜，每个机柜 12 台服务器，共计 192 台服务器。
因为这个项目是最近谈的，直接从备用机里提了 192 台 R720xd，客户对 CPU 和内存要求不高，所以上的 2640v2 双路，64G/128G 内存，每台机器 12 块 2TB 垃圾 SSD+魔改 H710 为 HBA 。没几个成本。


如果这个项目要是 2018 年接的，那么基本上当时就是配 R510/C2100 这种机器+双路 L5640+48GRAM+2TB*10 了

@realpg 我大概明白你是做什么的了
主库这么大没有从库，靠 DUMP 备份，根本不谈业务 SLA 了。

另外根据自己使用经验，DELL R 系列服务器在 3 年后的故障率极高 5 年后主板故障率也极高，你跑的业务是 CDN 7x24 小时高负载，2009 年的服务器你说要到你说要到 2020 年才出现 高故障率.以我自身的经验是超出的。

有特例么，肯定有的，什么跑 7 年的 DELL 服务器我也见过。但是 DELL 自己认可也就 5 年，从 DELL 的续保策略上是可以看出来的。

另外我确实不捡垃圾，以我们正规业务来讲，SLA 99.94%是最低要求，捡垃圾带来的收益 根本没必要。所以我明白你的业务场景是 CDN，不需要稳定只需堆量和便宜。

这和企业业务场景一致么，和企业 SLA 业务场景一致么？

@594duck #92
不是 CDN 啊 啥场景 这些机器的 SLA 可用性都高于四个 9

而且，大量的业务可用性是用 HA 机制保障的

我不知道你经手管理过多少物理环境在标准内的大批量设备
硬件故障率，不含硬盘，远没有你想象的那么高

首先是基于用户的操作，那就可以基于用户 userid 进行分表操作。这期间可以起队列进行消费。mysql 只需要保存最近 5 分钟数据的话。可以在用户 userid 分表的情况，增加时间段的维度进行冷热数据的过渡。

这里边牵扯到数据部分归档的问题。

@realpg 这和主题无关，但是 dell 自己都说超过 5 年的服务器是非常不稳定的不推荐的。你竟然说 4 个 9 。

你知道 4 个 9 是什么概念的。

写还是用 mongodb 吧