“人皆可研”的国产数据库，正在向全民“多模”“超融合”的阶段大跨步，国产数据库弯道超车、换道超车指日可待！！！
潮涨潮退，大浪淘沙，谁是真技术，谁是吹牛皮，其实一用便知。
关键词就在这“一用”，不管能不能用，好不好用，”让用户先用上“就是厂商的第一目标，案例LOGO有了、市场覆盖做到了，就能继续忽悠下一个客户，故事讲圆了，融资也就到~~
所以很多企业大肆开发新功能，不管研发有没有付出，前端的市场、销售、售前们吆喝的肯定是真的卖力！
一部分聪明的厂商就只吆喝一下赚个眼球，一部分“实诚”的，为了讨好市场、讨好用户，就真的投入研发去铺更多的产品线，建设更全的功能覆盖蓝图，这中间不乏有能力的企业做到言行合一，但大多都已经快把自己玩死。
数据库软件难度自然很高，但就以简单的数据库周边工具而言，新功能也不是那么简单就能做好的，就像数据库迁移工具、监控工具。
之前在某项目上遇到的真实情况，该项目要采购一款国产MPP数仓，目标是把各交易系统的每日增量数据同步到数仓进行存储分析。
为了让用户方便达到这个目标，也为了提升解决方案的竞争力，某数据库厂商很快制定了研发计划：
在已有的迁移工具的基础上，设计了类似ETL的每日增量数据同步功能，并快速搭建了demo，在POC中赢得了用户的认可，也获得了这个项目，确实很有执行力！
但当生产系统上线以后，隔三差五的BUG让甲方DBA焦头烂额，最后更放弃参与、直接让系统应用人员与数据库厂商沟通。
而厂商不得不配置专职运维人员24小时在线值守，整个数据迁移工具组的研发也被这个增量迁移功能全部耗住，使原本在计划内的性能优化、新特性开发全部无限期推延...
都有哪些BUG呢
入库报错数据格式不匹配，分析半天发现是源端表字段顺序发生了变更（这看着就像是用了insert into..select * from...这样的语句,如果在select中指定字段名称，这个错误是不是就不会发生了？)
又如，迁移进程一致夯住，日志有报错但进程不退出。又分析半天，发现是系统前期设计为了“健壮性”而遇错重试，却没有设置重试次数限制~~（尴尬的是客户每次要杀进程就必须向上级打申请，原本一个小事件就成了大问题...）
为什么每个故障都要分析半天呢？因为系统输出的日志仅记录错误的结果，缺少详细的问题定位和价值信息，所以分析起来只能不断的尝试推导和测试验证，这无疑增加了解决问题的时间...
诸如此类吧，大多是一些“需要消耗长时间分析，但是分析出来的原因却很低级”的问题…（当一个超级富翁要多次向你借钱买午餐的时候，那他一定是遇到的绝对不是小问题）
于是企业为了拿项目、扩市场，盲目扩展产品线，让企业忙于增加临时新功能；随着问题积累，最终整个研发团队都耗在了解决历史BUG上，在激烈竞争中再无一战之力，搭上了企业的未来！
有些人说这要产品经理背锅，肯定有责任，到也不尽然如此，毕竟这也代表了企业的决策。
这就像几个人托一根木头跑马拉松，为了增加速度，你用半天时间在木头上造了一个轮子，但是刚走一步轮子就卡在路上了，怎么也动不了，再一折腾一天过去了。卸掉轮子又不舍得，而且肯定有人抱怨当初谁决定的要装轮子。于是很多人就在修轮子的过程中莫名其妙的结束了比赛！！！
弯道超车也好，换道超车也罢，重要的是选择一条匹配自己能力的道路。
END
扫码关注支持一下
点赞、在看、转发，也非常感谢~~
