昨天小米发布会可谓赚足了眼球，或者说，从去年年底到现在的3个月时间里，大家都在等待小米最后的悬念——价格。这三个月里，发生了比亚迪7.98万引领的一波新能源汽车集体大幅降价，不得不说，小米面临的竞争十分激烈。另一方面，也有一些新能源汽车开始退市，厂商烧了几年钱，终于扛不住了。一些早期的车主面临后续维保无门的尴尬境地。汽车如此，数据库呢？
长生命周期产品
数据库和汽车有一些相似性，就是都是一个长生命周期的产品。一个普通家庭买一辆车都要用很多年，我们家最早的一辆车从购入到退役超过了十年。这期间各种各样的维修、保养、配件更换随着使用年头的提升，都不可避免。当时老爸选择了一个比较常见的品牌，这些就都没有遇到过问题，哪怕后来车型已经改款甚至换代，后面的维修和更换配件都很容易。遍地的汽修厂和维修师傅都对这型号的车很熟悉，也从不用担心。
数据库在这一点上也很相似。就拿oracle为例子，直到数年前，还有很多企业都核心系统都还在10g上，要知道oracle10g是2003的产品，这个系统是07年上线。数据库使用年头超过了10年，这期间依托于oracle强大的技术支持能力以及无数的补丁、文档、经验还有足够的Oracle DBA储备，这个系统在十几年时间里平稳运行到升级Oracle11g，而升级到11g的时候，11g也接近生命周期尾声了。这在数据库使用过程中是常态，稳定压倒一切。
现在的新能源汽车，迭代速度太快了，快到我不敢轻易入坑。一方面谁也不敢保证现在的产品在物理设计上有什么坑，另一方面电池电机这些核心部件也在不断有新技术新革新，我比较担心的是，自己买了一辆新车，两三年后就面临被时代淘汰的尴尬，更惨的是甚至厂商都没了，以后的维保都很难。
我相信，很多公司在选择国产数据库时，也有同样的顾虑。
墓碑系统
在之前的工作经历中，遇到过很多老旧系统，服役时长已经超过了部门资历最深的同事。业务没有新需求，也没有预算，这些老旧系统年复一年地跑着。有的厂商已经不再支持这个系统，有的甚至厂商都没了。运维人员摸索出很多坑，但是又没人敢去解决，只能尽可能地规避。这些系统我同意称之为墓碑系统。然而最坑的是，有些墓碑系统突然又有了新业务需求，又要重新改造甚至重构。当年的研发已经离职或者转岗甚至项目组公司都没了，代码都找不到的时候，除了重新选一家供应商别无他法。这还只是应用程序的墓碑系统，如果是数据库，该怎么办？数据库的迁移和替换，可比这些墓碑系统麻烦的多。真遇到绕不开的bug，厂商又解决不了甚至干脆没了，除了认栽好像也没别的选择。（精通研发的DBA自行改代码这种事不在考虑范围）
所以作为曾经的数据库产品经理，我也给各位DBA同行提供4个维度作为选型建议，避免出现墓碑数据库：
- 团队规模。这里的团队规模，不仅仅是当下的团队规模，还包含了团队规模的变化情况。比如某个数据库产品过去一年时间里开发团队规模缩减了一半，这个事情就得仔细考量。是什么原因减少，因为数据库是个长生命周期产品，短期内一下子研发投入减半就很耐人寻味。毕竟基础软件不是某个app或者游戏，主体内容开发完成就减少投入，后续有无尽的内容要做。
- 产品路线。数据库开发是一个极其复杂的工程，很多功能存在依赖关系，产品路线往往要提前半年甚至更早规划。如果某个产品路线做的很不合理或者频繁变动，这说明规划很差，团队内部真正懂数据库的人很少。如同不懂车不开车的人做的车，有多少坑没人知道。
- 客户数量。一个数据，在上生产之后很多问题才会暴露。按照过往我的经验，95%以上的问题测试中都是暴露不出来的。客户数量，尤其是上生产的数量越多，业务场景越多，暴露出来的问题就越多，对这个产品的了解程度就越高。DBA圈子不大，通过朋友找到同业客户的同行总能打听出一些东西。
- 面对面沟通。把你的问题直接面对面抛给厂商的人，不管是售前还是实施，看看他们的反馈。如果一些数据库运维和使用的基本知识储备都没有，直接拉黑免谈。
