数据库管理-第125期 融合vs专用（202301221）

数据库管理-第125期 融合vs专用（202301221）

最近参加的两场活动，一次是11月的SACC上海站(《向量数据库技术探索》专场)，一次是上周六的《国产数据库共话未来趋势》主题活动，虽然二者讨论内容与范围有很大区别，但是关于是否需要专用向量数据库和时序数据量的讨论，确是一致的，即在一个特定的数据领域是否需要独立的专用类型数据库。我认为这需要从好几个方向考虑。

1 便捷性

其实很多时候吧，业务发展是需要数据库快速跟上的，这一点使用专用数据库的优势就显现出来了，数据库的定制化开发与单一功能的实现是可以快速实现的，确实可以很快支撑相关业务的发展。在传统数据库融合新功能，往往需要付出很大的努力，往往需要耗费较多的时间，很难实现敏捷上线。

2 性能

这时候又得说出专用数据库的另一个优势了，因为专注于一件事情不需要考虑其他过多的东西，在这个专用场景下往往都能发挥出较好的性能。这一点如果使用传统数据库融合新功能，特别是比较复杂的新功能，数据库没有做好相关研发优化的情况下，往往不能很好的支撑新功能的高性能实现。
回到传统数据库融合的方式来，如果能做到多种类型数据的统一存放统一查询，简化业务研发难度而且性能能够赶上专用数据库（或者能够快于使用专用数据库的架构场景），从SACC的反馈来看，很多业务方会毫不犹豫使用融合数据库。

3 架构

话又说回来，无论专用数据库再怎么厉害，有一件事情是绕不过去的，无论是向量数据还是时序数据抑或是其他类型的非关系型数据，最终产生价值都需要于传统数据做关联，使用专用数据库就会出现数据的多次流转的问题，多次在不同类型数据库之间的分步查询，会产生时间和网络上的更多损耗。另一方面，多一个数据层面的组件也会显著增加了整体数据架构层的复杂度，增加研发和维护的难度。这一点又是传统数据库融合功能的一些优势。

一些观点

• 薛首席在SACC说过：“平时外出，没有特别需求我会用手机拍照；但如果是婚纱照我会找影楼”。
• 熊灿灿上周在《国产数据库共话未来趋势》说：“把复杂留给数据库，把简单送给研发”
• AWS是针对每种数据类型和工作量运行单一用途的专有数据库
• Oracle是针对多种数据类型和所有工作负载运行融合开放式数据库
  等等

我认为吧，还是得从业务场景、上线周期要求、数据量、业务量、性能要求、研发能力、运维能力、云上&云下等维度出发（感觉又说了一堆废话），来选择使用专用数据库还是融合数据库。
老规矩，不知道写了些啥。