专栏首页CNCF为什么Vitess推荐每个MySQL服务器250GB?

为什么Vitess推荐每个MySQL服务器250GB?

作者:Morgan Tocker

Vitess对数据库的可伸缩性有自己的看法。有些观点很少有争议,比如应该如何通过复制提供持久性,但是我发现一个有趣的建议是每个MySQL服务器250GB。

https://vitess.io/docs/overview/scalability-philosophy/

这是物理的MySQL限制吗?

简而言之:不是。我说的“物理限制”是指是否存在文件格式限制,即数据库不能大于250GB?

InnoDB的物理限制是每个表空间(tablespace)64TB,在默认配置中,每个表(table)都有自己的表空间。通过表分区(table partitioning),可以进一步扩展这个限制。

这是实际的MySQL限制吗?

简而言之:不一定。所谓的“实际限制”,我的意思是当MySQL达到250GB的数据库大小时,它会立即崩溃吗?在物理极限之前达到实际极限是很常见的。

这个问题的答案,在很大程度上取决于表结构(和查询模式)。以这些场景为例:

表A:

CREATE TABLE tablea (
 id INT NOT NULL PRIMARY KEY auto_increment,
 b DATETIME NOT NULL,
 c VARBINARY(512) NOT NULL,
 INDEX(b)
);

表B:

CREATE TABLE tableb (
 id INT NOT NULL PRIMARY KEY auto_increment,
 b DATETIME NOT NULL,
 c VARBINARY(512) NOT NULL,
 UNIQUE (c)
);

..它们看起来几乎一样,对吧?让我们试着在32个并行线程中插入行,持续一个小时:

INSERT INTO {tablename} (b, c) VALUES (NOW(), RANDOM_BYTES(512)), (NOW(), RANDOM_BYTES(512)), ..;

表A:1小时的插入性能

在一个小时内,我能够插入1.13亿行数据。尽管最终的表大小(93GB)比InnoDB缓冲池(16GB)大得多,但是插入性能相当一致。我怀疑最初性能的急剧下降是因为超过了SSD写缓存。

表B:1小时的插入性能

插入性能随着表变大而下降。16GB的缓冲池不足以容纳所有重要的页,iostat显示了大量的读/秒,因为需要读取-修改-写入页。最后插入的行数为2900万,表大小为50GB。

为什么这两个表的表现如此不同呢?

c上的索引更宽(512字节vs.6字节),但是随机插入加上惟一性是真正的性能杀手。

对于表A,性能是稳定和一致的,因为插入在表的末尾,所需的页在内存中。我用一个128MB的缓冲池重复了这个基准测试,结果只发现性能下降了13%:

表A:1小时的插入性能(128M缓冲池)

1小时后的总行数为1亿。这与使用16GB缓冲池的测试只相差13%(下表作比较)。

表A:128M vs. 16M缓冲池

在表B中,插入性能在基准测试的运行期间是不可持续的。因为惟一索引上的插入模式是随机的,所以不能保证所需的索引页在内存中。但是必须加载这些页以确保没有违反约束检查(c列必须是惟一的)。

因此,可以公平地说,表B上的工作负载需要比表A上的工作负载更高的内存适合度。我们还可以通过将RANDOM_BYTES(512)转换为插入效率更高但仍然是512字节的内容来提高性能:

SELECT LENGTH(CONCAT(current_timestamp(6), RANDOM_BYTES(486)));
+---------------------------------------------------------+
| LENGTH(CONCAT(current_timestamp(6), RANDOM_BYTES(486))) |
+---------------------------------------------------------+
|                                                     512 |
+---------------------------------------------------------+
1 row in set (0.00 sec)

转换为有效率地插入

通过在随机字节前面加上26字节的时间戳,该值就变成了有效率地插入。使用我们的16GB缓冲池,我们现在的读-修改-写速率非常低,并且可以随着表的增长保持性能。

比较“有效率地插入”和c的随机值之间每秒插入的性能。越高越好。注意,当表变大时,有效率地插入如何维持性能。

有效的插入可以扩展到多远?

当缓冲池从16GB降低到128MB时,表A只损失了13%的插入性能。为了证明没有明确的“最大行数”限制,现在让我们将测试运行时间延长到5小时。在插入了近4.63亿行之后,我们可以看到我们的376GB表仍然保留了大部分的插入性能:

插入运行5小时,性能保持不变。在4.63亿行中,与1小时内插入的1.13亿行相比,只减少了18%。InnoDB内部使用页来存储,缓冲池缓存是面向页的。没有直接的证据表明表大小有行数限制。

插入性能不受数据大小或行数的限制。它取决于表+索引结构以及如何插入行。在这里很难给出一个一般化的答案。你可以有一个256GB的数据库,它可以很好地与1GB的RAM一起工作,而另一个256GB的数据库需要128GB的RAM。

这样,为什么设极限呢?

前一节中的示例描述了插入性能,以说明一点。但是性能并不局限于插入性能:-)具体来说,一些管理任务在较大的数据库中变得更加困难:

  • 进行全面备份
  • 提供新的读副本
  • 恢复备份
  • 进行模式更改
  • 减少复制延迟

让我们以4TB分片故障为例:

  • 当主服务器失败时,爆炸半径(blast radius)将会更大,可能会使更多的服务离线。
  • 当一个副本失败,在千兆网络速度,它可能需要10-12小时来恢复一个新的副本。而这个时间在高速度的网络(推荐)可以减少;而可能会出现相当大的二次故障窗口。许多Vitess使用者的目标是15分钟恢复;这在2.5Gbps网络上的250G分片是可能的。

Vitess并没有将250GB作为硬性限制。它甚至鼓励你在同一主机上运行多个MySQL实例(多个tablet)。

总结

通过指定推荐的大小,Vitess的作者还可以对某些操作需要多长时间进行假设,并简化系统的设计。或者换句话说:Vitess的作者们决定不采用一种放之四海而皆宜的方法来实现可伸缩性,于是我又回到了开头的那句话:Vitess对数据库的可伸缩性有自己的看法。

Vitess建议使用250G作为分片大小,用于管理和可预测的恢复时间。出于性能方面的原因,这可能是正确的,但这在很大程度上取决于你的使用情况。

测试信息披露

  • 8 Core (16 thread) Ryzen 1700
  • 64GiB RAM (MySQL intentionally limited with O_DIRECT)
  • Samsung EVO 970 1TB
  • Ubuntu 19.04
  • MySQL 8.0.17
  • MySQL Config:
    • innodb-buffer-pool-size= 16G (modified to 128M in second Table A test)
    • innodb-flush-method=O_DIRECT
    • innodb-log-file-size=4G
    • innodb-io-capacity=2000
    • innodb-io-capacity-max=5000
    • binlog_expire_logs_seconds=30
    • skip-mysqlx
    • max-binlog-size=100M
  • Benchmark inserts in 32 threads (gist)

本文分享自微信公众号 - CNCF(lf_cncf),作者:Vitess

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-10-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Istio技术与实践04:最佳实践之教你写一个完整的Mixer Adapter

    Istio的功能与作用在之前的文章中已经向大家展示了,基于Istio的微服务治理也必将登上广大云服务供应商的舞台。本文中,我们将会为您重点介绍一下Istio的核...

    CNCF
  • Falco安全审计

    定期审计代码库是发布安全软件的一个重要过程。对于依赖于来自各种贡献者的代码的开源项目,审计可能特别重要。我们很高兴地宣布Falco首次安全审计的发布,这是Fal...

    CNCF
  • TODO指南:关闭开源项目

    本开源指南旨在为贵企业或您所在的开发团队提供建议,以便能在需要关闭或离开不再需要的开源项目的那天有准备好的计划。这个指南通过合理地关闭项目或将项目转交给其他可以...

    CNCF
  • iPhone6s据说存储依然16G起,电池还缩水了,果粉们入坑吗?

    镁客网
  • [日常] 小白来装机基本概念BIOS与硬盘分区

    这两天因为在linux进行测试,先是搞坏了linux的系统,然后在重装linux系统后搞坏了引导。在修复引导的过程中,搞坏了本机的win8系统,再次修复引导与重...

    陶士涵
  • DOMO-冉冉升起的自助式商业智能工具

    自助式商业智能(BI)工具Domo通过能够快速建立数据连接并开启分析的网页版BI工具解决了自助式BI的难题,目前售价是每个用户每年2,000美金。不像其他的工具...

    iCDO互联网数据官
  • 新网站如何做好SEO优化 尽快被收录

    对于新网站,百度等搜索引擎会有一定的扶持,所以在网站上线之前一定要做好规划,为了网站往什么领域发展、所涉猎的内容等都要提前想好。

    德顺
  • Entity Framework(EF) 5

    在Entity Framework宣布开源后不久Entity Framework(EF) 5就正式发布了,ADO.NET官方博客上EF5 Released列出了...

    张善友
  • python 解决方法:ImportEr

    py3study
  • Redis list 之增删改查 转

    1、lpush [lpush key valus...]  类似于压栈操作,将元素放入头部

    双面人

扫码关注云+社区

领取腾讯云代金券