Mpp 架構(gòu)（大規(guī)模并行處理）：核心思想是"分而治之"，它將龐大的計(jì)算任務(wù)拆分成許多小任務(wù)，分發(fā)到多臺(tái)服務(wù)器節(jié)點(diǎn)上并行處理，最后合并結(jié)果，以此顯著提升數(shù)據(jù)處理效率。

其核心每個(gè)節(jié)點(diǎn)都擁有獨(dú)立的計(jì)算、內(nèi)存和存儲(chǔ)資源，通過節(jié)點(diǎn)互聯(lián)網(wǎng)絡(luò)進(jìn)行協(xié)作；這種架構(gòu)具備優(yōu)異的水平擴(kuò)展性，可通過增加節(jié)點(diǎn)來線性提升系統(tǒng)處理能力，非常適合進(jìn)行低延遲的復(fù)雜分析查詢；

MPP架構(gòu)尤其適用于數(shù)據(jù)倉(cāng)庫(kù)、商業(yè)智能（BI）和交互式分析等需要快速響應(yīng)和處理海量結(jié)構(gòu)化數(shù)據(jù)的場(chǎng)景。

Lambda 架構(gòu)（批流分離） ：這是早期的經(jīng)典模式，旨在同時(shí)滿足 大數(shù)據(jù)量的批處理準(zhǔn)確性 和 流數(shù)據(jù)的低延遲性

它包含批處理層（Batch Layer，如 Spark）、速度層（Speed Layer，如 Flink/Kafka Streams）和服務(wù)層（Serving Layer，如 HBase/Druid）。其最大優(yōu)點(diǎn)是架構(gòu)成熟，有大量實(shí)踐案例。但缺點(diǎn)也顯而易見： 復(fù)雜性高 （需維護(hù)兩套邏輯一致的代碼）、 資源消耗大 （兩套系統(tǒng)）且存在 數(shù)據(jù)一致性挑戰(zhàn) 。

Kappa 架構(gòu)（流批一體） ：為解決 Lambda 的復(fù)雜性，Kappa 架構(gòu)提出 一切皆流 的理念

批處理被視作流處理的一個(gè)特例（處理有界的歷史數(shù)據(jù)流）。所有數(shù)據(jù)通過如 Apache Kafka 這樣的 中心化日志 接入，由統(tǒng)一的流處理引擎（如 Apache Flink）進(jìn)行處理。它的優(yōu)勢(shì)是 架構(gòu)簡(jiǎn)化 、 邏輯統(tǒng)一 （只需維護(hù)一套代碼）。挑戰(zhàn)則在于：對(duì)消息隊(duì)列的 長(zhǎng)期存儲(chǔ)能力 和 流處理引擎的重處理（Reprocessing）能力 要求極高。

Lakehouse 架構(gòu)（湖倉(cāng)一體） ：這是當(dāng)前的重要演進(jìn)方向，旨在融合 數(shù)據(jù)湖的靈活性 與 數(shù)據(jù)倉(cāng)庫(kù)的性能與管理性

其核心是通過 Apache Iceberg、Delta Lake、Apache Hudi 等開放表格式，在低成本的對(duì)象存儲(chǔ)（如 S3）上實(shí)現(xiàn) ACID 事務(wù)、數(shù)據(jù)版本（Time Travel）、 schema 演化等數(shù)倉(cāng)能力。它試圖解決數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)割裂帶來的數(shù)據(jù)冗余、遷移成本和治理困難問題。這三種架構(gòu)沒有絕對(duì)優(yōu)劣，只有是否適合。選擇取決于你的業(yè)務(wù)對(duì) 數(shù)據(jù)一致性、處理延遲、開發(fā)運(yùn)維成本和歷史數(shù)據(jù)規(guī)模 的要求。

=============================
NoSQL并非否定SQL，而是“Not Only SQL”。它根據(jù)不同的數(shù)據(jù)模型和訪問模式，提供了多樣化的選擇，其設(shè)計(jì)核心是 CAP理論 的權(quán)衡。
CAP 理論 是分布式系統(tǒng)設(shè)計(jì)中的一個(gè)核心理論，由計(jì)算機(jī)科學(xué)家 Eric Brewer 在 2000 年提出。它指出，在分布式系統(tǒng)中，一致性（Consistency）、可用性（Availability） 和 分區(qū)容錯(cuò)性（Partition Tolerance） 這三個(gè)特性無法同時(shí)滿足，最多只能同時(shí)滿足其中的兩個(gè)。這一理論為分布式系統(tǒng)的設(shè)計(jì)和優(yōu)化提供了重要的指導(dǎo)原則。
CAP 理論的三個(gè)核心特性
一致性（Consistency）：
在分布式系統(tǒng)中，所有節(jié)點(diǎn)在同一時(shí)間看到的數(shù)據(jù)是一致的。
例如，當(dāng)用戶向系統(tǒng)寫入數(shù)據(jù)后，所有后續(xù)的讀取操作都會(huì)返回最新的數(shù)據(jù)。
可用性（Availability）：
系統(tǒng)在任何時(shí)候都能正常響應(yīng)請(qǐng)求，不會(huì)出現(xiàn)超時(shí)或錯(cuò)誤。
例如，用戶發(fā)起的請(qǐng)求總能得到響應(yīng)，即使某些節(jié)點(diǎn)出現(xiàn)故障。
分區(qū)容錯(cuò)性（Partition Tolerance）：
系統(tǒng)在網(wǎng)絡(luò)分區(qū)（即節(jié)點(diǎn)之間無法通信）的情況下，仍然能夠繼續(xù)運(yùn)行。通常是必須滿足的。
例如，即使某些節(jié)點(diǎn)之間的網(wǎng)絡(luò)中斷，系統(tǒng)仍然能夠提供服務(wù)。

CA（一致性 + 可用性）：
放棄分區(qū)容錯(cuò)性，適用于單機(jī)系統(tǒng)或網(wǎng)絡(luò)絕對(duì)可靠的場(chǎng)景。
CP（一致性 + 分區(qū)容錯(cuò)性）：
放棄可用性，在網(wǎng)絡(luò)分區(qū)時(shí)，系統(tǒng)可能會(huì)拒絕請(qǐng)求，直到數(shù)據(jù)一致。
AP（可用性 + 分區(qū)容錯(cuò)性）：
放棄一致性，在網(wǎng)絡(luò)分區(qū)時(shí)，系統(tǒng)可能會(huì)返回舊數(shù)據(jù)或不一致的數(shù)據(jù)。

鍵值存儲(chǔ)（Key-Value）: 模型最簡(jiǎn)單，性能極高。代表： Redis （內(nèi)存型，豐富數(shù)據(jù)結(jié)構(gòu)）、 DynamoDB （云原生，自動(dòng)擴(kuò)縮容）。適用于會(huì)話緩存、購(gòu)物車、計(jì)數(shù)器等場(chǎng)景。

文檔存儲(chǔ)（Document）: 以JSON/BSON格式存儲(chǔ)半結(jié)構(gòu)化數(shù)據(jù)，模式靈活。代表： MongoDB （最流行的文檔數(shù)據(jù)庫(kù)）、 Couchbase 。適用于內(nèi)容管理系統(tǒng)、用戶配置文件等。

寬列存儲(chǔ)（Wide-Column）: 概念源于Google的BigTable。數(shù)據(jù)按列族存儲(chǔ)，擅長(zhǎng)海量數(shù)據(jù)的隨機(jī)讀寫和范圍查詢。代表： Apache HBase （Hadoop生態(tài)）、 Cassandra(無中心化架構(gòu)，高可用性極強(qiáng))、 ScyllaDB(C++重寫，性能怪獸)。適用于物聯(lián)網(wǎng)、消息日志、用戶行為數(shù)據(jù)存儲(chǔ)。

圖存儲(chǔ)（Graph）: 專門為存儲(chǔ)實(shí)體（節(jié)點(diǎn)）和關(guān)系（邊）而設(shè)計(jì)，支持高效的圖遍歷和關(guān)系查詢。代表： Neo4j （原生圖存儲(chǔ)）、 Nebula Graph(分布式開源方案)。適用于社交網(wǎng)絡(luò)、欺詐檢測(cè)、知識(shí)圖譜、推薦系統(tǒng)。

==================================
存儲(chǔ)引擎：LSM-Tree vs. B-Tree
存儲(chǔ)引擎是數(shù)據(jù)庫(kù)的“心臟”，決定了數(shù)據(jù)的組織和存取方式。

B-Tree（及其變種B+Tree）
○ 工作原理： 一種保持排序的平衡樹，所有數(shù)據(jù)都存儲(chǔ)在葉子節(jié)點(diǎn)。讀寫操作都是 原地更新（Update-in-place） 。
○ 優(yōu)點(diǎn)： 優(yōu)秀的讀性能（尤其是范圍查詢），事務(wù)支持成熟。
○ 缺點(diǎn)： 隨機(jī)寫可能導(dǎo)致頁(yè)分裂，產(chǎn)生碎片；寫放大（Write Amplification）問題較嚴(yán)重。代表：MySQL InnoDB, PostgreSQL。

LSM-Tree（Log-Structured Merge-Tree）
○ 工作原理 ： 首先將寫入操作追加到內(nèi)存中的 MemTable （常跳表實(shí)現(xiàn)），寫滿后凍結(jié)并刷到磁盤形成不可變的 SSTable（Sorted String Table） 。后臺(tái)通過 Compaction 過程將多個(gè)SSTable合并排序?yàn)楦蟮男挛募?br> ○ 優(yōu)點(diǎn) ： 極高的寫吞吐量 （順序?qū)懘骐S機(jī)寫）， 更好的壓縮率 （有序的SSTable）。
○ 缺點(diǎn) ： 讀放大（Read Amplification） （可能需要查找多個(gè)SSTable）， 寫放大 （Compaction帶來額外IO）。Compaction策略（Leveled vs. Size-Tiered）是調(diào)優(yōu)核心。
○ 代表 ： Google LevelDB 、 RocksDB （Facebook基于LevelDB開發(fā)，事實(shí)上的標(biāo)準(zhǔn)嵌入式引擎），幾乎所有現(xiàn)代NoSQL系統(tǒng)如Cassandra、ScyllaDB、HBase都基于RocksDB或類似LSM引擎構(gòu)建。

=================================
分布式一致性協(xié)議
構(gòu)建分布式存儲(chǔ)系統(tǒng)必須解決數(shù)據(jù)一致性問題。

主從復(fù)制中的一致性 ：

○ 異步復(fù)制 ： 性能最好，但存在數(shù)據(jù)丟失風(fēng)險(xiǎn)（主宕機(jī)）。

○ 半同步復(fù)制 ： 至少一個(gè)從庫(kù)確認(rèn)后才向客戶端返回成功，在性能和數(shù)據(jù)一致性間折衷。

○ 全同步復(fù)制 ： 所有從庫(kù)確認(rèn)，一致性最強(qiáng)，但延遲高。

分布式共識(shí)算法 ：

○ Paxos ： 理論上最優(yōu)但極其復(fù)雜，難以工程實(shí)現(xiàn)。

○ Raft ： 為易于理解而設(shè)計(jì)，通過領(lǐng)導(dǎo)者選舉、日志復(fù)制和安全性保證來維持一致性，已成為 事實(shí)標(biāo)準(zhǔn) （Etcd, Consul, TiKV等均采用）。

○ ZAB ： Zookeeper原子廣播協(xié)議，為ZooKeeper設(shè)計(jì)，與Rast思想類似。

=======================================