数据库服务器选型那些事儿，关键点你得先搞明白才能不踩坑

综合自知乎专栏“技术选型漫谈”、极客时间“架构师实战笔记”以及多位一线运维工程师的社区分享）

选个数据库服务器，听起来好像就是看哪个牌子响、哪个价格贵就选哪个，但真要这么干，十有八九项目做到一半就得推倒重来，掉进大坑里，这事儿其实跟找对象差不多，没有最好的，只有最适合你的，你得先把自己的情况摸透了，才知道该找什么样的“另一半”，下面这些关键点，你要是先搞明白了,能避开路上百分之八十的坑。

第一点，也是最重要的一点：先别急着看数据库本身，回头看看你的业务。

很多人一上来就问“MySQL和PostgreSQL哪个好？”这问题没法回答，你得先问问自己：我的业务是干啥的？是个天天有成千上万人疯狂下单的电商网站，还是个内部使用的、数据量不大但报表特别复杂的分析系统？这决定了完全不同的方向。

• 如果你的业务像淘宝、京东，特点是并发极高，每秒要处理海量的简单读写（比如扣库存、生成订单），那么你首先要考虑的是数据库的扩展性和高并发读写能力，这种情况下，可能传统的关系型数据库（比如MySQL）单机顶不住，你得考虑能不能方便地做分库分表，或者直接选用那些为分布式而生的NewSQL数据库（比如TiDB，根据PingCAP官方技术白皮书描述，其擅长高并发OLTP场景），这类场景我们常称之为OLTP，就是在线交易处理，核心是“快”和“准”。
• 如果你的业务更像是一个后台数据分析平台，需要把过去几年的销售数据、用户行为数据都拿出来，跑一些非常复杂的查询，做报表、做预测，那这时候，“每秒处理的事务数”可能不是最关键的，关键是处理复杂查询和海量数据的能力，这类场景叫OLAP，在线分析处理，这时候，列式存储的数据库（比如ClickHouse，据其GitHub文档介绍，在OLAP场景下性能远超传统数据库）或者专业的数据仓库可能更合适。

第一步一定是业务场景驱动，拿张纸，把你的业务特征写下来：数据量大概多大？增长多快？读写比例是多少（是读远多于写，还是读写差不多）？查询是简单的根据主键查,还是动不动就十张表关联再加各种条件过滤？

第二点，摸摸你的钱包，算算总拥有成本。

数据库的成本可不仅仅是买服务器硬件或者买云数据库实例的那笔钱,这里面有不少隐藏开销：

• 软件许可费用：有些商业数据库（比如Oracle、SQL Server）的许可费非常昂贵，是按CPU核心数来算的，一台好点的服务器，许可费可能比硬件本身还贵，而像MySQL、PostgreSQL这类开源数据库，软件本身是免费的,但并不意味着零成本。
• 硬件成本：你的数据量和访问压力需要什么样的服务器？是需要一大堆普通PC服务器组成集群，还是需要几台内存超大的“怪兽”级服务器？这钱差远了。
• 人力成本：这是最容易被忽略也往往是最大的一块，一个成熟的Oracle DBA（数据库管理员）的薪资和一个MySQL DBA的薪资可能不一样，更重要的是，你所选数据库的技术生态如何？招人好招吗？学习资料多不多？社区是否活跃？出了问题能不能快速找到解决方案？如果你选了一个非常冷门、没人用的数据库，可能省了点软件费，但将来招人、维护的坑能把你埋了，极客时间专栏里提到，技术选型时要考虑团队的“技术基因”，强行引入团队不熟悉的技术栈,风险极高。

第三点，想想数据这东西有多金贵，能丢吗？能错吗？

这就是在考察数据库的可靠性和一致性。

• 可靠性：说白了就是数据会不会丢，数据库有没有完善的备份恢复机制？能不能做主从复制？出现硬件故障时，能不能自动切换，保证业务不停机？（这叫高可用），云服务商（如阿里云、AWS）的数据库产品通常都会提供高可用版本,但配置和价格也需要你权衡。
• 一致性：这在分布式数据库里尤其重要，举个例子，你在北京下单买了东西，在上海马上要能看到这个订单，这就是强一致性，但为了保证这种强一致性，可能会牺牲一些性能（延迟会变高），有些场景可以接受“最终一致性”（比如社交媒体的点赞数，晚几秒钟看到也没关系），这样系统性能会更好，你需要想清楚你的业务对一致性的要求到底有多高，知乎上有资深架构师指出，很多团队盲目追求强一致性，反而把系统搞复杂了,性能也上不去。

第四点，别光想着现在，想想一年后、三年后。

你的业务是在快速发展期，还是稳定运营期？数据库的可扩展性必须提前规划。

• 垂直扩展（Scale-up）：就是给现有的服务器加CPU、加内存、换更快的硬盘，简单粗暴，但有物理上限,而且好的硬件非常贵。
• 水平扩展（Scale-out）：就是通过增加更多的普通服务器来分担压力，像MySQL的分库分表，或者一些NewSQL数据库（如CockroachDB，其设计目标即为全球级分布式扩展），天生就支持水平扩展，如果预估业务会快速增长,一定要优先考虑支持良好水平扩展能力的方案。

动手之前先试试。

纸上谈兵终觉浅，在确定了几个候选数据库之后，一定要做压力测试（POC），模拟真实的业务场景，用接近真实的数据量，去跑一跑你的核心业务逻辑，看看在实际环境中，它们的性能表现到底如何，监控指标（如CPU使用率、磁盘IO、延迟等）是不是符合预期,这个过程可能会让你发现很多之前没想到的问题。

数据库选型就是个权衡的游戏，在性能、成本、可靠性、扩展性、开发效率这几个方面之间，根据你业务的轻重缓急，做出最适合自己的选择，没有银弹，只有最适合你的那一款，把这些关键点都想明白了，再下手，虽然不敢说百分百不踩坑，但至少能保证你掉进去的是个小水洼,而不是万丈深渊。