为什么数据库选型和找对象一样重要

为什么数据库选型和找对象一样重要

一、找对象

正常路径:

• 知己 -> 缘分出现 -> 恋爱[知彼] -> 结婚 -> 2个家庭关系结合(七大姑八大姨) -> 生娃 -> 带娃 -> 七年之痒 -> 愉快的共度一生

错误后果:

• 1、家庭不和睦
• 2、影响小孩成长

• 3、离婚

  • 生无可恋
  • 财产分割
  • [娃]的成长、抚养问题等
  • 家庭关系处理
• 4、再婚

二、数据库选型

正常路径:

• 评估 -> [技术磨合] -> 研发 -> 上线 -> 迭代维护期

错误后果:

• 1、研发、维护、软件、硬件成本增加,

  • 性能问题
  • 线下输出, 某些开源协议导致的软件分发风险
  • 架构迁就数据库, 导致开发周期变长、软件|硬件|维护成本增加

• 2、影响业务, 营收、客户数,

  • 如果出现异常, 导致业务受到影响

• 3、企业形象

  • 稳定性、安全问题、数据泄露等问题...

三、谁为数据库选型负责

• 开发者?
• DBA?
• 架构师?
• 技术总监?
• CTO?
• 技术委员会?

怎么选型?

四、选型中最容易踩到的几个坑

• 大公司用什么我就用什么, 没大错.
• 用熟不用生.
• 统一技术栈, 一个库解决一切.

五、在什么时间点选型?

架构设计阶段

六、架构设计阶段有哪些能确定|预判的指标?

一定不完整, 请各位自行补充

1、技术指标

1、业务类别(在线事务处理、离线分析、实时分析、混合业务)
2、业务场景
3、数据量
4、业务场景相关性能指标(并发、qps、rt)
5、行业合规诉求
6、开发语言
7、应用级功能诉求(图像识别, 分词搜索, GIS, 用户画像, 化学分析, 多维搜索, ...)
8、各种场景的工业标准性能指标(tpcc tpch tpcds)
9、可用性
10、可靠性
11、安全
12、一致性要求
13、扩展性要求
14、容灾要求
15、可恢复的目标范围要求
16、恢复耗时要求

2、商务指标

1、业界成功案例
2、使用这个产品时的开发周期
3、使用这个产品时的开发人力投入成本
4、使用这个产品时的项目it投入成本
5、数据库软件license成本(不同输出形式下的成本和风险)
6、数据库运维人力投入成本
7、[云产品成本]

3、生态指标

1、发展趋势(全球趋势、本土趋势: 谷歌搜索趋势、stackoverflow趋势、招聘数量)
2、活跃度(bug响应速度, 修复速度. 小版本发布频率. 大版本发布频率. 提交数.)
3、培训公司数量、规模(全球、本土)
4、学习成本(有数据库基础到达中级水平需要多长时间)
5、服务公司数量、规模(全球、本土)
6、云厂商数量、规模
7、数据库厂商数量、规模
8、社区规模(人数、内容、活动、流量)
9、市场份额

七、建立DB画像库

建议定期更新数据

数据库种类

一定不完整, 请各位自行补充

• 缓存
• 关系
• 离线仓库
• 在线仓库
• nosql
• 时序
• 图
• GIS
• ...

画像库

一定不完整, 请各位自行补充

• pg,
• mysql,
• oracle,
• greenplum,
• polardb o,
• adb pg,
• redis,
• hbase,
• mongo,
• timescaledb,
• agensgraph,
• edgedb,
• postgis,
• ... ...

八、数据库产品很多, 怎么做到深度分析?

1、内部技术专家

• 建议技术栈多元化, 提高技术竞争力.

2、聘请外部技术顾问

• 推荐, 没屁股, 比较公正

3、外部参考资源

• 权威行业报告

九、建立评估模型

类似招标书，建立评估模型。

1、技术分

2、商务分

3、生态分

直播地址

免费领取阿里云RDS PostgreSQL实例、ECS虚拟机