从市场和需求分析分布式数据库产品的实际用户群体与需求定位 (大佬一句话引发的文字)

近某位数据库业界大佬私聊,提出一个问题值得思考,所以才有了这篇文字

这位大佬有这样一句原话, 从这句话可以看出这位大佬对国产数据库产品以及产品定位的考量.  

我作为一个nobady, 也想"胡说八道" 一下个人的小看法 , 基于个人的目光短浅以及知识层次的问题, 估计下面也就是"车祸现场". 

首先不管是单体数据库,还是分布式数据库,或者国内或外的产品, 他都是一个产品.  产品的诞生必然是由客户的需求来驱动,并且部分需求引导产品的发展和迭代.  国内大部分客户的思维模式还停留在ORACLE 为主导的数据库体系,以及单体数据库完成功能的思维定式上. 所以分布式数据库到底是什么, 部分客户是不清楚和明确的. 部分还是用ORACLE 来往分布式数据库上套, 需求方面也是类似的情况.  

在此之前我们需要明确一些前摄

1  数据库产品的客户是谁 ?

2  客户对数据库产品的需求是什么?

3  怎么应对目标客户对数据库产品的技术需求?

1  数据库产品的客户群体是谁 ?

我们先从一张图说起, 下图是一张全球数据库市场增长的趋势图, 通过这个趋势图, 数据库行业的从业者估计会笑开了花, Really ?  别忘记你在中国,顿时就笑不出来了.  国内对盗版的打击力度低, 导致中国的软件产业一直处于小打小闹的阶段. 基础软件的研发,其实一直离不开 "开源架构"

那么,中国的数据库产品的客户群在哪里 ?   (用户画像)

首先可以确认的是,哪些企业不是中国数据库产品的潜在的客户,  互联网企业,尤其是头部互联网企业,一定不是潜在的数据库产品的客户群体, 他们大部分在开源数据库,或自研数据库方面有很丰厚经验, 自然不是数据库产品的潜在客户,这与他们在技术上自主性有关, 并且即使使用了,也大多不愿意等额付出. 小型传统型企业,在基于国内盗版软件监管和打击力度上的缺失, 也必然不是数据库产品的潜在的客户群体. 

一个产品的定位与价值在于客户对产品本身的依赖的程度,以及产品可以提供给客户在使用产品后享受到的价值. 一个产品本身的总体价值为

产品的价值 = 平均创造用户价值 *  覆盖用户量

要不就提高客单价, 要不提高覆盖用户量, 都能让产品本身的价值提高, 不谈利润的产品是没有未来的, 他需要变现的方式,哪怕产品不赚钱,但产品的流通环节,或非终产品使用方付费都可以被视为产品的价值. 平均创造用户价值 与 覆盖用户量中，任何一个的值偏低都会导致产品的价值无法达成满意的效果.

从目前的整体的数据库客户群体以及客单价来看, 国家政府机构以及金融机构,电信,保险等行业(国有,或具有国有性质) 是满足目前数据库产品价值大化的客户群体.   客户群体已经确定的基础上,下一步就是产品本身的需求.

2  客户对数据库产品的需求

上面提到过,在国内能对分布式数据库本身提出明确需求的客户估计不多,但本着产品价值的实现, 就需要研究客户群体对数据库产品的需求, 基于上述的一些特征, 大部分客户基于主要的需求可以综合成如下的一些需求总结

 对数据存储量,扩展性和数据性能方面的需求是核心需求

    在数据存储量上, 分布式数据库本身对应单体数据库就有明显的优势, 所以分布式数据库产品的主要的特性就是灵活的延展和伸缩数据存储的特性. 以及在此基础上的性能需求满足.  

这里需要提及一点, 大部分用户的意识对于分布式数据库的想法的基点在大容量数据存储上是没有异议的, 但在性能方面,期望过高, 分布式数据库本身在设计原理必然导致在目前的硬件水平基础上,不能完全的与单体数据库处于一个基线.  

举例,如果你的数据库本身的容量过小, 在单体数据库上的性能是要高于分布式数据库的, 分布式数据库的性能与单体数据库之间是有一个单调递增的函数曲线在X 轴达到 0 后是分布式数据库的战场. 

所以对于分布式数据库的性能要辩证的看, 不能化,要么都行,要么都不行.

剩下的需求,基本上都是从单体数据库上的"拿来主义", 国内的数据库基本上还都在重复昨天的故事, 不过这也不能怪产品和产品生产商, 1 是分布式数据库本身处于初级阶段  2 以需求为导向的方式,决定了分布式数据库的发展趋势.

其实一句话, 用户对产品的需求不明确, 那么剩下的在满足核心基本功能的情况下, 就剩下"各自挥洒的发挥".  这就让有些数据库,成为分布式的ORACLE, 你们懂得. 

下面这段语句就是某分布式上的可以支持的语句,当然还有其他, 所以叫"他"分布式的ORACLE 也没错.

   

终分布式数据库应该是怎样的, 没有人能说得清, 或许现在大多都是走一步算一步的状态.

3  应对目标客户对产品的需求

在应对客户的需求阶段, 实际上分布式数据库还充满了以下一些特色

1  需求的不确定导致产品的返工和某个功能的取消

2  产品支持的多样化,导致产品的质量和产品的本身定位不明确, 看似什么都行,其实.......

3  需求的变化较快, 导致产品生命周期缩短, 有些功能在确认的时候是"必须的", 但在做出来后, 就被证明是"脑子发热的产物". 

当然以上也是一个产品从诞生到成熟必然的一个"崎岖" 的过程, 还有一些产品是野心勃勃,要做大生态. 成为众多功能的叠加. 产品线拉的长, 从另外一个角度也证明, 资金雄厚.

也可以明确一个方向, 做一个专业的方面数据库产品, 如物联网大数据产品, (时序数据库), 大数据分析产品, 或者定位某一个行业, 做行业数据库产品具有某个行业的特性和标签, 相信加以时日的积累,也能有眉目,当然前提也是的有资金做持续的支持,为不断的行业知识累积,同时铸造行业壁垒.

但做任何的产品都必须考虑需求和成本之间的关系,下面列了思维导图, 对产品的功能需求实现做了一个非常不完全的总结

核心功能是对产品的主定位,这点是不能动摇的,剩下的就是用户对功能的需求,以及产品本身的定位, 通用性是为了保证与同类产品竞争中,不处于劣势,产品特殊性功能是为了给自己一个明确的定位,至少你的有一个 slogan让别人记住你.后才是某个客户的定制化的功能需求.

按照排序来说, 通用性排, 是生存之本, 第二是产品的特殊功能 这是产品脱颖而出的和其他产品不在一个赛道的根本,  同类产品的功能需求是第三, 可以有不一致的地方, 后才是客户的定制化, 一般属于费力不讨好, 那客户的多付 M 来实现一些 "所谓的功能".

另一个角度是从产品的成本上来考虑, 也是一个做企业必然要考虑的地方,终究做企业不是来做慈善的.

其实上面已经是车祸现场了, 本着脸皮厚, 不怕被骂的精神,一本正经的胡说八道（胡说八道比较专业） 这里补充一句, 积累和创新的前提 1 活下去, 可能会完成一些看上去SX的客户需求  2 在崎岖的路上摸索经验，逐渐找到分布式数据库产品的定位和市场，改变现状.