明白了，聚焦文档数据库，巨杉做减法

关注飞总聊IT，了解IT行业的方方面面。

上周看到巨杉和腾讯云TDSQL的合作，我还有点不理解。重新看完巨杉3月22号的推文，结合腾讯云26号的认证合作，这回搞明白了。这看看起来，是巨杉经过深思熟虑后在，执行聚焦和减法的策略而展开的生态合作。

2024年3月22号，巨杉数据库的公众号发表了一篇文章：。

这篇文章里，巨杉数据库回顾了公司的产品发展历程，提出了要做减法，聚焦在文档型数据库。

巨杉数据库是一家国内比较老牌的数据库公司，尤其是在JSON分布式文档型数据库方面，产品有着很强的竞争力。在创业的12个年头里，巨杉数据库在“文档型数据库”这个细分领域一直是国内的领导者，也成功地服务于超过100家金融银行的总行生产系统，处理PB级数据量和万亿行数据的管理。

从公开的资料看来，在文档型数据库这个细分领域取得领导地位的同时，巨杉数据库也在2018年左右开始尝试基于文档数据库的底座，发展关系型数据库技术，和湖仓一体技术，拓展自己的业务到更传统的关系型数据库领域。

但是这个决策实际上并不算得上成功。因为基于文档型数据的底座而做出来的关系型数据库，和从头到脚都是关系型的数据库比起来，技术上会存在明显的短板。

公司要想同时做好文档型数据库，和关系型数据库，如果还想基于同一个底座去做的话，很多时候技术上不仅仅南辕北辙差异性大，更有可能是有冲突的。

因此，巨杉从2021年起逐步展开减法工作，聚焦回到自己最擅长的文档型数据库技术领域，这样才能建立长期的产品竞争力。

了解到这里，对于巨杉公司领导层觉得要做减法的想法，我本人是非常认同的。

几年前我有次开会的时候，和MongoDB公司的某个VP of Engineering有过一次比较深入的聊天。

我们知道MongoDB是文档型数据库里一个非常成功的产品，MongoDB公司在其文档型数据库的云产品上也是赚得盆满钵满的。

我当时问对方，MongoDB的产品线，对传统的OLTP数据库，以及数据仓库或者数据湖这类的数据仓库相关的产品，有没有布局。

对方的观点是，如果在文档型数据库上，有对关系型数据库/数据仓库某些典型功能的需求，并且需求的客户很多，那么增加一些这样的特性和功能并不是不可以。

但是MongoDB的产品线上并没有打算基于文档型的数据库底座，去做出一个和关系型数据库或者数据仓库竞争的产品。他们也不打算做一款可以既是文档型数据库，又是关系型数据库/数据仓库的产品。

对方和我就产品形态，使用方式，存储层如何实现，查询引擎应该怎么做等等很多方面都进行了讨论。

我们比较一致的意见是，文档型数据库有其自身的使用方式，有适合其自身的存储，索引，查询等实现的方式，这并不和关系数据库完全兼容。

要想各方面都讨好，那么必然就会做出一款各方面都没特点的产品，也不会在市场上有竞争力。

但是如果全新去做一款，比如说，关系型数据库的话，市场上已经有足够多的关系型数据库了，自己加入，也不会比其他人更有优势。

我想巨杉公司决定做减法，聚焦文档数据库这个细分市场，应该也是这样的道理。

而当巨杉公司做出这样的减法选择之后，必然面临一个问题：对于巨杉现在的，使用了关系型SQL特性的客户来说，怎么办？

巨杉公司的做法是，首先，公司会为已经使用了巨杉数据库关系型SQL特性的客户提供稳定支持。简单来说，产品会持续稳定固有的SQL特性及Bug修复，而不会继续增加研发，大规模地开发新的SQL特性了。这样可以避免新特性的引入带来新的问题，让已经生产上线的系统保持稳定运行。

所以，如果客户确实对新的SQL特性有强烈的需求，巨杉公司的做法是和上下游工具以及产品厂商进行官方认证，帮助客户进行迁移。

基于这样的一个理念，巨杉公司的第一个合作伙伴是腾讯云的DTS-DBbirdge以及TDSQL。

腾讯云的DTS-DBbridge可以实现各种商业化和开源数据库的迁移。而数据迁移是一件不容易的事情，迁移过程中，不仅仅会涉及到迁移的速度，迁移过程中因为网络等原因导致数据的迁移中断，重连，还会涉及到不同数据库在数据结构，语法，数据一致性等各方面的问题。

而为了确保巨杉的客户在有需要时能够顺利的迁移，巨杉和腾讯云进行了厂商间的认证合作。通过厂商之间的生态合作提前解决迁移过程中可能遇到的各种问题，确保了巨杉数据库的客户，如果想迁移到腾讯云的TDSQL，可以更加平滑地迁移，不会遇到问题。

腾讯云是第一个和巨杉互相合作，完成互认证的伙伴。而我认为巨杉和合作伙伴进行官方认证的步伐，应该不会止步于此。从双方这两天的技术合作新闻看，巨杉还将和其他的合作伙伴进行官方认证，确保巨杉的客户，能够顺利地把自己的关系型SQL数据迁移到更多的不同的产品中去。