对DBA、开发、测试、产品同时友好大规模多存储场景的数据库选型与服务平台建设( 二 ) _数据库

DBA不再是用户眼里那个总是说NO ，或者躲在幕后的英雄。而是以产品运营的方式将能力最大化输出，以解决用户麻烦的思路去看待问题，更好地服务公司的业务。

二、需求驱动的数据库选型
1、业务场景是需求的灵魂
现在我们来讲第二部分，需求驱动的数据库选型。首先来看一个概念，什么叫业务场景？业务场景一般指企业和商家需要在用户某个特定的环节中，适时提供给消费者可能需要的以及关联的产品或服务。
一般来说用户使用我们的产品后，都会获得反馈。首先用户需要接触和使用到我们的产品或者服务；其次用户使用后，要么是满足了用户的需求，要么是解决了用户的问题或者在使用过程中遇到了一些困难或者障碍，这样我们就可以得到用户对产品的反馈，并形成一个循环。

文章插图
总的来说，业务场景是需求的灵魂，并且需求不是凭空出现的，是基于业务场景出现的。简单总结就是：【“谁”在“什么环境下” ， “干什么/遇到什么问题” ， “如何解决这些问题” ， “产生什么样的价值”】，这点在后面讨论数据库选型和服务平台建设时，是很关键的的一个套路。
2、我们的业务场景-场景分类
接下来说我们的业务场景，这里主要针对的是依附于vivo手机的场景，不包括硬件产品。从软件产品生态来看，主要分为以下六类：

推荐场景：应用商店、信息流、音乐、视频、小说等
账号系统：全系业务场景
广告场景：信息流、应用商店、小说、视频等
交易场景：音乐VIP、主题、云服务、游戏等
下载场景：应用商店、系统升级、主题等
推送场景：信息推送、天气、闹钟、语音助手等

上面是一些vivo产品的截图，有在使用vivo产品的同学可以试用下。应用场景分类之后，我们来看下，针对这些业务场景如何进行数据库服务选型。
3、数据库选型实践
1）数据库画像
这里我们使用了雷达图这个工具，把各种数据库抽象成为五个方向的能力，并列举了一些常见数据库产品：

文章插图
第一个是数据规模，单集群建议的数据存储规模。针对业务场景，看看这个场景下的数据规模如何，关于这点没有绝对的建议，只需按照业界的最佳实践来做就行。
第二是响应时延，最佳实践下的平均响应时延。这个很好理解，看你的业务场景是用户业务还是离线业务，是同步的还是异步等。
第三个是数据模型，这部分比较关键，主要指的是结构化、非结构化、事务等，可以抽象为数据模型，或者业务模型都可以。举个例子，前面提到的账号或者交易的场景，这种数据肯定需要关系型数据库来支撑的；前面还提到的推荐业务，可能有几千个特征或者标签，这种时候用关系型数据库来支撑就不太合适。
第四个是数据安全性，指的是存储系统的稳定性、可靠性、数据的安全性。这也比较好理解，当然绝大多数系统都标榜自己的稳定性和可靠性如何如何，但只需要从原理上仔细对比就可以看出差异，比如使用Redis就不能保证数据一定不丢失，这是由它本身内存这种易失型介质导致的。
第五个是扩展性，主要是指扩展的便利性和扩展时对业务连续性的影响。这个主要还是看业务，如果业务的数据量在未来有扩展的需求，那这个就要重点对待，有些数据库产品的扩容是很痛苦的或者扩容的过程中对业务的影响并不能做到业务无感知。
这就是用雷达图把数据库产品进行抽象对比，这样就能看出是数据库产品的特长在哪儿，方便我们去做选型。
最后一点不在这个雷达图里面，但是至关重要，就是DBA的能力范围，不要做超越DBA能力范围的选型。回到前面对 DBA+DBRMS的定义，如果DBA不能cover住这个数据库产品，那么对外暴露出的就是一个不稳定的、不靠谱的产品，不仅影响公司业务还影响公司口碑。所以在能力范围内做事情，不反对尝鲜，但针对生产环境还是要谨慎对待。