数据库

这份榜单里有什么

存放数据并能快速取回的地方：关系型引擎、文档存储、键值缓存、搜索索引、时序存储，以及替您运行其中任何一种的托管服务。

多数团队需要的数量比厂商暗示的要少。一个关系型数据库能在很长时间里应对多数应用，再加第二种引擎，就多了一套故障、备份，以及需要懂它的人。

对这些数据的分析和报表属于数据分析。应用本身运行的地方是托管与云。

选择引擎

从数据的形态以及您将向它提出的问题出发。

关系型引擎适合任何涉及关系、事务、约束和报表的场景，多数业务软件都符合这一描述。

其余的是专才。文档存储适合形态各异、通常整条读取的记录。键值存储用于简单查找时追求速度。搜索索引的存在，是因为关系型的文本搜索到了一定规模就不够用，时序存储的存在，是因为指标数据的到达速度快过其他一切。

诚实的默认选项是关系型引擎，直到有事实证明它不够用。为了避免一个并不存在的扩展问题而一开始就选用冷门存储的团队，通常会先遇到另一个更糟的问题。

兼容性比品牌更重要。使用广泛实现的协议的引擎，给您带来工具、驱动、招聘和退路。专有接口给您带来的是一个迁移项目。

托管、自托管还是无服务器

托管服务收取溢价，并免去您本来要在不方便的时段做的工作：打补丁、版本升级、故障切换、备份验证。

自托管在账面上更便宜，只有在团队里已经具备这些技能时，实际才会更便宜。诚实地算一算工时，包括磁盘写满那个晚上花掉的那些。

无服务器产品随负载伸缩容量，闲置时收费很少。这适合流量不均的场景，更适合开发环境。要检查冷启动的表现、连接数限制，以及计量方式如何对待一个永不停止的后台任务。

决定可靠性的问题

• 备份：多久一次，保留多久，能否恢复到选定的时间点。
• 恢复：在您的数据量下完整恢复要多久，要测试过的，而不是承诺的。
• 故障切换：自动还是手动，需要多长时间，以及发生期间应用会看到什么。
• 复制：只读副本、跨区域副本，以及您的代码必须容忍的延迟。
• 连接数：上限是多少，连接池是自带的还是要自己运行。

试用期间做一次恢复。没人恢复过的备份只是一种希望，而这个分类恰恰是希望代价最高的地方。

增长、迁移，以及日后会痛的部分

大表上的架构变更，是毁掉周末的操作。问问引擎在流量持续的情况下，如何处理添加列、修改类型或创建索引。

从第一天起就把迁移文件与应用一起放进版本控制。另一种做法，即在控制台里手工应用变更，会产生没人能还原其差异的环境。

也要留意数据位置。数据库与应用不在同一个区域，会给每次查询增加延迟，而一个页面发出五十次查询的应用，会清楚地感受到这一点。

账单是怎么构成的

计算、存储、备份存储、网络出站流量，有些服务还有读写单位。

出站流量是让人意外的一项，尤其是当分析或副本把大量数据拉过区域时。存储很少会自己缩小，所以已删除的行在维护运行之前可能仍在计费。开发和预发布副本会让一切翻倍，除非把它们缩小规模或夜间停止。

问问用量达到今天的三倍时价格会变成多少，而不是问今天的，因为那才是您实际要付的数字。相关的做法汇总在定价页隐藏了什么中。

让数据库保持平淡的做法

这个分类的目标是没有戏剧性，少数几个习惯就能带来其中大部分。

把迁移文件放进版本控制，在每个环境里用同样的方式应用。在控制台里手工做的变更，会产生日后没人能还原的差异。

有意识地添加索引，并偶尔复查，因为没用到的索引看似无害，却会消耗写入性能和存储。

把监视慢查询当作例行工作，而不是在事故发生时才做。今天要花四秒的查询，等表长大了，就是下个季度的故障。

还有，按计划恢复备份。从未恢复过的副本只是一个文件，不是一道保障，而这个分类恰恰是晚发现这一点代价最高的地方。