数据库 Friends don't let real friends use INT as a primary key?
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 工具
- https://github.com/facebookincubator/OnlineSchemaChange
- https://github.com/github/gh-ost
- https://github.com/soundcloud/lhm
Postgres Online DDL workflow
postgres 在线修改数据类型： https://github.com/digoal/blog/blob/master/201811/20181108_01.md
有用的链接
- https://m.signalvnoise.com/update-on-basecamp-3-being-stuck-in-read-only-as-of-nov-8-9-22am-cst-c41df1a58352
- https://www.braintreepayments.com/blog/safe-operations-for-high-volume-postgresql/
- http://code.openark.org/blog/mysql/mysql-vs-postgresql-gh-ost-perspective
- https://github.com/doctolib/safe-pg-migrations
- https://github.com/gocardless/activerecord-safer_migrations
pynix
回复
uuid 更浪费，主键不止要存在一张表里，还要在其他表作为外键，还要加索引，所以内存和磁盘空间都带来没有必要的增长，云服务商应该是最希望看到 uuid 主键了。
DHH 在 Railfconf2018 中很自豪的说： “我们不招聘 DBA，数据库不分库分表，只用一个主实例和其他 slave，怎么省事怎么来”
其实就是 Basecamp 量小，业务不够复杂而已。
社区一直在逃避大数据高并发分布式之类的问题。
这些需求出现后，并没有成熟的解决方案，往往要转换技术栈。比如转向 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.
