共计 3747 个字符，预计需要花费 10 分钟才能阅读完成。
数据库倒退回顾
数据库作为古代软件系统的基石，人们对它的钻研由来已久，尽管到目前为止数据库畛域曾经先后产生过四位图灵奖得主，然而明天它依然是计算机科学中最具生机和翻新的畛域之一。自上世纪 70 年代 Edgar F. Codd 提出关系模型以来，以 IBM SystemR 为原型的关系数据库迅速倒退，并在泛滥行业利用中取得成功，甚至直到明天，关系数据库依然是数据库市场的相对支流。
随着进入 21 世纪以来，因为互联网的衰亡和蓬勃发展，传统的关系数据库开始难以满足疾速倒退的互联网业务的需要。在这样的背景下，轰轰烈烈的 NoSQL 静止揭开序幕，开启了数据库系统从关系数据库的一枝独秀到多种数据库系统百花齐放、百家争鸣的时代。这期间诞生了十分多优良的数据库系统，包含但不限于：
- 以 MongoDB, CouchDB 为代表的文档数据库
- 以 HBase, Cassandra 为代表的宽列数据库
- 以 Google Spanner 为代表的分布式强统一的关系数据库，包含其开源实现 CockroachDB, TiDB
- 以 Apache Druid, ClickHouse 为代表的基于列式存储的剖析型数据库
- 以 InfluxDB, TimescaleDB 为代表的时序数据库
- 以 Elasticsearch 为代表的全文索引数据库
- 以 Neo4j 为代表的图数据库
图 1: db-engines 上统计的各类数据库的数量
图源：https://db-engines.com/en/ran…
数据库系统继续倒退和演进的背地，是近数十年来寰球信息化浪潮下软件系统一直渗透到社会各个行业的过程，而与此同时， 不同行业、不同需要、不同场景也在一直地向数据库系统提出新的挑战。
目前为止，尚没有一个数据库系统能满足全行业、全场景的业务需要——甚至都很难满足一家公司或组织的全副需要。这是因为以后事实世界的业务需要日益简单多样，往往在数据的存储模型、拜访模式、存储的数据规模和时效、计算和剖析能力，运维和部署老本等方面对数据库系统有不同的要求。 繁多的数据库系统个别是基于某种特定的存储和计算模型而开发，因此个别只能在其指标场景下体现良好。
随着今后新兴行业的倒退，新商业市场的开拓，新业务需要的涌现，必将催生新的数据库系统。 比方近年来 IoT 产业以及 AI 行业的衰亡，间接导致了一批新的时序数据库和图数据库的诞生。
图 2: 2013 年以来各类数据库的风行度变动
图源：https://db-engines.com/en/ran…
新的数据存储和计算需要，始终是数据库系统倒退的源能源。
实时流计算的衰亡
随着计算机和网络技术的迅猛发展以及向各行业的一直浸透，现在数据的产生形式和产生起源相比以前都有了极大的丰盛，比方：来自传感器的数据、网站上的用户流动数据、来自挪动终端和智能设施的数据、金融市场的实时交易数据，各种监控程序产生的数据等等。 这些数据大多都是以间断的数据流的模式，从多种内部数据源继续一直地生成，在少数状况下，咱们无法控制这些流数据达到的程序和产生的速率。
依据国内出名剖析机构 IDC 的钻研报告 1， 这种实时的流式数据占总体数据规模的比例正一直攀升，预计 2025 年能达到 30%。
图 3: 实时数据的增长趋势 [1]
传统的数据处理系统通常是对曾经存储在数据库系统或文件系统等其它存储系统中的残缺静态数据集进行计算和剖析，显然不适宜这类继续生成的、有限的、动静的数据流。而且传统的批处理技术在数据生成到数据被解决之间通常会有比拟长的工夫距离，然而在现在强烈竞争、复杂多变的商业环境下， 营销机会转瞬即逝，危险防控必须争分夺秒，商业决策要求疾速精准，因而数据的解决必须在更短的工夫内失去后果，最好是可能做到实时处理。
在这种背景下，实时流解决技术开始在越来越多的场景下逐步代替批处理技术，并在古代的数据分析技术栈中占据外围的地位。 流解决可能天然地对间断的数据流进行建模，与对静态数据的查问和剖析不同，它可能随着新数据的到来实时地对计算结果进行更新，这使得「数据生成」->「获取数据洞察」->「采取行动」之间没有提早， 从而让企业在强烈的市场竞争中始终保持被动和当先劣势。
现在，流解决零碎曾经被各类企业和组织宽泛部署和应用。所有次要的私有云厂商都提供了流式数据存储和实时处理的托管服务，比方：Amazon Kinesis，Google Dataflow 以及 Azure Stream Analytics。开源社区也涌现出一批流解决相干的软件系统，比方：Apache Storm，Apache Flink, Apache Beam 等。同时在过来的几年里，也有越来越多的公司建设了本人外部的流数据平台，以便整个组织可能利用实时计算的力量，比方 Uber 的 AthenaX、Netflix 的 Keystone 平台以及 Facebook 的 Turbine 等。
数据库在流时代的挑战和时机
只管现在越来越多的企业和组织曾经意识到流解决的微小价值并开始利用和部署相干的零碎，目前也有泛滥开源和商业的流处理软件可供选择，但要落地一整套流解决技术栈却绝非易事。 在理论施行的过程中就会发现以后的解决方案普遍存在着：简单难用、部署和运维麻烦、上手门槛高、组件芜杂、API 不对立、迁徙艰难等问题 ，比方以后根本的流解决计划都要波及泛滥的分布式系统和组件，包含但不限于：
- 实时数据采集和捕捉零碎
- 实时数据存储系统
- 流计算引擎
- 上游的数据和利用零碎
这不仅给开发和运维都带来了极大的挑战，而且引入的不同组件的越多，整个零碎的可靠性就越低。同时这些计划中波及的各个组件和零碎不肯定都是适宜且高效的，而且彼此之间的集成往往也并非完满，因而通常很难满足企业的需要。比方流计算引擎要实现 exactly once 的解决语义和端到端的一致性，往往须要依赖流存储系统提供的反对，个别的集成计划很难达到这种要求。
一个有意思的景象在于，以往咱们通常会将某种数据存储和计算的需要诉诸于某类数据库系统，然而 在面对实时数据流时，数据库系统却常见的缺位了。 究其原因，咱们认为一方面是个别的数据库系统很难满足大规模实时数据流的低提早存储需要，这是因为其在保护其存储和索引构造上有绝对较大的开销，造成较高的写入延时。
另外一个更重要的起因，可能和大家对数据库系统的「刻板印象」无关：认为数据库系统都工作在申请 - 响应的模型之下，是命令驱动式的，在这种模式下，计算（命令）是被动的，数据是被动的。然而 流解决的模式却与此齐全相同，它是数据驱动的，即数据是被动的，计算是被动的，数据源源不断地流过计算，并继续更新计算的后果。 正是因为这种差异性，导致人们很难将流解决和数据库关联起来。
然而数据库系统真的全都如此吗？答案当然是否定的。曾经有局部数据库不仅反对申请 - 响应式的命令驱动模型，也反对数据驱动的模型，比方：MongoDB 的 Change Streams 性能，RethinkDB 可能实时的推送数据，：MongoDB 的 Change Streams 性能，RethinkDB 可能实时的推送数据，TimescaleDB 的继续聚合性能。
更进一步， 咱们齐全能够期待用一款业余的数据库系统来解决咱们对数据流治理的全副需要，比方通过相熟的 SQL 语言来不便的进行流计算。
流数据库的诞生
事实上，面对实时数据流的存储和解决，咱们须要的不是一堆零散的 ETL 工具、长期存储数据的消息中间件、孤立的流计算引擎，咱们须要的仅仅是 一个专为流式数据设计的数据库系统，无妨称它为流数据库（streaming database)。
其实流数据库并非是一个咱们明天创造的全新概念，甚至早在 1992 年的一篇发表在 SIGMOD 上的题为 Continuous queries over append-only database2 的论文里曾经摸索过它了。只管这篇论文里并未明确提出流数据库这一概念，但咱们的流数据库和论文的次要思维是一脉相承的。
不仅如此，咱们认为， 不同于其它数据库系统将动态的数据集（表或文档等）作为根本的存储和处理单元，流数据库是以动静的间断数据流作为根本对象，以实时性作为次要特色的数据库。流数据库是数据库在流时代的从新架构和设计。
结语
数据库系统的倒退未然进入一个全新的时代，是时候突破固有观点、发明属于流数据库的将来。在实时数据存储与计算需要一劳永逸的时代背景下， 咱们有理由置信，流数据库将大有可为。
在下篇推送中，咱们将围绕流数据库的存储与各位持续深入探讨，让咱们一起探寻一个高效牢靠的流数据库应有的模样。
同时，咱们也欢送各位退出 EMQ，与咱们独特发现和发明流数据库的有限可能。
- Rydning, David Reinsel–John Gantz–John. “The digitization of the world from edge to core.” Framingham: International Data Corporation (2018). ↩
- Terry, Douglas, et al. “Continuous queries over append-only databases.” Acm Sigmod Record 21.2 (1992): 321-330. [↩
版权申明：本文为 EMQ 原创，转载请注明出处。
原文链接：https://www.emqx.cn/blog/birth-of-streaming-database
