Mpp 架构（大规模并行处理）：核心思想是"分而治之"，它将庞大的计算任务拆分成许多小任务，分发到多台服务器节点上并行处理，最后合并结果，以此显著提升数据处理效率。
其核心每个节点都拥有独立的计算、内存和存储资源，通过节点互联网络进行协作；这种架构具备优异的水平扩展性，可通过增加节点来线性提升系统处理能力，非常适合进行低延迟的复杂分析查询；
MPP架构尤其适用于数据仓库、商业智能（BI）和交互式分析等需要快速响应和处理海量结构化数据的场景。
Lambda 架构（批流分离） ：这是早期的经典模式，旨在同时满足 大数据量的批处理准确性 和 流数据的低延迟性
它包含批处理层（Batch Layer，如 Spark）、速度层（Speed Layer，如 Flink/Kafka Streams）和服务层（Serving Layer，如 HBase/Druid）。其最大优点是架构成熟，有大量实践案例。但缺点也显而易见： 复杂性高 （需维护两套逻辑一致的代码）、 资源消耗大 （两套系统）且存在 数据一致性挑战 。
Kappa 架构（流批一体） ：为解决 Lambda 的复杂性，Kappa 架构提出 一切皆流 的理念
批处理被视作流处理的一个特例（处理有界的历史数据流）。所有数据通过如 Apache Kafka 这样的 中心化日志 接入，由统一的流处理引擎（如 Apache Flink）进行处理。它的优势是 架构简化 、 逻辑统一 （只需维护一套代码）。挑战则在于：对消息队列的 长期存储能力 和 流处理引擎的重处理（Reprocessing）能力 要求极高。
Lakehouse 架构（湖仓一体） ：这是当前的重要演进方向，旨在融合 数据湖的灵活性 与 数据仓库的性能与管理性
其核心是通过 Apache Iceberg、Delta Lake、Apache Hudi 等开放表格式，在低成本的对象存储（如 S3）上实现 ACID 事务、数据版本（Time Travel）、 schema 演化等数仓能力。它试图解决数据湖和数据仓库割裂带来的数据冗余、迁移成本和治理困难问题。这三种架构没有绝对优劣，只有是否适合。选择取决于你的业务对 数据一致性、处理延迟、开发运维成本和历史数据规模 的要求。
=============================
NoSQL并非否定SQL，而是“Not Only SQL”。它根据不同的数据模型和访问模式，提供了多样化的选择，其设计核心是 CAP理论 的权衡。
CAP 理论 是分布式系统设计中的一个核心理论，由计算机科学家 Eric Brewer 在 2000 年提出。它指出，在分布式系统中，一致性（Consistency）、可用性（Availability） 和 分区容错性（Partition Tolerance） 这三个特性无法同时满足，最多只能同时满足其中的两个。这一理论为分布式系统的设计和优化提供了重要的指导原则。
CAP 理论的三个核心特性
一致性（Consistency）：
在分布式系统中，所有节点在同一时间看到的数据是一致的。
例如，当用户向系统写入数据后，所有后续的读取操作都会返回最新的数据。
可用性（Availability）：
系统在任何时候都能正常响应请求，不会出现超时或错误。
例如，用户发起的请求总能得到响应，即使某些节点出现故障。
分区容错性（Partition Tolerance）：
系统在网络分区（即节点之间无法通信）的情况下，仍然能够继续运行。通常是必须满足的。
例如，即使某些节点之间的网络中断，系统仍然能够提供服务。
CA（一致性 + 可用性）：
放弃分区容错性，适用于单机系统或网络绝对可靠的场景。
CP（一致性 + 分区容错性）：
放弃可用性，在网络分区时，系统可能会拒绝请求，直到数据一致。
AP（可用性 + 分区容错性）：
放弃一致性，在网络分区时，系统可能会返回旧数据或不一致的数据。
键值存储（Key-Value）: 模型最简单，性能极高。代表： Redis （内存型，丰富数据结构）、 DynamoDB （云原生，自动扩缩容）。适用于会话缓存、购物车、计数器等场景。
文档存储（Document）: 以JSON/BSON格式存储半结构化数据，模式灵活。代表： MongoDB （最流行的文档数据库）、 Couchbase 。适用于内容管理系统、用户配置文件等。
宽列存储（Wide-Column）: 概念源于Google的BigTable。数据按列族存储，擅长海量数据的随机读写和范围查询。代表： Apache HBase （Hadoop生态）、 Cassandra(无中心化架构，高可用性极强)、 ScyllaDB(C++重写，性能怪兽)。适用于物联网、消息日志、用户行为数据存储。
图存储（Graph）: 专门为存储实体（节点）和关系（边）而设计，支持高效的图遍历和关系查询。代表： Neo4j （原生图存储）、 Nebula Graph(分布式开源方案)。适用于社交网络、欺诈检测、知识图谱、推荐系统。
==================================
存储引擎：LSM-Tree vs. B-Tree
存储引擎是数据库的“心脏”，决定了数据的组织和存取方式。
B-Tree（及其变种B+Tree）
○ 工作原理： 一种保持排序的平衡树，所有数据都存储在叶子节点。读写操作都是 原地更新（Update-in-place） 。
○ 优点： 优秀的读性能（尤其是范围查询），事务支持成熟。
○ 缺点： 随机写可能导致页分裂，产生碎片；写放大（Write Amplification）问题较严重。代表：MySQL InnoDB, PostgreSQL。
LSM-Tree（Log-Structured Merge-Tree）
○ 工作原理 ： 首先将写入操作追加到内存中的 MemTable （常跳表实现），写满后冻结并刷到磁盘形成不可变的 SSTable（Sorted String Table） 。后台通过 Compaction 过程将多个SSTable合并排序为更大的新文件。
○ 优点 ： 极高的写吞吐量 （顺序写代替随机写）， 更好的压缩率 （有序的SSTable）。
○ 缺点 ： 读放大（Read Amplification） （可能需要查找多个SSTable）， 写放大 （Compaction带来额外IO）。Compaction策略（Leveled vs. Size-Tiered）是调优核心。
○ 代表 ： Google LevelDB 、 RocksDB （Facebook基于LevelDB开发，事实上的标准嵌入式引擎），几乎所有现代NoSQL系统如Cassandra、ScyllaDB、HBase都基于RocksDB或类似LSM引擎构建。
=================================
分布式一致性协议
构建分布式存储系统必须解决数据一致性问题。
主从复制中的一致性 ：
○ 异步复制 ： 性能最好，但存在数据丢失风险（主宕机）。
○ 半同步复制 ： 至少一个从库确认后才向客户端返回成功，在性能和数据一致性间折衷。
○ 全同步复制 ： 所有从库确认，一致性最强，但延迟高。
分布式共识算法 ：
○ Paxos ： 理论上最优但极其复杂，难以工程实现。
○ Raft ： 为易于理解而设计，通过领导者选举、日志复制和安全性保证来维持一致性，已成为 事实标准 （Etcd, Consul, TiKV等均采用）。
○ ZAB ： Zookeeper原子广播协议，为ZooKeeper设计，与Rast思想类似。
=======================================
