数据库与数据仓库的本质区别是什么？

点击蓝色“有关SQL”关注我哟

加个“星标”，天天与10000人一起快乐成长

图 | 榖依米

文章较长，可收藏后看。本文最后，准备了文中谈到的资料，可自取。

在知乎上看到这么个问题：

数据库与数据仓库的本质区别是什么？

其实，我很反感本质这个词儿。因为本质这个词，抽象，模糊，不好定性。回答者好心倾囊相授，诡辩者却以一句“ 你没有明白我的意思，你说的本质和我说的，不一样！我的意思是……” balabala

去特么的本质！这分明是给偷懒者的一个词儿。

要说本质，就要有分门别类的标准，要把抽象细化下来，这非常考验人的形象与归纳思维。人与人之间，理解有偏差，谈话中对方跟不上，就容易造成误解。这种事情太多了。

那么我把这个题目改一改，问，数据库与数据仓库的应用区别是什么？这样就好多了。至少，我们明确了在应用这个方向上，讨论“本质区别”。但事实上，这样问也不够好，还是模糊。这相当于问，“咖啡店与星巴克的区别是什么”。是不是很奇怪，有谁会问这么二的问题呢？

所以我说，问题本身就不够明确。为什么，你往下看就知道了。

既然谈到了应用，那主体肯定是人，只有人，才是应用的驱动体。站在人的角度来看，两者的区别就会清晰很多。

首先，我们来看下，数据的应用有哪些。

第一种应用，我在淘票票买了电影票：

这类应用，特点都是实时交互，我付了款，立马得到服务。比如购物，餐饮，交通等等。我们称之为 OLTP，也就是传统上所说的“关系型事务数据库”应用。

第二种应用，我用支付宝的记账本，分析了下我本月的支出与收入：

这类应用，通常会涉及很长一段时间的数据读取，最终的数据呈现会以多种维度组织，实时性不高，但维度一定不止一维。比如支付宝年底的【我的2020】，它帮我们分析了全年的支出，哪个品类消耗最多资金，去过哪些城市，最钟爱哪类消费品等等。这类应用属于数据仓库的数据分析细分领域，也称之为 OLAP.

理解了这两类应用后，我们进一步归类。无论是 OLTP 还是 OLAP，其实都是数据库应用，都要以数据库作为存储和处理基础。OLAP 数据仓库技术，不过是数据库应用中的一种。但数据库和数据仓库是否一定要以关系型事务数据库作为基础呢，不是的。我们接着往下分析。

数据库

刚才我们谈到应用，继而谈到应用的主体，人。那么谈人的时候，又有必要从人经历的历史，来看人的发展。以下是半个世纪来，人们在使用数据库上的历史节点。

刚开始，人们在应用数据需求上，使用各类不同的数据模型，有 Network Model, Hierarchical Model,还有 Relational Model.

比较好理解的是，Hierarchical Model ：

有一对多的层级关系，最适合用来记录上下级关系的数据。比如部门组织架构，会计分录，工业制造常用的BOM(物料清单)等。

接下来，特殊应用就是网络模型(Network Model):

20世纪50年代的计算机应用水平，还没有互联网概念。以现在发达的社交网络来理解网络模型，最合适不过。对，就是平常我们所说的社交网络。比如微博，微信，抖音等等。人与人之间的联系，就像一张网。两两认识的朋友，早晚也会成为朋友，用6度人脉来解释，就是你要认识王思聪，也只要找到关键的6个人带你。

领衔数据库发展潮流，霸榜半个世纪的理论，是关系型数据库

1970 年开始，让全世界震惊的关系型数据库论文《大型共享数据库数据的关系模型》在ACM发表了。由此打开了关系型数据库霸榜的序幕。从1973年开始，数据库厂商都开始以 IBM System R 为蓝本，开发自己的商用版本。比如 Oracle, IBM DB2, SQL Server , PostgreSQL 等等。他们起先做的事情和我们现在并无二样，就是记录银行流水，航空订票，甚至美国中央情报局，军方机构都采购Oracle.

以 NoSQL,NewSQL 展开数据库新时代序幕

随着手机，尤其是智能手机，智能平板，互联网应用的发展，关系型数据库在处理这些应用上逐渐吃力，因此 Redis, MongoDB, ElasticSearch 逐渐有了市场。他们的操作语法，看似和关系型数据库没有相似之处，但在组成架构上却还有些异曲同工，目的是把原来在关系型数据库中不好处理的部分，经过结构规范化，存储优化，索引优化等技术，使得这些非关系型结构化的数据处理，变得更加高效。

并不是说，传统的应用中就没有今天互联网时代的应用，也有的。比如网站的打日志，全网搜索等。但那个时代并没有那么多流量，没有那么多人来访问应用，所以使用关系型数据库存储和处理这些数据还绰绰有余。但在流量爆发的今天，数据量早已不是当年可比。要存储和处理这些大数据，必须采用新新技术。

比如MongoDB的数据分片，可以把用户操作日志放入操作日志集群中，把搜索日志放入搜索集群中；而用户的搜索，可以单独放入 ElasticSearch 中，使得搜索这种高吞吐量的操作不再占用宝贵的 OLTP 服务器资源。

这些都是传统的关系型数据库在处理今天互联网应用上逐渐吃力的表现。

功能上的缺陷，使得关系型数据库丢失了一部分市场。可真正让厂商焦虑的，是处理 OLTP 事务上的瓶颈。这才是关系型数据库真正感到无力的地方。比如淘宝每年的双十一，OceanBase  最高峰值达到每秒 6100 万。然而，传统的数据库，依据Oracle 的 TPC-C 打榜数据，只有 300万，完全支撑不住。当然这是 Oracle 2009年的数据，现今的 O 记云，能打到多少 QpmC，我们也不知道。

所以我说，真正让传统的RDBMS厂商感到恐慌的，应该是大吞吐量事务处理的无力。

至此，所有的应用，我们都可以称之为数据库应用。当然，也包括数据仓库。20世纪70年代以来，市场上占据主导地位的，还是关系型数据库。使用关系型数据库搭建数据仓库，完全顺其自然，也合情合理。Kimball 与 Inmon 最初的数据仓库理论，都以关系型数据库作为底层存储架构。

但 Google 的大数据三驾马车出现后，情况开始变了。

FileSystem, BigTable, MapReduce 的出现，使得大吞吐量的数据仓库不再遥不可及，原先的RDBMS解决方案是利用时间差，来解决复杂查询
的效率问题，但在数据量和吞吐量达到单台服务器容量极限后，再多的数据量也就难以负载了。

Google三驾马车的出现，使得多台，甚至千台数据库服务共同计算变成可能。一个人的力量是有限的，但一群人的力量就不可估量了。机器也是一样，关键在于调度。

先讨论早期的数据仓库技术及产品

刚才谈到，关系型数据库技术，早期用来服务银行，航空，军方情报等行业。这些应用主要的功能是处理数据的输入与输出。能够把数据做到准确，安全，一致，就已经达标了。这系列应用，我们称之为 OLTP(在线联机事务处理)

但，随着输入的增多，输出就成为了瓶颈，最重要的就是数据分析变得吃力，响应需要等待很长时间，而且有时候结果甚至都出不来，还严重拖慢了数据输入的功能。

因此，全世界都意识到，大量数据的分析，应该和数据的输入系统，也就是业务系统分开来治理。这，就是数据仓库思维的启蒙。

进一步将数据模型优化成关系型数据模型与多维度数据模型概念的，是Kimball.  他的多维度数据模型虽然可以用关系型数据库实现，但数据结构的组织，已经完全不同于OLTP的使用规范，而是更接近于 OLAP，也就是在线联机分析处理。

正因为又了多维度数据模型，OLAP才有了新的产品。新的非关系型OLAP产品，与OLTP的关系型数据库，完全就不是一个架构了。比如 SQL Server Cube, Hyperion Essbase,DB2 OLAP Server 等等.他们采用了一种叫做稀疏性矩阵的技术。

以分布式数据库作为数据仓库技术的新起点

半个世纪以来，数据库世界一直都是关系型数据库的天下。那么多的业务系统都建立在RDBMS上，那么顺理成章，数据仓库也以RDBMS为基建了。这样一来，无论是硬件成本，还是人力成本，都可以减少到最少。

但摩尔定律一定是支配者信息产业的发展，每过18个个月翻番的，不仅仅是计算机硬件性能，对软件也提出更高的要求，数据库就更加严苛了。大家回忆下半年前，你们的数据库有多大，再想想现在你们的数据库有多大，就明白了。

所以，大小型机，受制于单台资源，在日益增大的数据面前，毫无应招之力，只能让步于分布式数据库。以Hadoop的横空出世为起点，数据仓库终于不再以RDBMS马首是瞻，纷纷投奔分布式的非关系型数据库。

跟RDBMS如出一辙，Hadoop一战成名之后，后起之秀就越来越多，也越来越猛。原本 Hive 这样的非实时数据仓库，已经取得了很大的市场，但随着实时数据技术的渴求与引入，Spark, Flink 这样的分布式计算也日益得到人们的青睐。

真是“问世间，是否此山最高  或者另有高处比天高。”

计算机的世界就是这样，你追我赶，你方唱罢，我方登场。总有软件比你更快，更好，也总有人，比你更懂SQL

分布式数据库的技术派别

分布式数据库，在提高系统吞吐量，降低服务器高负载，提高作业系统性能等方面，均做出了很好的优化。数据在爆量的情况下，采用分布式数据库系统又变得自然不过了。

那么究竟有哪些分布式数据库呢？

其实分布式数据库自数据库发展以来，就没有停过。Oracle, SQL Server 在创立之初，就有各自实现分布式数据库的方法。不过那个时候，我们倾向于把这些叫做产品功能，比如高可用，复制，镜像技术，或者读写分离。

严格来说，这些分布式与我们今天所说的分布式，完全不一样。最重要的一点，商业数据库的分布式产品，都是高度自治的，那可真的是分布式，一台数据库服务器，与另外的分布式数据库服务器，不共享硬盘，也不共享内存与CPU.看上去完全无关，但逻辑上还是有联系，围绕着同一个应用，一台服务器供写入数据，另一台或者几台则供查询读取。数据同步使用 CDC, BAT 脚本等方式完成。

但若继续采用上面的架构，流量再翻10倍，100倍，肯定就顶不住了，因为单机作战能力并不能无限升级，也就不能线性增长。这时，必须采用严格的分布式架构，使每一种数据，都落地在不同的数据库服务器上。比如江苏，上海，浙江的销售数据，分布在不同的机器上。如果业务继续扩展，增加了广州，北京，东北区域，那么再添加三台机器，分别用来承载这三个地区的销售数据，这样就完全可以抵住新增的业务吞吐量。

这个时候， MPP 和 Hadoop 为代表的两类分布式计算架构出现在市场，也算是应运而生了。当然这是另外的话题。

公众号后台回复“三驾马车”，可得 Google 大数据论文

--完--

往期精彩：

本号精华合集（二）

如何写好 5000 行的 SQL 代码

如何提高阅读 SQL 源代码的快感

我在面试数据库工程师候选人时，常问的一些题

零基础 SQL 数据库小白，从入门到精通的学习路线与书单