数据库 Friends don't let real friends use INT as a primary key?

hooopo · 2018年11月09日 · 最后由 ywjno 回复于 2018年11月09日 · 608 次阅读

Basecamp 因为使用int主键,单表达到上限21亿之后,服务变成只读模式近5小时。

Just in case you were curious to know how long it takes to upgrade a 200GB table with 2,147,483,647 rows in it from int to bigint. The answer is 2:52 hours on extremely beefy hardware 😫


Basecamp 3 is fully back after nearly five hours of being stuck in read-only mode. We're so sorry for what happened today. The play-by-play of our trials and our explanation for what happened is available on SvN:https://m.signalvnoise.com/update-on-basecamp-3-being-stuck-in-read-only-as-of-nov-8-9-22am-cst-c41df1a58352

看了一圈评论,发现一些有意思的点:

  • basecamp使用的是mysql
  • 爆掉的这个表应该是最大表,记录刚达到21亿,用途是做tracking的,类似审核或feed之类,无sharding。先scale up,硬件实在不能满足的时候才scale out,这点其实非常好。
  • 吃瓜群众更多认为是int做主键惹的货。其实basecamp这次read-only 5小时问题,不完全是int迁bigint引起的,mysql大表做online ddl的工具非常多,比如github的gh-ost、lhm等。但问题是,basecamp这次的问题是id用光了才发现问题。
  • bigint应该成为默认也挺扯的,是否使用bigint完全由系统规模和表的类型决定的,比如用户表,中国一共才13亿人口,21亿一定足够用,一定要bigint吗,未必,用了只会给云服务运营商多交银子。一些特殊类型的表才需要bigint,比如tracking、logging、feed、关系表等。

MySQL Online DDL 工具

Postgres Online DDL workflow

postgres在线修改数据类型: https://github.com/digoal/blog/blob/master/201811/20181108_01.md

有用的链接

共收到 14 条回复

basecamp已经第三代没有监控是挺扯的

pynix 回复

uuid更浪费,主键不止要存在一张表里,还要在其他表作为外键,还要加索引,所以内存和磁盘空间都带来没有必要的增长,云服务商应该是最希望看到uuid主键了。

DHH在Railfconf2018中很自豪的说: “我们不招聘DBA,数据库不分库分表,只用一个主实例和其他slave, 怎么省事怎么来”

其实就是 Basecamp 量小,业务不够复杂而已。

hooopo 回复

曾经用过。。。

可能招个DBA比用extremely beefy hardware贵得多把……

社区一直在逃避大数据高并发分布式之类的问题。

这些需求出现后,并没有成熟的解决方案,往往要转换技术栈。比如转向 Java 或是最近很火的 Go

活在 Ruby on Rails 舒适区里都不想改变,midori 是一个不错的尝试,可惜不够成熟也势单力薄。

原因就是一个两年前已经发现有隐患的主键上限、Rails 框架作为默认值修复的问题,Basecamp 团队自己却没有做数据迁移,DHH 责无旁贷。

Basecamp 一宕机趁机把对 Rails 的新仇旧恨抛出来的也是搞笑。

我想起这个演讲:

RailsConf 2018: Keynote: The Future of Rails 6: Scalable by Default by Eileen Uchitelle

演讲者 Eileen Uchitelle 正在把 GitHub 的技术逐步提交到 Rails。最后五分钟是重点。

如果觉得自己的方案比 Rails 社区的好多了,为什么不拿出来分享甚至向上游提交补丁?

Basecamp 明明自己蠢还赖框架,我做埋点分析的时候,做了一周发现数据总量跑到了2000W级别我们就害怕超21亿换成bigint了(实际根本没机会超),这种事情自己懒还赖别人。建表的时候就应该知道主键用什么。

pynix 回复

https://twitter.com/nateberkopec/status/1060633720003059713?s=20

"Also if you're thinking you're extra smart and you want UUIDs as primary keys...DON'T! They perform significantly worse than bigint/int on all SQL databases I know of."

Rei 回复

如果觉得自己的方案比 Rails 社区的好多了,为什么不拿出来分享甚至向上游提交补丁?

这个问题之前提出过了, DHH 硬是不接受也没有办法.

还好 Eileen 和 Tenderlove 在 Github 把 GitHub 的技术逐步提交到 Rails. 他们想专注在 Github 的 Business Logic, 其他的向上游提交, 重要的是 DHH 完全相信 Eileen 和 Tenderlove.

ksec 回复

bigint 的补丁没有接受吗?

Rei 回复

我意思是其他的补丁. 最近的例子例如 Active Storage.

Rails is omakase.

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册