實(shí)時(shí)數(shù)據(jù)處理是運(yùn)行以現(xiàn)代技術(shù)為導(dǎo)向的業(yè)務(wù)的基礎(chǔ)方面?？蛻舯纫酝魏螘r(shí)候都想要更快的結(jié)果，并且會(huì)在獲得更快結(jié)果的絲毫機(jī)會(huì)上背叛。因此，如今的組織都在不斷地尋求減少響應(yīng)的毫秒數(shù)。

實(shí)時(shí)處理接管了之前使用批處理處理的大部分方面。實(shí)時(shí)處理需要對(duì)傳入的數(shù)據(jù)流執(zhí)行業(yè)務(wù)邏輯。這與將數(shù)據(jù)存儲(chǔ)在數(shù)據(jù)庫(kù)中然后執(zhí)行分析查詢的傳統(tǒng)方式形成鮮明對(duì)比。此類應(yīng)用程序無(wú)法承受先將數(shù)據(jù)加載到傳統(tǒng)數(shù)據(jù)庫(kù)然后再執(zhí)行查詢所涉及的延遲。這為流式數(shù)據(jù)庫(kù)奠定了基礎(chǔ)。流式數(shù)據(jù)庫(kù)是可以接收高速數(shù)據(jù)并在移動(dòng)中處理它們的數(shù)據(jù)存儲(chǔ)，而無(wú)需混合使用傳統(tǒng)數(shù)據(jù)庫(kù)。它們不是傳統(tǒng)數(shù)據(jù)庫(kù)的直接替代品，但擅長(zhǎng)處理高速數(shù)據(jù)。本文將涵蓋流式數(shù)據(jù)庫(kù)的四個(gè)關(guān)鍵設(shè)計(jì)原則和保證。

了解流式數(shù)據(jù)庫(kù)

流式數(shù)據(jù)庫(kù)是可以實(shí)時(shí)收集和處理傳入的一系列數(shù)據(jù)點(diǎn)（即數(shù)據(jù)流）的數(shù)據(jù)庫(kù)。傳統(tǒng)數(shù)據(jù)庫(kù)存儲(chǔ)數(shù)據(jù)并期望用戶執(zhí)行查詢以根據(jù)最新數(shù)據(jù)獲取結(jié)果。在實(shí)時(shí)處理是關(guān)鍵標(biāo)準(zhǔn)的現(xiàn)代世界中，等待查詢不是一種選擇。相反，查詢必須連續(xù)運(yùn)行并始終返回最新數(shù)據(jù)。流式數(shù)據(jù)庫(kù)促進(jìn)了這一點(diǎn)。

在流式數(shù)據(jù)庫(kù)的情況下，查詢不會(huì)被執(zhí)行而是被注冊(cè)，因?yàn)閳?zhí)行永遠(yuǎn)不會(huì)完成。它們運(yùn)行無(wú)限長(zhǎng)的時(shí)間，對(duì)傳入的更新數(shù)據(jù)做出反應(yīng)。應(yīng)用程序還可以及時(shí)查詢以了解數(shù)據(jù)如何隨時(shí)間變化。

與傳統(tǒng)數(shù)據(jù)庫(kù)相比，流式數(shù)據(jù)庫(kù)在撰寫本文時(shí)完成所有工作。實(shí)現(xiàn)這一目標(biāo)面臨著許多挑戰(zhàn)。其一，人們對(duì)傳統(tǒng)數(shù)據(jù)庫(kù)的期望最低限度的持久性和正確性。當(dāng)數(shù)據(jù)始終處于動(dòng)態(tài)狀態(tài)時(shí)，保持這種持久性和正確性需要復(fù)雜的設(shè)計(jì)。然后是使用戶能夠查詢動(dòng)態(tài)數(shù)據(jù)的挑戰(zhàn)。SQL 長(zhǎng)期以來(lái)一直是所有查詢要求的標(biāo)準(zhǔn)。流式數(shù)據(jù)庫(kù)自然也支持 SQL，但是當(dāng)數(shù)據(jù)總是在移動(dòng)時(shí)，實(shí)現(xiàn)窗口、聚合等結(jié)構(gòu)很復(fù)雜。

持久查詢是對(duì)移動(dòng)數(shù)據(jù)進(jìn)行操作的查詢。它們無(wú)限期地運(yùn)行并不斷產(chǎn)生輸出行。無(wú)休止的查詢對(duì)更新邏輯提出了獨(dú)特的挑戰(zhàn)。關(guān)鍵問(wèn)題是關(guān)于用改進(jìn)的查詢替換查詢時(shí)的行為——它是對(duì)到那時(shí)到達(dá)的所有數(shù)據(jù)進(jìn)行操作，還是只對(duì)下一組數(shù)據(jù)進(jìn)行操作？第一種操作模式的名稱是backfill，后者是exactly-once processing。要實(shí)現(xiàn) exactly-once 處理，執(zhí)行引擎必須有一個(gè)本地存儲(chǔ)。有時(shí)，查詢可以提供給其他數(shù)據(jù)流。這樣的操作稱為級(jí)聯(lián)模式。

現(xiàn)在概念已經(jīng)清楚了，讓我們花點(diǎn)時(shí)間了解流式數(shù)據(jù)庫(kù)的架構(gòu)細(xì)節(jié)。流式數(shù)據(jù)庫(kù)通常構(gòu)建在基于生產(chǎn)者-消費(fèi)者范式工作的流處理系統(tǒng)之上。生產(chǎn)者是創(chuàng)建事件的實(shí)體。消費(fèi)者消費(fèi)事件并處理它們。通常將事件分組為主題的邏輯分區(qū)，以方便業(yè)務(wù)邏輯的實(shí)現(xiàn)。

它們之間有一個(gè)經(jīng)紀(jì)人，負(fù)責(zé)確保生產(chǎn)者和消費(fèi)者所需的流和格式轉(zhuǎn)換的可靠性。Broker通常分布在一個(gè)分布式平臺(tái)上，以保證高可用性和健壯性。流查詢引擎駐留在處理平臺(tái)之上。還存在將 SQL 查詢轉(zhuǎn)換為流處理邏輯的 SQL 抽象層。將所有內(nèi)容拼接在一起，架構(gòu)如下所示。

現(xiàn)在我們了解了流式數(shù)據(jù)庫(kù)和持久查詢的概念，讓我們花一些時(shí)間了解它們的典型用例。

物聯(lián)網(wǎng)平臺(tái)

物聯(lián)網(wǎng)平臺(tái)處理從世界各地的設(shè)備推送的大量事件。他們需要根據(jù)實(shí)時(shí)處理生成警報(bào)，并在反應(yīng)時(shí)間方面有嚴(yán)格的 SLA。IoT 平臺(tái)還需要永久存儲(chǔ)所有接收到的事件，并需要基于窗口的流數(shù)據(jù)聚合以進(jìn)行分析。流式數(shù)據(jù)庫(kù)和持久查詢非常適合這里。

事件溯源

事件溯源是一種范例，其中根據(jù)隨時(shí)間發(fā)生的事件而不是實(shí)體的最終狀態(tài)來(lái)執(zhí)行應(yīng)用程序邏輯。這有助于提高應(yīng)用程序的持久性和可靠性，因?yàn)榭梢酝ㄟ^(guò)回復(fù)事件隨時(shí)重新創(chuàng)建應(yīng)用程序狀態(tài)。這在審計(jì)跟蹤是強(qiáng)制性要求的情況下很有用。

點(diǎn)擊流分析

點(diǎn)擊流分析平臺(tái)處理作為應(yīng)用程序使用的一部分生成的點(diǎn)擊事件。來(lái)自點(diǎn)擊事件的數(shù)據(jù)有時(shí)會(huì)直接輸入機(jī)器學(xué)習(xí)模型，為客戶提供推薦和建議。持續(xù)事件和點(diǎn)擊流的實(shí)時(shí)處理是運(yùn)行電子商務(wù)等業(yè)務(wù)的重要組成部分。

交易系統(tǒng)

交易系統(tǒng)每秒處理數(shù)百萬(wàn)個(gè)交易請(qǐng)求，并將它們與需求和供應(yīng)方程式進(jìn)行匹配以結(jié)算交易。在這種情況下，審計(jì)跟蹤是一項(xiàng)強(qiáng)制性要求，即使是最輕微的延誤也會(huì)給相關(guān)各方造成巨大的經(jīng)濟(jì)損失。

欺詐檢測(cè)系統(tǒng)

欺詐檢測(cè)系統(tǒng)一旦檢測(cè)到與典型的欺詐開(kāi)始非常匹配的場(chǎng)景，就需要立即采取行動(dòng)。他們還必須記錄觸發(fā)警報(bào)和事件發(fā)生后的后續(xù)事件。考慮一個(gè)金融系統(tǒng)欺詐檢測(cè)系統(tǒng)，它根據(jù)合法所有者的消費(fèi)模式檢測(cè)欺詐。它需要實(shí)時(shí)將事件的特征提供給欺詐檢測(cè)模型，并在標(biāo)記可能的違規(guī)行為時(shí)立即采取行動(dòng)。實(shí)時(shí)數(shù)據(jù)庫(kù)是實(shí)現(xiàn)此類用例的絕佳解決方案。

IT系統(tǒng)監(jiān)控

集中監(jiān)控幫助組織保持其 IT 系統(tǒng)始終運(yùn)行流式數(shù)據(jù)庫(kù)通常用于從系統(tǒng)收集日志并在滿足特定條件時(shí)生成警報(bào)。通過(guò)事件存儲(chǔ)生成的實(shí)時(shí)警報(bào)和審計(jì)跟蹤是可觀察系統(tǒng)實(shí)施的關(guān)鍵要素。

流式數(shù)據(jù)庫(kù)市場(chǎng)并不擁擠，只有少數(shù)數(shù)據(jù)庫(kù)經(jīng)得起考驗(yàn)來(lái)處理生產(chǎn)工作負(fù)載。Kafka、Materialise、Memgraph 等是一些穩(wěn)定的。選擇一個(gè)適合用例的工具需要仔細(xì)比較它們的特性和用例剖析。

現(xiàn)在讓我們將注意力轉(zhuǎn)移到學(xué)習(xí)流式數(shù)據(jù)庫(kù)背后的關(guān)鍵數(shù)據(jù)庫(kù)設(shè)計(jì)原則和保證上。

4個(gè)關(guān)鍵的流式數(shù)據(jù)庫(kù)設(shè)計(jì)原則和保證

數(shù)據(jù)庫(kù)系統(tǒng)的完整性通常用數(shù)據(jù)庫(kù)是否符合 ACID 標(biāo)準(zhǔn)來(lái)表示。ACID 投訴構(gòu)成了良好數(shù)據(jù)庫(kù)設(shè)計(jì)原則的基礎(chǔ)。ACID 合規(guī)性代表原子性、一致性、隔離性和持久性。原子性是指保證邏輯操作的一組語(yǔ)句部分在其中一條語(yǔ)句出錯(cuò)的情況下優(yōu)雅地失敗。這樣的一組語(yǔ)句稱為事務(wù)。在流式數(shù)據(jù)庫(kù)的早期，事務(wù)支持和原子性常常缺失。但是較新的版本確實(shí)支持事務(wù)。

一致性是指遵守?cái)?shù)據(jù)庫(kù)強(qiáng)制執(zhí)行的規(guī)則，如唯一鍵約束、外鍵約束等。如果結(jié)果狀態(tài)不遵守這些規(guī)則，一致的數(shù)據(jù)庫(kù)將恢復(fù)事務(wù)。隔離是單獨(dú)事務(wù)執(zhí)行的概念，這樣一個(gè)事務(wù)不會(huì)影響另一個(gè)事務(wù)。這使得事務(wù)的并行執(zhí)行成為可能。像 KSQLDB 這樣的數(shù)據(jù)庫(kù)支持查詢的強(qiáng)一致性和并行執(zhí)行。耐用性是指從故障點(diǎn)恢復(fù)。該架構(gòu)的分布式特性確保了現(xiàn)代流式數(shù)據(jù)庫(kù)的強(qiáng)大持久性。

在流式數(shù)據(jù)庫(kù)的情況下，保證是指處理事件的保證。由于數(shù)據(jù)是不斷移動(dòng)的，因此很難保證事件處理的順序或避免重復(fù)處理。確保所有數(shù)據(jù)只處理一次是一項(xiàng)昂貴的操作，并且需要狀態(tài)存儲(chǔ)和確認(rèn)。同樣，在分布式應(yīng)用程序的情況下，確保消息以與接收消息相同的順序進(jìn)行處理需要復(fù)雜的體系結(jié)構(gòu)。

現(xiàn)在讓我們看看核心設(shè)計(jì)原則以及它們是如何在流式數(shù)據(jù)庫(kù)中實(shí)現(xiàn)的。

1.自動(dòng)恢復(fù)

對(duì)于流式數(shù)據(jù)庫(kù)，自動(dòng)恢復(fù)是最關(guān)鍵的數(shù)據(jù)庫(kù)設(shè)計(jì)原則之一。流式數(shù)據(jù)庫(kù)用于高度監(jiān)管的領(lǐng)域，如醫(yī)療保健、金融系統(tǒng)等。在這些領(lǐng)域，沒(méi)有任何借口可以失敗，并且事故可能導(dǎo)致巨大的金錢損失甚至生命損失。想象一下作為醫(yī)療保健物聯(lián)網(wǎng)平臺(tái)的一部分集成的流式數(shù)據(jù)庫(kù)。傳感器監(jiān)測(cè)患者的重要參數(shù)并將它們發(fā)送到云端托管的流式數(shù)據(jù)庫(kù)。這樣的系統(tǒng)永遠(yuǎn)不會(huì)宕機(jī)，基于閾值生成警報(bào)的查詢應(yīng)該無(wú)限期地運(yùn)行。

由于流式數(shù)據(jù)庫(kù)不會(huì)出現(xiàn)故障，因此它們通?；诜植际郊軜?gòu)來(lái)實(shí)現(xiàn)?；诠?jié)點(diǎn)集群設(shè)計(jì)的流式數(shù)據(jù)庫(kù)提供了很好的容錯(cuò)能力，因?yàn)榧词股贁?shù)節(jié)點(diǎn)出現(xiàn)故障，系統(tǒng)的其余部分仍然可以接受查詢。這種容錯(cuò)必須在開(kāi)發(fā)周期的早期納入流式數(shù)據(jù)庫(kù)的設(shè)計(jì)中。現(xiàn)在讓我們看看流式數(shù)據(jù)庫(kù)自動(dòng)恢復(fù)中涉及的關(guān)鍵活動(dòng)。

分布式流式數(shù)據(jù)庫(kù)中的自動(dòng)恢復(fù)涉及以下活動(dòng)：

• 故障檢測(cè)
• 重新平衡和智能路由
• 最終恢復(fù)

故障檢測(cè)是自動(dòng)恢復(fù)的第一步。系統(tǒng)必須有足夠的自我意識(shí)來(lái)檢測(cè)故障情況，以便它可以采取必要的步驟進(jìn)行恢復(fù)。在分布式系統(tǒng)中，故障檢測(cè)通常是通過(guò)心跳機(jī)制來(lái)完成的。心跳是一個(gè)周期性的輕量級(jí)消息，節(jié)點(diǎn)發(fā)送給集群的每個(gè)節(jié)點(diǎn)或集群的主節(jié)點(diǎn)。這讓其他人知道它還活著。如果沒(méi)有收到來(lái)自節(jié)點(diǎn)的心跳消息，系統(tǒng)會(huì)認(rèn)為它已經(jīng)死亡并啟動(dòng)恢復(fù)程序。心跳消息的大小、其中捆綁的信息以及心跳消息的頻率對(duì)于優(yōu)化資源很重要。非常頻繁的心跳有助于更早地檢測(cè)到故障，但它也會(huì)耗費(fèi)處理時(shí)間并產(chǎn)生開(kāi)銷。

當(dāng)分布式系統(tǒng)中發(fā)生節(jié)點(diǎn)故障時(shí)，該節(jié)點(diǎn)擁有的資源必須重新平衡到其他節(jié)點(diǎn)。分布式系統(tǒng)使用受控復(fù)制來(lái)確保即使在一些節(jié)點(diǎn)出現(xiàn)故障時(shí)數(shù)據(jù)也不會(huì)丟失。一旦一個(gè)節(jié)點(diǎn)出現(xiàn)故障，系統(tǒng)會(huì)確保數(shù)據(jù)在其他節(jié)點(diǎn)之間重新平衡，并盡可能保持復(fù)制策略以降低數(shù)據(jù)丟失的風(fēng)險(xiǎn)。

要維護(hù)高可用性流式數(shù)據(jù)庫(kù)，僅在部分故障期間進(jìn)行重新平衡是不夠的。由于在流式數(shù)據(jù)庫(kù)的情況下查詢始終在運(yùn)行，因此系統(tǒng)需要確保它們保持運(yùn)行。這就是智能路由的用武之地。智能路由有助于確保查詢保持運(yùn)行并返回結(jié)果。使用故障節(jié)點(diǎn)上的資源的查詢被無(wú)縫地路由到其他節(jié)點(diǎn)。這需要仔細(xì)設(shè)計(jì)，并且是流式數(shù)據(jù)庫(kù)基本要求的一部分。

最終恢復(fù)涉及恢復(fù)在事件中丟失的狀態(tài)存儲(chǔ)。狀態(tài)存儲(chǔ)需要確保系統(tǒng)滿足用戶配置的約束恰好一次、至多一次或至少處理保證。分布式數(shù)據(jù)庫(kù)通常使用無(wú)限日志作為事實(shí)來(lái)源。他們還使用單獨(dú)的主題，將時(shí)間偏移量作為恢復(fù)機(jī)制。如果發(fā)生故障，此時(shí)間偏移主題可用于重新創(chuàng)建事件的時(shí)間線。

2.恰好一次語(yǔ)義

對(duì)于流式數(shù)據(jù)庫(kù)，故障情況下的自動(dòng)恢復(fù)是不夠的。與傳統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì)不同，流式數(shù)據(jù)庫(kù)設(shè)計(jì)應(yīng)確保在故障期間丟失的結(jié)果不影響下游消費(fèi)者。實(shí)現(xiàn)這一點(diǎn)有幾個(gè)方面。首先，系統(tǒng)需要保證沒(méi)有記錄漏處理。這可以通過(guò)重新處理所有記錄來(lái)完成，但存在風(fēng)險(xiǎn)。其一，沒(méi)有充分考慮的重新處理可能導(dǎo)致記錄被處理不止一次。這會(huì)導(dǎo)致不準(zhǔn)確的結(jié)果。例如，考慮相同的醫(yī)療保健 IOT 平臺(tái)，其中警報(bào)是決定生命的警報(bào)。重復(fù)處理會(huì)導(dǎo)致重復(fù)警報(bào)，從而造成資源浪費(fèi)。重復(fù)處理也會(huì)導(dǎo)致聚合結(jié)果，如平均值、百分位計(jì)算等。

根據(jù)要求，有時(shí)，事件處理中的一些錯(cuò)誤可能是可以接受的。流式數(shù)據(jù)庫(kù)定義了不同的消息處理保證以支持具有不同需求的用例?？梢允褂萌N類型的消息保證——至多一次、至少一次和恰好一次。Utmost once 保證定義了消息永遠(yuǎn)不會(huì)被處理超過(guò)一次的情況，但有時(shí)可能會(huì)錯(cuò)過(guò)處理。至少一次保證定義了允許重復(fù)處理但不接受丟失記錄的情況。

Exactly once 語(yǔ)義保證一條消息只被處理一次，并且結(jié)果足夠準(zhǔn)確，以至于消費(fèi)者不會(huì)注意到失敗事件。讓我們借助圖表來(lái)探討這個(gè)概念。

假設(shè)系統(tǒng)正在處理按順序發(fā)送的消息。為了表示，消息在此處從 1 開(kāi)始排序。處理器接收消息，根據(jù)邏輯進(jìn)行轉(zhuǎn)換或聚合，傳遞給消費(fèi)者。在上圖中，綠色表示尚未處理的消息，紅色表示已處理的消息。每次處理消息時(shí)，處理器都會(huì)使用偏移量更新?tīng)顟B(tài)存儲(chǔ)。這是為了在發(fā)生故障時(shí)啟用恢復(fù)。現(xiàn)在假設(shè)處理器在處理第二條消息后發(fā)生錯(cuò)誤并崩潰。當(dāng)處理器恢復(fù)時(shí)，它必須從 3 而不是從消息 2 重新開(kāi)始處理。它應(yīng)該避免對(duì)狀態(tài)存儲(chǔ)進(jìn)行重復(fù)更新或?qū)⑾?2 的結(jié)果再次提供給消費(fèi)者。

換句話說(shuō)，系統(tǒng)從結(jié)果的角度和系統(tǒng)間通信的角度都掩蓋了故障。這需要生產(chǎn)者、消息系統(tǒng)和消費(fèi)者根據(jù)約定的合同進(jìn)行合作。消息傳遞確認(rèn)是可以幫助流式數(shù)據(jù)庫(kù)完成此操作的最簡(jiǎn)單的保證。合約應(yīng)該能夠承受代理故障、生產(chǎn)者與代理之間的通信故障，甚至是消費(fèi)者故障。

3.處理故障記錄

良好的數(shù)據(jù)庫(kù)設(shè)計(jì)將處理無(wú)序記錄視為一個(gè)關(guān)鍵方面。由于多種原因，流式數(shù)據(jù)庫(kù)會(huì)遇到亂序記錄。原因包括網(wǎng)絡(luò)延遲、生產(chǎn)者不可靠、時(shí)鐘不同步等。由于它們用于高度敏感的應(yīng)用程序，如金融和醫(yī)療保健，處理順序非常重要，流式數(shù)據(jù)庫(kù)必須優(yōu)雅地處理它們。為了更好地理解這個(gè)問(wèn)題，讓我們考慮同一個(gè)物聯(lián)網(wǎng)醫(yī)療保健平臺(tái)的例子。假設(shè)由于短暫的互聯(lián)網(wǎng)連接失敗，其中一臺(tái)設(shè)備在短時(shí)間內(nèi)無(wú)法發(fā)送數(shù)據(jù)。當(dāng)它恢復(fù)時(shí)，它從恢復(fù)時(shí)間開(kāi)始發(fā)送數(shù)據(jù)。一段時(shí)間后，設(shè)備中的固件發(fā)送了之前未能發(fā)送的其余數(shù)據(jù)。

為了更好地了解上下文，讓我們現(xiàn)在使用圖表來(lái)解釋這個(gè)問(wèn)題。下圖有一個(gè)生產(chǎn)者，它發(fā)送的消息的編號(hào)從 1 開(kāi)始。綠色塊代表尚未發(fā)送的事件，紅色塊代表此處已發(fā)送的事件。當(dāng)消息。1,2, 3 按時(shí)間戳順序到達(dá)；一切安好。但是，如果其中一條消息在途中或從源本身延遲，則會(huì)導(dǎo)致流媒體平臺(tái)的結(jié)果損壞。在這種情況下，消息1和3早于2到達(dá)。流媒體平臺(tái)在1和3之后收到2，但必須保證下游消費(fèi)者按實(shí)際順序收到消息。

如果亂序記錄沒(méi)有得到妥善處理，處理記錄的流式數(shù)據(jù)庫(kù)將向下游系統(tǒng)提供不準(zhǔn)確的結(jié)果。例如，假設(shè)消息表示一個(gè)溫度值，并且有一個(gè)持久查詢可以找到最后一分鐘的平均溫度。延遲的溫度值會(huì)導(dǎo)致錯(cuò)誤的平均值。流式數(shù)據(jù)庫(kù)以兩種方法處理這些情況。第一種方法涉及一個(gè)配置參數(shù)，該參數(shù)定義處理器在每個(gè)微批處理開(kāi)始之前等待無(wú)序記錄到達(dá)的時(shí)間量。微批次是一組記錄，它們是實(shí)時(shí)查詢的一部分。微批處理的概念是持久查詢的基礎(chǔ)。

解決亂序記錄的第二種方法是允許處理器更新已經(jīng)計(jì)算的結(jié)果。這需要與消費(fèi)者達(dá)成協(xié)議。這個(gè)概念與事務(wù)的概念直接沖突，因此在實(shí)現(xiàn)時(shí)需要仔細(xì)設(shè)計(jì)。這僅適用于下游消費(fèi)者即使以不同順序接收輸入也能夠產(chǎn)生相同輸出的情況。例如，如果下游消費(fèi)者的輸出是一個(gè)允許修改的表，那么流式數(shù)據(jù)庫(kù)就可以使用這種策略。

4. 一致的查詢結(jié)果

實(shí)現(xiàn)流式數(shù)據(jù)庫(kù)通?；诜植际郊軜?gòu)。傳統(tǒng)的數(shù)據(jù)庫(kù)設(shè)計(jì)原則將原子性和一致性視為良好數(shù)據(jù)庫(kù)設(shè)計(jì)的關(guān)鍵支柱。但是在流式數(shù)據(jù)庫(kù)的情況下，由于分布式的特性，很難實(shí)現(xiàn)寫入的一致性?？紤]一個(gè)使用復(fù)制分區(qū)概念并部署在節(jié)點(diǎn)集群上的流式數(shù)據(jù)庫(kù)。收入流將根據(jù)存儲(chǔ)模式進(jìn)入不同的分區(qū)或節(jié)點(diǎn)。為確保真正的寫入一致性，需要確保只有在所有分區(qū)都反映成功時(shí)才確認(rèn)流。當(dāng)有多個(gè)消息作為邏輯事務(wù)的一部分時(shí)，這很困難。

確保寫入一致性的困難也會(huì)影響到讀取一致性。只有讀取一致，才有可能返回一致的查詢結(jié)果?？紤]充當(dāng)多個(gè)持久查詢的數(shù)據(jù)源的流，該查詢根據(jù)不同的業(yè)務(wù)邏輯聚合流。流式數(shù)據(jù)庫(kù)必須確保兩個(gè)查詢都作用于單一的真實(shí)來(lái)源，并且查詢的結(jié)果反映不沖突的值。這是一個(gè)極其困難的命題，因?yàn)闉榱颂幚韥y序的記錄，大多數(shù)數(shù)據(jù)庫(kù)都以持續(xù)更新的模式運(yùn)行，經(jīng)常會(huì)改變它們之前計(jì)算的結(jié)果。在串聯(lián)查詢的情況下，此類更新會(huì)在不同時(shí)間滴入下游流，并且一些派生查詢狀態(tài)可能反映不同的源數(shù)據(jù)狀態(tài)。

有兩種方法可以解決查詢結(jié)果的一致性問(wèn)題。第一種方法通過(guò)確保在來(lái)自該流的所有查詢完成之前不確認(rèn)寫入來(lái)解決這個(gè)問(wèn)題。這對(duì)生產(chǎn)者而言是昂貴的。因?yàn)闉榱藵M足 exact once 處理要求，大多數(shù)流式數(shù)據(jù)庫(kù)依賴于代理和生產(chǎn)者之間的確認(rèn)。如果僅在查詢完成后才確認(rèn)所有寫入，那么生產(chǎn)者將被蒙在鼓里的時(shí)間更長(zhǎng)。這種方法是 block-on-write 方法。

解決一致性的第二種方法是在查詢引擎級(jí)別進(jìn)行。在這里，查詢引擎延遲需要強(qiáng)一致性保證的特定查詢的結(jié)果，直到所有寫入都得到確認(rèn)。這比第一種方法更便宜，因?yàn)檩斎肓鞯膶懭胄阅懿皇苡绊?。這種方法不是延遲確認(rèn)作為查詢基礎(chǔ)的輸入流，而是在查詢級(jí)別運(yùn)行。因此，如果查詢不需要強(qiáng)一致性保證，則該查詢的結(jié)果將比依賴于相同輸入流的其他查詢更早發(fā)出。因此，不同的查詢根據(jù)其一致性配置對(duì)同一輸入流的不同版本進(jìn)行操作。

流式數(shù)據(jù)庫(kù)必須在數(shù)據(jù)的陳舊性和一致性級(jí)別之間取得平衡，以優(yōu)化性能。提高一致性級(jí)別可能會(huì)導(dǎo)致處理速度降低，反之亦然。

結(jié)論

流式數(shù)據(jù)庫(kù)是實(shí)時(shí)處理應(yīng)用程序的基礎(chǔ)。它們不是傳統(tǒng)數(shù)據(jù)庫(kù)的替代品，而是有助于滿足需要對(duì)永無(wú)止境的數(shù)據(jù)流進(jìn)行始終在線處理的獨(dú)特需求。設(shè)計(jì)流式數(shù)據(jù)庫(kù)是一項(xiàng)復(fù)雜的任務(wù)，因?yàn)樵谔幚砹魇綌?shù)據(jù)時(shí)存在一些限制。實(shí)現(xiàn)讀取一致性、處理亂序數(shù)據(jù)、確保恰好一次處理和自動(dòng)恢復(fù)是設(shè)計(jì)流式數(shù)據(jù)庫(kù)時(shí)考慮的典型設(shè)計(jì)原則。