資料庫會演變成分散式計算平臺嗎? - Nikita
“資料庫”一詞是否會在 5 到 10 年內慢慢演變成“分散式計算平臺”?
隨著無伺服器市場的擴大,更多的資料庫解決方案開始考慮模組化架構,其中系統的各個元件都是分開的。這允許為每個無伺服器租戶分配此類元件的一個例項,從而在使用者之間提供清晰的分離。這種分解資料庫並模組化的解決方案也是使其各個部分可被非資料庫應用程式重用。
資料庫 = 分散式系統的框架?
分散式資料庫具有以下元件是很常見的:
- 分散式儲存:該元件有一個鍵值儲存介面:Get(key)和Set(key, value),其中key和value是一些二進位制字串。這個元件對資料一無所知——它可以是表中的行、JSON 文件或其他東西。通常,該元件提供“耐用性”保證,這意味著在某些故障情況下資料不會丟失。這種情況的一個常見示例是“不到一半的伺服器停機”。
- 叢集節點之間的通訊: 該元件實現了某種通訊協議,以便從一個節點向另一個節點傳送和接收訊息。
- 計算模型該元件對使用者的查詢執行結果:例如,使用 SQL 請求的一組行。
在經典資料庫(例如 PostreSQL)中,所有這些元件都在一個應用程式中實現。此類應用程式自行管理所有內容:控制儲存、與叢集中的其他節點通訊以及計算 SQL 查詢的結果。
在 MapReduce 系統(如 Hadoop)和其他一些資料庫(如 Google BigQuery)中,各種資料庫元件在物理上是分開的。一些叢集節點專門用於儲存。其他節點僅用於計算 SQL 查詢的結果。如果 SQL 查詢需要一些資料,它會通過網路從儲存節點傳輸到計算節點。
分散式系統的特點
現在讓我們想象我們想要建立一個新的分散式系統 - 一個監控各種指標的服務(如Prometheus)。根據對該系統的具體要求,我們可能需要以下內容:
- 具有“永續性”保證的分散式儲存我們需要將使用者的指標儲存在某個地方,並且我們不想因為資料中心停機而丟失有價值的資料。
- 叢集節點之間的通訊監控系統可以部署在多個資料中心,以減少延遲並提高容錯能力。我們系統的各種例項需要相互協調。
- 計算模型首先,我們的系統必須接受儲存新指標的請求。其次,它應該響應讀取時間序列資料並生成監控圖報告的請求。
編寫這些元件中的每一個都是一項艱鉅的任務。我們不僅需要編寫程式碼和測試,還需要在生產中強化系統。後者通常會導致發現意外錯誤和設計效率低下。
現在讓我們回到資料庫。它們擁有我們構建分散式系統所需的所有元件。這些元件已經被數千種不同的工作負載實施、測試和強化。更重要的是,這些元件中的每一個都可以與資料庫本身分離並單獨使用。
這基本上意味著資料庫可以用作構建新分散式系統的框架。
案例1:YDB
YDB是一個在Yandex開發的分散式資料庫。它提供了橫向可擴充套件性和強大的一致性保證。
在引擎蓋下,YDB使用actor模型,Actor是一個併發的單位,它能夠:
- 接收來自其他Actor的訊息
- 向其他Actor傳送訊息
- 啟動新的Actor
Actor始終是單執行緒的,只能改變其內部狀態。Actor沒有共享狀態的概念,這意味著所有的同步都是通過訊息傳遞完成的。一方面,程式碼中不再有mutexes。另一方面,你不能再只是寫到記憶體中讓其他Actor看到它。
YDB對actor有一個特殊的名字--tablet。它是YDB的構建模組。SQL查詢的執行,事務的協調,tablet的建立--這些任務都是由一個或多個tablet執行的。用這個帖子的術語來說,tablet是計算模型。
作為Actor,tablet需要傳送和接收資訊。在YDB中,有一個特殊的系統就是為此而建立的--它被稱為互連。每個tablet都有一個ID,tablet可以用這個ID作為他們的地址互相傳送訊息。互聯是一個用於叢集節點之間通訊的系統。
最後,tablet需要在某個地方儲存它們的狀態。例如,代表SQL表分片的tablet需要儲存分配給它們的錶行的範圍。YDB有一個分散式儲存,它可以儲存任意的二進位制blob,並有 "永續性 "保證。
擁有所有這些元件使得YDB不僅是一個資料庫,也是一個通用的分散式計算平臺。分散式系統的開發者可以通過建立一種新的平板電腦來編寫自己的應用邏輯,併為自己的目的重用系統的其他部分。
免責宣告:YDB被宣傳為一個資料庫解決方案。沒有公佈關於使用它作為分散式系統平臺的公開檔案。
案例2:Tarantool
Tarantool是一個用 Lua 編寫的分散式系統應用伺服器。在 Tarantool 中啟動的 Lua 應用程式可以通過 API 訪問以下元件:
- 分散式事務資料庫。該資料庫支援 2 種操作模式 - 記憶體中和提交到磁碟。第二種模式使這個元件在本文中被稱為分散式儲存。
- 通訊協議稱為 SWIM。它允許在叢集節點之間傳送和接收訊息。
由於應用伺服器本身製作了計算模型,因此我們擁有將 Tarantool 稱為通用分散式計算平臺所需的所有元件。
這聽起來並不令人印象深刻。看起來 Tarantool 最初是為了成為這樣一個平臺而建立的,所以它符合所有標準也就不足為奇了。問題是,Tarantool 最初是作為一個資料庫建立的,然後迅速發展成為一個成熟的計算平臺。僅用了 2-3 年的時間這一事實非常出色,但它也顯示了資料庫解決方案如何演變為構建分散式系統的“框架”。
相關文章
- 分散式資料庫的架構演變之路分散式資料庫架構
- 專訪 | 分散式HTAP資料庫會成為未來主流據庫嗎?分散式資料庫
- MyCat 啟蒙:分散式系統的資料庫架構演變分散式資料庫架構
- OPPO大資料離線計算平臺架構演進大資料架構
- 分散式資料庫 ZNBase 的分散式計劃生成分散式資料庫
- SequoiaDB巨杉資料庫攜手民生銀行分散式資料管理平臺資料庫分散式
- 分享 | 滴滴分散式NoSQL資料庫Fusion的演進之路分散式SQL資料庫
- 存算分離是否成為開源分散式資料庫主流架構?分散式資料庫架構
- 分散式資料庫分散式資料庫
- 分散式資料庫技術的演進和發展方向分散式資料庫
- 明解資料庫------資料庫儲存演變史資料庫
- RestCloud ETL資料交換平臺,支援分散式部署RESTCloud分散式
- 銀聯分散式資料庫安全設計分散式資料庫
- 資料庫平臺資料庫
- Elixir 分散式平臺分散式
- OceanBase 首席架構師:關聯式資料庫到三代分散式資料庫,我親歷的資料庫演進史架構資料庫分散式
- 分散式ID系列(3)——資料庫自增ID機制適合做分散式ID嗎分散式資料庫
- 【系統設計】分散式鍵值資料庫分散式資料庫
- 得物資料庫中介軟體平臺“彩虹橋”演進之路資料庫
- openGauss 分散式資料庫能力分散式資料庫
- 聯通實時計算平臺演進與實踐
- 16 臺伺服器達成 1000 萬 tpmC!挑戰分散式資料庫效能極限伺服器分散式資料庫
- 故事篇:資料庫架構演變之路資料庫架構
- 分散式流平臺Kafka分散式Kafka
- 分析型資料庫:分散式分析型資料庫資料庫分散式
- 資料庫市場格局已變,統一的管理平臺將成為資料庫生態體系的主要入口資料庫
- 從GrowingIO產品到平臺的進化看資料分析的演變
- 平臺結算費用資料庫表的正負號設計,三方平賬設計資料庫
- 漸成主流,分散式圖資料庫迎來“最好的時機”分散式資料庫
- [分散式]分散式計算系統淺析分散式
- 《分散式資料庫HBase案例教程》分散式資料庫
- DTCC演講 | PolarDB-X技術架構:雲原生分散式資料庫架構分散式資料庫
- BI 資料視覺化平臺建設(1)—交叉表元件演變實戰視覺化元件
- AIGC時代的算力基石,未來的資料平臺將如何演進?AIGC
- 基於 ShardingSphere 的得物資料庫中介軟體平臺演進之路資料庫
- 騰訊音樂內容庫資料平臺架構演進實踐架構
- 金融級分散式資料庫架構設計要點分散式資料庫架構
- AR新計算平臺要來了,蘋果會帶火AR遊戲嗎?蘋果遊戲