国产数据库厂商太多了！
L是一名数据库专家，一天L约了企业技术主管W、行业专家Q一起喝茶聊技术聊人生。谈话间，L提及当今国产数据库厂商超过200家，这让W很是震惊！
W：超过200家，国内数据库厂商这么多吗？这太不可思议了！
L：老W，为啥不可思议？
W：数据库是IT系统的核心，对安全、性能、功能要求极高，其投入远非一般企业所能承受的。你看漂亮国那款被称之为O记的数据库厂商，员工规模已超10万人。如果国内数据库厂商分散成200家，人才自然也分散四处，那拿什么与O记抗衡呢？
L：我理解你对人才分散的担忧，不过集中了又如何？目前规模超千人的国内数据库厂家屈指可数，即便把国内所有数据库厂商合并成一家，总员工数和总营收也远不及O记。而在漂亮国，居然还有与巨无霸O记旗鼓相当的对手存在，如I记、M记。
W：差距这么大？难以置信啊。我估摸国内还是这种诸侯纷争态势，是不是永远也别想追上了。
L：也没你想的那么悲观，我还是对国产数据库充满信心的，已经看到了换道超车的希望，反观O记看似强大，实则危机四伏。后续听我讲故事你们就会明白的，很有意思。
W：期待！对了，你说面对这么多国内数据库厂商，该如何做数据库选型呢？
L：选型这个问题很现实，在当下算是不折不扣的苦差事了，个中的酸甜苦辣就在后续故事中分享吧。
Q：L兄，我很好奇国内会如此多数据库厂商，是怎么冒出来的？
L：怎么冒出来的？这和开源数据库有关。当前国内数据库厂商可分两类，分别是“自研类”和“开源改造类”。前者是完全从零开始探索，后者则是依据主流开源数据库进行改造。大家觉得哪类厂商更容易推出产品？
W：那肯定是基于开源更容易，拿现成的改改多省心啊。L：所以当前开源改造类占据国内厂家的绝大多数，不过自研类厂商虽说为数不多，却有不少已取得巨大的突破，他们坚守信念，负重前行，让人敬佩。此处先不展开，后续听我讲故事吧。
Q：我也很敬佩这些自研的厂商。那开源改造类厂家到底改了什么？功能、性能、安全性还是只替换Logo套个壳....这些我们都不得而知啊。L：是的，开源改造类不仅门槛低，操作的弹性空间还大，干多干少全凭良心。于是一夜冒出数百家数据库企业的乱象，也就可以解释了。不过话说回来，也有一些开源改造类厂家有其自身特点，这些就在后续的故事中说吧。L：其实国内冒出这么多数据库厂家也不仅是因为开源数据库，还有第二个原因，即数据库产品越来越多了。L：是的，早先基本就是通用关系型数据库一库打天下，现在则根据不同场景出现了多种专用数据库，同时又对应催生出一大批数据库厂商。Q：哦，都有哪些专用数据库，通用关系型数据库为啥就搞不定这些应用场景？L：数据库按场景可分出OLTP数据库、OLAP数据库、HTAP数据库、图数据库、GIS数据库、时序数据库、向量数据库.....L：你这就晕了。每种类型的数据库产品都有多个厂商参与，如果前面描述的是数据库产品名，总数还得数十倍的往上加。W：真搞不清为啥整出这么多产品，我曾参与过数据库选型，快被折腾疯了。
L：两位，我想通过 “老明的一天”，把这些数据库产品串起来理解，如何？L：9点，公司账户A将奖金成功转给老明账户B，老明收到短信通知后立即查询了余额，接着干活愈发来劲了。这种能支撑此类数据交易操作的数据库即OLTP数据库，也是通用关系型数据库。10点，公司开始分析像老明这个年龄段所有员工的薪酬水平，觉得给高了。这种能支撑此类数据分析操作的数据库即OLAP数据库。12点，老明用奖金买了一笔理财产品，系统先对老明风险承担能力做了分析评估，认为合适后才同意其购买。这种能支撑此类集数据交易、分析于一体的数据库，即HTAP数据库。15点，银行发现A账户存在异常操作，开始查找A账户和各种相关联账户之间关系，同时分析各账户交易地点。这种能找到数据间关联关系的数据库即图数据库；这种能保存数据空间地理位置的数据库即GIS数据库。22点，老明总算完成了设备上各采集指标数据的分析工作，准备下班。这种能按时间顺序连续存储数据的数据库，即时序数据库。
24点，忙碌一天的老明躺在床上，心想自己任劳任怨，应该快涨薪了，然后美美的进入梦乡。要实现是否涨薪的预测，需要使用向量类型的相关数据进行机器学习，这种能支持向量存储的数据库即向量数据库。W：“老明的一天”写出了各类数据库的特点，也写出了中年打工人的忧伤，老明的梦想要破灭吧。Q：L兄，通用数据库为啥搞不定这些专用数据库的场景，你还没回答我哦。L：我想分享“老明的日记”，来回答两位的疑问，如何，不过这个日记上次不小心进水了，大部分字迹都模糊看不清楚了。公司决定部署专用的OLAP分析型数据库，因为数据统计分析的需求越来越多了......只是，咱们DBA团队的活以后要变多了。
X年X月X日 阴
今天公司准备上HTAP数据库，没料到真有实时性要求很高的分析需求，新上的Y系统居然要求交易前先分析，判断符合条件才能交易......看来，以后DBA团队的活要越来越多了。
X年X月X日 雨
质量追溯的需求实在是太复杂了，SQL响应时间没法满足要求啊。不过图数据库的的这个方式倒还真有用.....团队忧喜参半啊，喜的是能解决问题，忧的是又要折腾了，已经快忙不过来了。
X年X月X日 暴雨
今天公司决定上专用时序数据库，真没想到时序数据有这么大的坑，频率、指标和设备三者的变化会让你疲于奔命啊。采集频率1分钟变1秒，数据量增大60倍......哎，现在技术栈太多了，咱们DBA团队已经扛不住了。
因为生产系统跑的关系型数据库没有向量类型......不得不引进了向量数据库，惨！好在今天收到我面试通过的消息，明天就向老大提离职，太好了，终于解脱了！
W：L兄，每篇日记的中间部分都模糊了，只能看清头和尾啊。
Q：能看清老明公司上了好多次专用数据库，还有老明越来越不开心了。L：模糊之处，我们下次让老明亲自展开来跟我们说说。其实所有新出现的这些专用数据库都是特定历史时期的特定产物。就说时序数据库，正是由于关系型数据库在当时无法在满足ACID的前提下还能有很好的扩展性，给了通过牺牲阉割大部分功能而换取扩展性的时序数据库一个机会，但是关系型很快就弥补了这个短板。其实其他专用数据库的逻辑也是类似的。Q：那这些专用数据库很快就要被关系型通用数据库融合进去吧。
L：道理是这样的，可实际上产品、厂商已形成，且产品在生产系统已上线，这不是说放弃就放弃，说替换就替换的，需要各种平衡和考量。这里不展开说明了，后续在故事中细说。
W：L兄，你一直提到后续要讲故事，能否透露一下故事大致说什么。
L：W兄，今天就是故事的第一集，咱们已经身处故事中了。故事名为《数据库二十年目睹之怪现状》，咱们下回继续分解。“老明，大家正在说你的故事呢。” L哈哈大笑，迎上前去。“走，一起吃饭去。”
预告：《超融合数据库》即将出版，关注梁老师公众号，敬请期待。
梁敬彬约 7 分钟