数据库ToB市场的几点观察

近期连续参加了多场数据库技术会议,针对数据库ToB市场的最新变化,自己的一点观察。以下观点仅针对偏重传统企业,互联网企业差异性较大。

1. 传统企业数据库问题

1). 新环境的变化

在谈传统企业数据库转型之前,先来看看相较于过去,传统企业的数据库特点的一些变化。这些也正是促进传统企业积极转型的主要因素。

  • 数据规模大 ✦ 随着企业愈发重视数据使用,越来越多的内外部数据被利用起来。 ✦ 伴随着企业数据化转型,内部的大量数据被整合挖掘出来。 ✦ 随着企业的业务发展(特别是C端),大量数据被收集利用起来。 ✦ 随着物联网、大数据类应用的逐步成熟,数据规模也不断增大。 ✦ 中台”模式的兴起,也对数据的存储、计算在规模上提出了更高的要求。
  • 并发数高 ✦ 和传统业务对比,新型业务(特别是C端),访问用户数往往很大。 ✦ 随着微服务的架构的兴起,很多传统企业也面临微服务化改造,其对数据库端的影响往往就是并发访问数据的增加。
  • 数据特征多样 企业内部的”有价值”数据,不再仅仅限于结构化数据,大量半结构化(如日志)、非结构化(音视频)等逐步被挖掘利用起来。因此,”多模”类需求也逐步被提出。
  • 使用方式融合 与过去传统的TP+AP,非常清晰的数据分层使用不同,现在对数据的使用方式更加灵活,融合方案成为未来的一种趋势。因此可看到HTAP、流式处理等,纷纷登场。
  • 自主可控要求 伴随着内外部环境的变化,近些年来国家已多次从政策层面明确提出了对基础设施的自主可控要求。特别是针对金融、通讯等,涉及国计民生的行业领域,更是提出了强制性规定。这些也正倒逼企业,不得不将基础平台的转型问题提上议事日程。

2). 传统企业的出路

  • 全自主(互联网路线) 作为技术的“先行者”,互联网企业往往站在技术的前沿。上面这些新环境的变化,互联网企业早些年也都已遇到过。很多互联网公司(特别是头部企业),经过多年的积累,往往已经可以很好地解决了上述的问题,并沉淀了一整套成熟的技术及人员。但与互联网不同,很多传统企业无论是在技术积累、人才贮备,还是风险防范等均有不足。对于某些巨头公司,尚可通过短期内加大技术投入,快速补齐短板;但对更多传统企业来讲,还不具备这个能力。
  • 无自主(“云”路线) 随着云技术的成熟,上云似乎是某些企业技术转型的一条“捷径”。受限于中国的国情特点,云技术的私有化部署在中国仍然有较大市场。当然,云路线存在厂商绑定及技术改造等问题,更多是需要在思想层面先行转型。由此,混合云、多云管理,成为当前的一些热点。
  • 混合(商业+自主) 部分沿用商业方案,部分自主完成;这类混合方案是大部分企业比较务实的一种选择。一方面,部分沿用商业方案,可降低转型风险,保证业务稳定;具体操作上,可选择逐步使用多厂商、国产厂商等代替依赖单一厂商、国外厂商的情况。另一方面,部分自主,即可降低对商业的依赖,又可以培养企业自主技术能力。
  • 个例(大数据路线) 对于某些数据使用场景,是可以通过大数据技术进行解决的。但对传统企业来讲,大数据技术似乎也离之甚远。一方面,大数据技术本身对于企业的自主技术能力要求较高;另一方面大数据技术缺乏统一标准,技术分化严重,企业不得不背负较高的技术压力。此外,大量企业的传统业务系统,也需要向大数据栈迁移,而这一生态系统尚不成熟。很多企业自有开发人员或者ISV,还是熟悉SQL+DB的模式。

2. 企业对数据库的诉求

传统企业对数据库要求有其特点,简单整理下(有前后优先顺序)

1). 外在需求

  • 服务 传统企业使用大型商业数据库多年,已经习惯于这种”交钥匙”工程。非常看重其完备的服务能力,使得企业可以安心于业务。即使每年付出昂贵的服务费,但企业仍然可以接受。这点也是目前很多国内厂商的短板,要在短时间内建立其等同于国外数十年积累的企业服务能力,不是一朝一夕的功夫。这是需要国内厂商静下心来,锻炼内功的。
  • 生态 国外大型商业数据库,不仅其自身功能很强大,其周边生态也颇为完善。这不仅包括上下游的配套软件、工具,还包括成熟的架构、设计、开发、运维、测试全栈技术以及积累多年基数很大的技术人才基础。国内厂商要想短期建立其完整生态,也是比较困难的;目前通用的策略是“兼容”。尽量降低用户,使用新型数据库的门槛。
  • 自主可控 作为国家的政策要求,对于某些行业自主可控是必须要考虑的。这一点,无疑对国产厂商有很大的优势。但需要注意的是,对于开源软件的使用,企业也要注意评估风险。一方面是可能存在的法律风险(毕竟开源协议比较繁杂);另一方面是技术风险,对开源代码的理解掌握也是需要企业很大投入的。
  • 性价比 作为商业行为,价格因素也是企业重点考虑的。这里需要关注两点:一是价格本身不仅包括一次性采购,还要计算长期服务的问题;二是对于云服务,可能短期较少,但需要关注其长期费用。

2). 内在需求

  • 可靠性 数据安全,是数据库技术的底线。保证数据准确、不丢失,是很多企业第一位去考虑的。特别是对于分布式等新兴技术,要更加慎重,仔细评估。
  • 可用性 持续可服务,SLA指标在一个较高的水平,也是企业的考察重点。特别是对于核心业务而言,因此可常见的两地三中心、三地五中心等架构,非常常见。
  • 功能 在功能上,应做到尽量完备。特别是对于已经习惯于大型商业数据库的用户。视图、存储过程、支持复杂SQL等很多备受互联网摒弃的功能,对传统企业仍然是必选项。要全部按照互联网模式改造,其代价往往是无法承担的。此外,对于一些新型功能,如多模、混合负载等,也是功能上的加分项。
  • 扩展性 数据库产品,应具备较为完善的计算、存储的扩展能力,来应对企业可能遇到的业务发展或转型。如果在扩展性上有显式的瓶颈,也应提前告知用户。在整个扩展过程中,应做到尽量顺滑、风险可控。
  • 易用性 尽量降低用户的使用门槛,一个窍门是向大厂靠近,符合大多数人的传统习惯。这一点是很多国产厂商,需要重点加强的。

3. 开源方案的利与弊

受到众多互联网公司的影响,很多传统企业对于开源方案也是跃跃欲试。但在选择之前,也要看到,开源方案并不是免费的“蛋糕”。让我们来看看,开源方案的利与弊。

1). “利”的方面

  • 价格 这往往是企业,最先看到的一点。开源软件,可节省大量的商业采购费用。当然,我们这里要算一笔综合的经济账:

价格=采购成本+维护成本+人员成本+时间成本+机会成本

  • 简单、灵活 相较于商业产品,开源产品往往比较简单、配置灵活、不依赖于特有硬件等。在满足企业的技术要求下,这些确实是开源的优势。
  • 可定制 开源的一大特点,就是源码公开,企业可以根据自身特点进行有针对性的改造。对于企业的某些特殊要求,确实只能通过定制化才能完成。
  • 人才+技术 随着近些年来对开源软件的使用,开源的人才已相对较多,企业可以较为容易地招聘到人才。且企业大规模使用开源,也可逐步提升企业自主技术水平,有利于企业的长期发展。

2). “弊”的方面

  • 服务 服务,特别是规模化后的服务。开源方案,一般重点着力于核心功能,其周边功能往往比较薄弱,这对于后期服务很不利。通常企业是依靠自身的人员完成服务。这通常需要一定的投入,且整体服务质量较成熟的商业产品仍有较大差距。这一问题,可通过“开源软件+商业服务”的模式,或者通过云服务来提升整体服务水平。
  • 产品责任 这就是所谓的“兜底”问题。国内的企业,往往已经习惯于有外部厂商帮助其兜底,尽量规避自身风险。使用开源,难以找到指定的责任方,兜底更无从谈起。虽然可依靠某些第三方服务商,但其对开源的掌控能力需要评估。
  • 运维复杂度 成熟商业产品,通常经过完备的设计开发、丰富的周边生态、系统的文档化及多年的锤炼积累,其运维复杂度较低,可快速搭建起完善的运维体系。但对于开源而言,需要从头来做,自己独立完成整个过程。
  • 技术演进路线 开源技术的发展,通常没有固定的主导方。企业很难把控,开源软件未来的发展方向。某些企业急需的特性或bug fix,也很难得到及时的响应。企业整体是缺乏把控力的。
  • 性能 开源软件,在一般简单场景下,其性能不差,甚至好于很多商业产品。但从整体综合性能来看,特别是在复杂场景下,其性能往往表现不佳。因此,针对开源方案,往往强调前期架构设计很重要,发挥其强点、规避弱点。但这对于传统企业尤为困难,企业有很多沉重的历史包袱,很难短时间内完全重构。即使决定重构,也需要逐步摸索,小步迭代。
  • 用户体验 开源软件的第一诉求,是功能的实现,其针对用户体验往往考虑不多。使用惯商业产品的用户,需要一个“由奢入俭”的适应过程。
  • 企业级特点 企业用户,对数据库的使用是有其专有特点。例如:安全审核、数据加密等等。这类功能对于企业很重要,但对其他类用户相对意义不大。很多开源软件,不会在这些上大做功夫。

本文分享自微信公众号 - 韩锋频道(hanfeng_channel)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-11-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏DBA随笔

Innodb数据页简介

Innodb存储引擎在读取一条数据的时候,是将数据记录从磁盘中取出来,然后在内存中进行处理的,当我们写入一条数据时,是将内存中的数据进行修改,然后再刷新...

6230
来自专栏DBA随笔

mysql中的字符集和校验规则

在MySQL中,最常见的字符集有ASCII字符集、latin字符集、GB2312字符集、GBK字符集、UTF8字符集等,下面我们简单介绍下这些字符集:

5110
来自专栏DBA随笔

MySQL动态修改复制过滤器

今天是周五,最近睡眠不好,一整天都浑浑噩噩的,状态不是很好,周五了,准备早点回家,早点休息了,今天的内容写写线上的一个案例,主要是关于主从复制过程中的r...

7810
来自专栏DBA随笔

工作中的任务高并发问题

在开始文章之前,我先把我今天一天做的工作大概罗列一下,看看这一天的时间都怎么被这些任务瓜分了:

8220
来自专栏DBA随笔

insert...on duplicate key update语法

这样的操作乍一看没有什么问题,但是仔细分析分析,还是有些瓶颈的,目前来看,我能分析到的瓶颈有两个,

19430
来自专栏DBA随笔

MySQL常见问题之SQL查询慢

可能是经常处理业务,最近总是听到开发的同学说SQL的查询慢。然后问我为什么,让我在数据库层面找原因。这样的需求接的多了,对于这类需求,我已经有了一套比较官方的...

4010
来自专栏DBA随笔

一个线上的排行榜SQL问题

今天上班的时候,要对一个数据库中的所有慢日志记录进行做一个统计,统计出数据库中所有慢日志用时最长的10条,这个需求乍一听比较简单,数据库中的满日志大概...

7000
来自专栏DBA随笔

Linux中的NFS挂载问题

Linux中的NFS挂载问题 在Linux环境中,如果你经常进行mysql的数据备份,可能会遇到备份机挂载在线上环境的问题,今天我们说说NFS备份机目录...

20120
来自专栏DBA随笔

MySQL的行转列

所谓的行转列操作,就是将一个表的行信息转化为列信息,说着可能比较笼统,这里先举个例子,如下:

5610
来自专栏DBA随笔

MySQL中binlog的三种格式

在MySQL中,我们经常需要打开binlog来观察用户对某一个数据库的操作,binlog中记载着对用户数据库所做的所有修改类操作,例如delete,up...

4810

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励