数据库管理-第337期 换个角度看集中与分布（20240617）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE Partner
10年数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著 名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸
CSDN：胖头鱼的鱼缸（尹海文）
墨天轮：胖头鱼的鱼缸
ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

突然发现又有5天没写文章了，主要是上周又因为热伤风感冒发烧，然后一不小心差点把自己右脚大拇指指甲盖给废了，上周六还参加了IFClub成都站的活动，所以稍微放松了一下。这两天看了韩锋老师的文章《 浅谈分布式、伪分布式与集中式之选》，今天有看到曹宇老师的《 集中式，分布式，到底“集”或“分”了什么》，我也想从另一个角度再来聊一下数据的集中与分布，事先声明本期其实不是讲数据库的集中式与分布式。

1 生产数据的使用应当集中

数据是关联的，无论是传统的结构化数据，还是非结构数据，它们关联在一起才能发挥出价值。但是如果按照以前的IT架构，即每一种数据使用一种数据库，比如标量数据使用MySQL/PG、JSON数据使用MongoDB、向量数据使用Milvus、KV数据使用Redis等等；不同的数据用途还有不同的数据库，比如Redis还可以作为缓存、ES用于全局检索、ClickHouse/Doris用于查询加速、Hadoop用于海量数据的离线分析等等。
这样的IT架构也带来了一些问题：不同的数据需要存放在不同的数据库之中，但这些数据又是关联使用的，要么将数据抽取到应用层进行结合处理，这需要在不同的数据库中有统一且唯一的标识符用于数据关联，对于全局数据一致性的校验要求就会非常高；要么就是将这些数据根据实际用途抽取到其他地方再做使用，这需要做好ETL/CDC，管理好数据同步链路，这样也势必会增加数据操作的延迟；还有一个问题就是技术栈繁杂，开发、维护、管理的难度大。
在21世纪第二个十年结束的前后，Oracle提出了融合数据库，OceanBase提出了数据库一体化，其主要目的是为了解决以下几个问题：

• 多模数据存储在一个数据库内，且多模数据可以以多种方式进行存放并被关联使用
• 一个数据库解决OLTP、OLAP、HTAP、缓存、消息队列等多种负载，解决大多数数据方面的需求
• 支持AI能力扩展，可以使用向量存储检索能力实现DB4AI

2 海量数据的使用与分析应当均衡

数据是有价值的，无论是当前产生的生产数据，还是近期的流转数据，亦或是长期存储的历史数据，如同以历鉴今一样，它们也是能分析出很多有用的东西。但是随着业务的不断扩展、数据来源的扩增以及时间的不断积累，特别是历史数据的数据量会达到一个可怕的程度，这也势必会超过单机或者小规模集群的承载力，这也导致了我们需要依托较多的服务器、高速稳定网络、高性能存储设备与数据分层存储等来实现海量数据的存放。
在海量数据的场景下我们需要考虑：

• 冷热数据分层存放中，成本与数据使用效率的平衡
• 在存算分离、存算一体、集中式使用+分布式存储、分布式数据库等选型方向进行组合权衡
• 节点间数据分布与交互设计需要充分考虑数据特性与计算分析要求
• 无论如何存储并使用数据都需要同时要满足业务发展快速变更的需求
• 技术栈选择带来的开发、维护、管理、成本等各方面平衡

3 数据安全必须分布

老话说得好“鸡蛋不能放在一个篮子里”，数据安全亦是如此，数据是现代IT架构的基石，说严重点，只要数据还在，上层业务应用就还在，因此数据的安全存储是非常重要的一件事情。在我的职业生涯中，还是出现过好几次机房断电、存储异常等导致的数据库不可用，因此我们需要避免IDC级别故障带来的数据丢失，那么跨IDC的数据容灾是必须要做的。
另一方面，我们还需要考虑一定程度的数据回溯能力以避免类似于数据误删等误操作，用以恢复数据，这就需要针对重点数据进行离线备份，如果数据安全要求足够高，离线数据甚至还会在所有数据中心的异地。

总结

本期换了个角度，从生产数据、海量历史数据与数据安全角度来看数据的集中与分布。
老规矩，知道写了些啥。