在当前数据库领域最热门的话题之一就是one size can fit all or not，我打算尽可能系统地分析一下，内容会同时覆盖学术界和工业界。划分数据库workload的做法很早就有了，比如AP和TP的划分就是由Codd在1993年提出的。
一、工业界和学术界中数据库的研究热点
在当前数据库领域最热门的话题之一就是one size can fit all or not，我打算尽可能系统地分析一下，内容会同时覆盖学术界和工业界。
分离
划分数据库workload的做法很早就有了，比如AP和TP的划分就是由Codd在1993年提出的。One size cannot fit all的意思就是一种数据库无法满足所有的需求，所以我们需要根据不同需求来造出不同的数据库，这种说法来自于Stonebraker。
Stonebraker在Berkeley时期做出了Ingres、Postgres，与Oracle等数据库供应商展开了激烈的竞争。那时候用RDBMS就可以满足几乎所有数据存储需求，one size can fit all。
而在MIT时期，他到ICDE 2005上发了篇《”One Size Fits All”: An Idea Whose Time Has Come and Gone》，宣告one size can fit all的时代已死，并在不同的场合宣扬，使其广为人知。随后他以身作则排列组合出了各种数据库，包括做OLAP的C-Store（后改名为Vertica），做内存OLTP的H-Store（后改名为VoltDB），做科学计算的SciDB等等，同时不断开公司卖公司，在2014年时就已co-founded了9家公司。
虽然Stonebraker提出one size cannot fit all可能有其商业目的，但这句话本身是有合理性的。数据库中各部分往往耦合臃肿，从头做方便探索针对特定情形的架构设计与优化。想一口气做出AP+TP+relational+graph+JSON+ACID+SQL只能是over design，和GNU Hurd一样止于流产。
通过quad chart排列组合产生数据库idea的方法也来自Stonebraker，并从他的身边的人传播到了整个领域。
融合
话说天下大势，分久必合，合久必分。就在Stonebraker发出one size cannot fit all的豪言没多久，SAP就做出了HANA这个大一统数据库，在SIGMOD 2009会上当着Stonebraker的面上台讲起了同时处理OLAP和OLTP的新型数据库，把Stonebraker搞得气急败坏。
将各种需求统一处理的好处在于它能降低机器、学习、运维等成本，不用同时处理一堆又一堆的组件。大数据生态的那一堆组件互联网企业都头疼，对于传统企业就更困难了。比如OceanBase在解释做HTAP的原因时就举例说，有些用户连AP、TP是什么都不知道，因为他们以前用的是Oracle。
近些年都合并趋势非常之多，细数起来包括以下几点：
- RDBMS和NoSQL的合并，a.k.a. NewSQL。Andy Povlo在《What’s Really New with NewSQL?》中把NewSQL分为三种：new architectures、database-as-a-service和transparent sharding middleware。虽然很多人都是只把Google Spanner、TiDB这种new architectures和Amazon Aurora这种DBaaS视为NewSQL。
- 混合事务分析处理，a.k.a HTAP。为了防止AP影响TP，现在HTAP一般都将AP和TP物理隔离成两套系统，在内部通过CDC或者Raft复制等方式进行同步。目前看来，HTAP成功得彻彻底底，占领了越来越多的轻量分析市场。
- 多种查询能力的融合，a.k.a. 联邦查询。devcon2021报告。联邦查询的概念来自于Postgres，指将其他数据库数据源当成它内部的一张表。以TiDB为代表的HTAP把列存融入了TP中，那能不能像MySQL那样把全文检索、文档甚至graph等也融进去呢？而恰好后来听Milvus
@Zilliz
的报告时发现他们也提到，Milvus等purpose-built数据库除了纵向挖深外，能不能横向融入其他模型的能力呢？比如不少用户呼吁的向量数据库和graph的融合。
- 批处理和流处理的融合，a.k.a 计算层的流批一体。由于Storm没实现exactly-once语义来保证正确性，其创始人Nathan提出了Lambda架构流批分离。2015年，谷歌发布Dataflow模型，将批处理归为流处理的特殊情况。接着Flink抓住机会采用了Dataflow模型实现了接口层的流批一体，在来自阿里的Blink分支合入后实现了内部运行的流批一体。当然，Spark也在流批一体上奋勇直追，用Structured Streaming替代落后的Spark Streaming，增强了其流处理能力。
- 文件存储和流存储的融合，a.k.a 存储层的流批一体。通常，流处理读消息队列，批处理读文件系统。近些年，流批一体的趋势从计算层蔓延到了存储层。Iceberg和Hudi等数据湖基于文件来实现队列特性，而Pulsar和Pravega等消息队列基于队列来实现文件特性。在这个场景下，文件的变化可以生成流，流又可以聚合成文件。
分离和融合的本质是用户需求和技术实现的trade off。像MapReduce那样将整个数据库领域推倒重来确实技术上解决了scalable的问题，但代价就是功能完整和使用体验。随着屠龙少年成长为了恶龙，整个领域也开始回归到了分布式的本质，从二选一进化到了全都要。
如果说one size cannot fit all是为了更好地实现功能，那one size can fit all again就是对整个数据库领域的重构。代码的主要功能实现完了，自然该重构了。当然，新的功能还在持续开发，purpose-built数据库也依旧有其市场。
延伸阅读：
二、按照SQL标准的解释Catalog和Schema
在SQL环境下Catalog和Schema都属于抽象概念，可以把它们理解为一个容器或者数据库对象命名空间中的一个层次，主要 用来解决命名冲突问题。从概念上说，一个数据库系统包含多个Catalog，每个Catalog又包含多个Schema，而每个Schema又包含多个数据库对象（表、视图、字段等），反过来讲一个数据库对象必然属于一个Schema，而该Schema又必然属于一个Catalog，这样我们就可以得到该数据库对象的完全限定名称从而解决命名冲突的问题了；例如数据库对象表的完全限定名称就可以表示为：Catalog名称.Schema名称.表名称。这里 还有一点需要注意的是，SQL标准并不要求每个数据库对象的完全限定名称是少数的，就象域名一样，如果喜欢的话，每个IP地址都可以拥有多个域名。
通俗点理解：
schema是对一个数据库的结构描述。在一个关系型数据库里面，schema定义了表、每个表的字段，还有表和字段之间的关系。
catalog是由一个数据库实例的元数据组成的，包括基本表，同义词，索引，用户等等。
或许更通俗还可以这样理解：
schema有点类似于类，catalog有点类似于对象。
