我可以合理地期望每秒向MySQL服务器写入多少次?

我们正在运行一个定制的广告服务器解决方案,在某些情况下,我们在MySQL中存储和递增递减计数和汇总值,以进行优化。

我知道在MySQL中保存计数并不理想,尽管我并不100%确定为什么。我的猜测是,在磁盘上的写入速度比在内存中的写入速度要慢,所以将计数保存在Redis中会比保存在MySQL中效果更好。但这将给我们的系统增加几层额外的复杂性,并且意味着在多个组件上的严重变化。

在过去,我们看到连接数堆积如山,CPU利用率也在上升,但在缓存了大部分请求并切换到更快的磁盘后,我们已经成功地将这个限制上移。目前我们每天处理的请求量在1000-2000万,采用的是主从MySQL的配置,其中写是发给主服务器的,而大部分读是由从服务器完成的。另外,再增加一个从属服务器也完全不是问题。

我担心的是主服务器上的写入,虽然它们只是在5张表中各增加一行的微小操作。

所以我的问题是:根据你的经验,我可以期望在MySQL中每秒安全地执行多少次这样的小写操作才会达到极限?我听说有人同时处理10万个连接,但如果这些连接都试图在同一秒内增量一行怎么办?在需要的时候,有什么好的策略来扩大这个规模?

谢谢!我们正在运行一个定制的广告服务器。

解决方案:

对于InnoDB,你可能用SSD就可以了。

20M UPDATEs 每天=230second;如果有峰值,则更多。

旋转磁盘(HDD):每秒100次写入。

固态硬盘(SSD)。 可能1000秒。

批量 INSERTs 运行速度更快。

RAID的某些变体运行速度更快。

带有电池备份写入缓存的RAID控制器运行速度非常快(直到缓存饱和)。

对于保持 “喜欢 “或 “浏览量 “或 “点击量 “来说,它是 可能 最好将计数器与其他关于页面产品什么的列分开放在一个表中。 这样一来,更新计数器和处理其他数据的干扰就少了。

有几个设置可以考虑调整。

innodb_flush_log_at_trx_commit = 2 (权衡速度而不是安全)

sync_binlog = OFF

将多个动作合并为一个动作 BEGIN..COMMIT 事务。 但要谨慎对待死锁等问题。

也许你说的不是100K 连接? 这是一个巨大的数字。 超过几十个正在运行的线程(不考虑睡眠线程的数量)是相当多的。

另一种计算点击的方法是不实时记录,而是每隔一小时从Web服务器上刮取一次日志。 有一个单独的进程来计算这一小时(或每5分钟或其他什么)的所有点击,并将其转化为一个单一的数字,以馈送给一个 UPDATE. 这对于一个单独的服务器来说,工作会比较多,但是对于数据库来说,工作量非常小。

给TA打赏
共{{data.count}}人
人已打赏
未分类

如何在UITableViewController中显示navigationItem.leftBarButtonItem?

2022-9-9 2:01:20

未分类

在预构建事件中设置环境变量,并在编译步骤中使用。

2022-9-9 2:12:16

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索