數據庫發展回顧
-
數據庫作為現代軟件系統的基石，人們對它的研究由來已久，雖然到目前為止數據庫領域已經先后產生過四位圖靈獎得主，但是今天它仍然是計算機科學中最具活力和創新的領域之一。自上世紀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 上統計的各類數據庫的數量
數據庫系統持續發展和演進的背后，是近數十年來全球信息化浪潮下軟件系統不斷滲透到社會各個行業的過程，而與此同時， 不同行業、不同需求、不同場景也在不斷地向數據庫系統提出新的挑戰。
目前為止，尚沒有一個數據庫系統能滿足全行業、全場景的業務需求——甚至都很難滿足一家公司或組織的全部需求。這是因為當前現實世界的業務需求日益復雜多樣，往往在數據的存儲模型、訪問模式、存儲的數據規模和時效、計算和分析能力，運維和部署成本等方面對數據庫系統有不同的要求。 單一的數據庫系統一般是基於某種特定的存儲和計算模型而開發，因而一般只能在其目標場景下表現良好。
隨着今后新興行業的發展，新商業市場的開辟，新業務需求的涌現，必將催生新的數據庫系統。 比如近年來 IoT 產業以及 AI 行業的興起，直接導致了一批新的時序數據庫和圖數據庫的誕生。
圖 2: 2013 年以來各類數據庫的流行度變化
新的數據存儲和計算需求，始終是數據庫系統發展的源動力。
實時流計算的興起
隨着計算機和網絡技術的迅猛發展以及向各行業的不斷滲透，如今數據的產生方式和產生來源相比以前都有了極大的豐富，比如：來自傳感器的數據、網站上的用戶活動數據、來自移動終端和智能設備的數據、金融市場的實時交易數據，各種監控程序產生的數據等等。 這些數據大多都是以連續的數據流的形式，從多種外部數據源持續不斷地生成，在多數情況下，我們無法控制這些流數據到達的順序和產生的速率。
根據國際知名分析機構 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 原創，轉載請注明出處。