初识NOSQL
初识NOSQL
- 1. NOSQL简介
- **Oracle NoSQL 数据库简介**
- **核心特性**
- **技术架构**
- **适用场景**
- **部署与集成**
- 2.关系型数据库与非关系数据库的区别
- **1. 核心特性对比**
- **2. 技术实现差异**
- **2.1 存储引擎**
- **2.2 分布式能力**
- **3. 典型应用场景**
- **关系型数据库**
- **非关系型数据库**
- **4. 优缺点对比**
- **5. 如何选择？**
- 3.NOSQL理论基础
- 1. CAP 理论
- **CAP 的核心矛盾**
- **实际案例**
- 2. BASE 理论
- **BASE 的核心思想**
- **实际案例**
- **关键说明**
- **3. CAP 与 BASE 的对比**
- **4. NoSQL 数据库的 CAP/BASE 实践**
- **1. CP 系统（强一致性优先）**
- **2. AP 系统（高可用性优先）**
- **3. 混合策略（CA 系统）**
- **5. 如何选择 CAP/BASE 策略**
1. NOSQL简介
Oracle NoSQL 数据库简介
核心特性
-
横向可扩展的分布式存储
- 专为键值对数据设计，支持大规模数据存储和高并发访问。
- 通过增加硬件资源（如节点）实现性能线性扩展，满足吞吐量需求。
-
高性能与低延迟
- 提供 低延迟 和 高吞吐量 的数据读写能力。
- 可预测的数据一致性（取决于存储配置），确保关键业务场景的可靠性。
-
高可用性（HA）
- 设计为高可用架构，减少单点故障风险，支持自动故障转移和数据冗余。
-
灵活的持久性保证
- 支持用户定义的读/写性能级别，提供可调整的持久性策略（如同步/异步写入）。
技术架构
-
底层存储引擎
- 基于 Oracle Berkeley DB Java Edition，提供高效、可靠的键值存储能力。
-
数据模型
- 键值对存储：数据以表或键值对形式存储，支持简单的 CRUD 操作（创建、读取、更新、删除）。
-
分布式架构
- 数据分片（Sharding）和自动负载均衡，支持跨数据中心部署和动态扩展。
适用场景
- 高吞吐量应用：如实时推荐系统、物联网（IoT）数据处理、在线广告投放等。
- 低延迟需求：适用于需要快速响应的场景（如金融交易、实时分析）。
- 云原生应用：支持弹性伸缩和分布式部署，适配云计算环境。
- 混合架构：可部署在传统三层架构（Web 服务器、应用服务器、后端数据库）中，作为后端数据库或与关系型数据库协同工作。
部署与集成
-
安装位置
- 推荐部署在应用服务器后方，或直接作为后端数据库使用。
-
驱动程序支持
- 提供 Java 驱动程序（.jar 文件），通过网络请求与数据库交互。
- 开发者可通过 Java API 实现数据操作（如 Put、Get、Delete）。
-
云服务支持
- 通过 Oracle NoSQL Database Cloud Service 提供托管服务，简化集群管理、监控和扩展。
如需进一步了解 Oracle NoSQL 数据库的特定功能（如一致性配置、云服务部署细节），可参考官方文档或联系 Oracle 技术支持
oracle开发官方文档主要操作
oracle概念文档
2.关系型数据库与非关系数据库的区别
关系型数据库与**非关系型数据库（NoSQL）**的核心区别总结，涵盖数据模型、扩展性、事务支持、查询语言、适用场景等方面：
1. 核心特性对比
| 特性 | 关系型数据库（RDBMS） | 非关系型数据库（NoSQL） |
|---|---|---|
| 数据模型 | 以二维表结构（行和列）组织数据，所有数据必须符合预定义的模式（Schema）。 | 采用灵活的数据模型，如键值对、文档、列族、图等，支持动态模式（Schema-less）或无模式设计。 |
| 数据一致性 | 遵循 ACID 原则（原子性、一致性、隔离性、持久性），保证强一致性。 | 通常遵循 BASE 原则（基本可用、软状态、最终一致性），优先保证高可用性和性能，允许短暂的不一致。 |
| 查询语言 | 使用 SQL（结构化查询语言），支持复杂查询（如 JOIN、子查询）。 | 通常使用特定 API 或类 SQL 语言，查询能力受限，但灵活性高（如 MongoDB 的 JSON 查询语法）。 |
| 扩展方式 | 垂直扩展（提升单机硬件性能），扩展性有限，难以应对海量数据。 | 水平扩展（通过添加节点实现分布式存储），天然支持大规模数据和高并发场景。 |
| 事务支持 | 支持完整的 ACID 事务，适合需要强一致性的业务（如金融交易）。 | 通常仅支持部分事务特性（如单文档原子操作），更适合最终一致性场景（如实时分析、缓存）。 |
| 适用场景 | 金融系统、ERP、CRM 等需要复杂事务和强一致性的场景。 | 社交媒体、物联网、实时分析等需要高可用性、高扩展性和灵活数据模型的场景。 |
2. 技术实现差异
2.1 存储引擎
-
关系型数据库：
- 采用 B+树索引（如 InnoDB 的聚簇索引），优化复杂查询。
- 严格遵循 WAL（Write-Ahead Logging） 机制，确保事务持久性。
-
非关系型数据库：
2.2 分布式能力
- 关系型数据库：
- 分布式支持较弱，需通过分库分表或集群（如 Oracle RAC）实现扩展，复杂度高。
- 非关系型数据库：
- 天然支持分布式架构，通过 分片（Sharding） 和 数据冗余 实现高可用性和负载均衡（如 Cassandra、MongoDB）。
3. 典型应用场景
关系型数据库
- 金融系统：银行交易、账户余额更新，需强一致性。
- 企业资源计划（ERP）：涉及复杂的业务逻辑和事务处理。
- 客户关系管理（CRM）：管理结构化客户数据，需复杂查询。
非关系型数据库
- 社交媒体：处理海量用户数据和高并发请求（如 Twitter 的用户关系存储）。
- 物联网（IoT）：存储传感器产生的非结构化日志数据（如时序数据库）。
- 实时分析：快速处理和分析海量数据（如日志分析、推荐系统）。
4. 优缺点对比
| 类别 | 关系型数据库 | 非关系型数据库 |
|---|---|---|
| 优点 | - 数据一致性高 - 支持复杂查询 - 成熟的生态系统 - 权限控制完善 | - 高可扩展性 - 灵活数据模型 - 高性能读写 - 低成本（开源方案多） |
| 缺点 | - 扩展性受限 - 模式修改成本高 - 海量数据性能下降 - 高并发场景瓶颈 | - 数据一致性较弱 - 查询能力受限 - 无标准化语言 - 不适合复杂事务处理 |
5. 如何选择？
-
选择关系型数据库：
- 需要强一致性（如金融交易）。
- 数据结构固定且复杂（如 ERP 系统）。
- 需要复杂查询和事务支持。
-
选择非关系型数据库：
- 数据量大且增长迅速（如 IoT 日志）。
- 需要高可用性和水平扩展（如社交网络）。
- 数据结构灵活多变（如用户配置存储）。
- 关系型数据库 是结构化数据的“传统王者”，适合需要强一致性和复杂事务的场景。
- 非关系型数据库 是大数据时代的“灵活新秀”，擅长处理海量、非结构化数据和高并发场景。
- 混合使用：实际中，两者常结合使用（如 MySQL + Redis 缓存），发挥各自优势。
3.NOSQL理论基础
1. CAP 理论
CAP 定理（Consistency, Availability, Partition Tolerance）是分布式系统设计的核心理论，由 Eric Brewer 提出，具体定义如下：
| 特性 | 定义 | 典型场景 |
|---|---|---|
| 一致性（C） | 所有节点在同一时间看到相同的数据（强一致性）。 | 银行转账、金融交易等需要实时数据同步的场景。 |
| 可用性（A） | 每个请求都能收到非错误的响应（高可用性）。 | 社交媒体、电商网站等需要持续服务的场景。 |
| 分区容错性（P） | 网络分区（节点间通信中断）时，系统仍能继续运行。 | 云原生架构、跨数据中心部署等必然面临网络分区的场景。 |
CAP 的核心矛盾
- CAP 三者不可兼得：在分布式系统中，必须在一致性（C）和可用性（A）之间做出权衡，因为分区容错性（P）是分布式系统的必然要求（无法避免网络故障）。
- 典型选择：
- CP 系统：优先保证一致性和分区容错性，牺牲可用性（如 MongoDB、HBase）。
- AP 系统：优先保证可用性和分区容错性，牺牲一致性（如 Cassandra、DynamoDB）。
实际案例
-
CP 系统（牺牲可用性，保证一致性）
- 场景：银行账户余额更新。
- 行为：当网络分区发生时，系统会阻止写操作，直到分区恢复，确保所有节点的数据一致。
- 缺点：用户可能无法完成交易，但数据不会出错。
-
AP 系统（牺牲一致性，保证可用性）
- 场景：电商秒杀活动。
- 行为：网络分区时，允许用户继续下单，但可能出现短暂的数据不一致（如库存超卖）。
- 缺点：需通过异步补偿（如事后对账）解决不一致问题。
2. BASE 理论
BASE 理论（Basically Available, Soft State, Eventually Consistent）是 NoSQL 数据库对 CAP 理论的灵活实践，强调 最终一致性 和 高可用性，适用于大规模分布式场景。
| 特性 | 定义 | 典型场景 |
|---|---|---|
| 基本可用（BA） | 在网络故障或负载激增时，允许损失部分功能（如降级、限流），但核心功能可用。 | 双 11 促销期间，购物车服务降级，但下单功能保持可用。 |
| 软状态（SS） | 允许系统存在中间状态（如数据延迟同步），但最终会达成一致。 | 微信充话费时，余额扣减后，话费到账可能存在短暂延迟。 |
| 最终一致性（EC） | 系统在一段时间后自动修复数据不一致，达到最终一致状态。 | 分布式数据库通过异步复制和冲突解决机制实现最终一致性。 |
BASE 的核心思想
- 容忍短暂不一致：通过异步处理和延迟同步，降低对实时一致性的依赖。
- 优先可用性：在分区发生时，系统仍能响应请求，后续通过补偿机制修复数据。
实际案例
-
电商平台的“基本可用”
- 场景：双 11 期间，系统限制非核心功能（如商品评价、收藏夹），但允许用户下单。
- 实现：通过限流、服务降级等手段，确保核心交易链路的可用性。
-
微信充话费的“软状态”
- 场景：用户提交充值后，系统先返回“处理中”，等待异步同步完成后通知“充值成功”。
- 实现：允许余额和话费系统存在短暂不一致，最终通过后台任务同步数据。
-
NoSQL 数据库的“最终一致性”
- 场景：Cassandra 中的读写操作允许配置一致性级别（如 QUORUM）。
- 实现：在分区期间，允许部分节点响应读请求，后续通过反熵（Anti-Entropy）机制修复数据。
以下是 BASE 理论中最终一致性的五种主要变体 的详细介绍，以表格形式呈现：
| 变体名称 | 定义 | 实例场景 |
|---|---|---|
| 因果一致性 | 若进程A更新数据后通知进程B，则进程B后续访问该数据时能获取到A的最新值；与A无因果关系的进程C则不受此限制。 | 社交平台动态更新：用户A更新了个人资料（如头像），用户B在看到A的动态后，能立即看到新头像；但用户C未关注A，则可能暂时看到旧头像，直到系统同步完成。 |
| 读己之所写 | 用户更新数据后，自身始终能读取到最新值（不会看到旧数据），但其他用户可能暂时看到旧数据。 | 电商用户信息修改：用户修改了收货地址后，立即在订单页面查看，系统返回新地址；但其他用户（如客服）可能暂时看到旧地址，后续自动同步。 |
| 会话一致性 | 在同一用户会话中，数据读取保持一致（如连续操作均看到最新数据），但不同会话间可能不一致。 | 购物车操作：用户A在浏览器会话中修改了购物车商品数量，后续页面均显示最新数量；若用户A新开浏览器会话，可能看到旧数量，需重新登录同步。 |
| 单调读 | 用户多次读取数据时，看到的版本不会倒退（即数据版本单调递增，不会从新版本回到旧版本）。 | 新闻阅读：用户首次读取新闻为版本1，刷新后看到版本2，再次刷新不会返回版本1，确保阅读体验连贯。 |
| 单调写 | 用户对同一数据的写操作顺序在所有副本中保持一致（后续写操作不会覆盖之前的操作，且按顺序执行）。 | 订单提交：用户A先提交订单1，再提交订单2，系统确保订单2的版本号高于订单1；即使网络分区，订单2不会覆盖订单1，最终按顺序同步。 |
关键说明
- 因果一致性：强调事件间的因果关系，是其他变体的基础（如读己之所写可视为因果一致性的特例）。
- 读己之所写：保障用户自身操作的体验，避免“修改后看不到新数据”的问题。
- 会话一致性：聚焦单个用户会话，适合需要会话状态的场景（如Web应用）。
- 单调读/写：确保数据操作的顺序性，避免数据混乱（如消息顺序、订单状态）。
- 共同目标：所有变体均通过短暂不一致+最终同步，实现高可用性和性能，符合 BASE 理论的核心思想。
3. CAP 与 BASE 的对比
| 特性 | CAP 理论 | BASE 理论 |
|---|---|---|
| 核心目标 | 强调分布式系统的三难抉择（C、A、P 无法同时满足）。 | 强调高可用性和最终一致性，接受短暂不一致。 |
| 适用场景 | 金融交易、强一致性要求高的场景（CP 系统）；高并发、弱一致性要求的场景（AP 系统）。 | 大数据、云原生、高可用性要求的场景（如社交网络、物联网）。 |
| 典型技术 | MySQL（CA 系统）、MongoDB（CP 系统）、Cassandra（AP 系统）。 | Cassandra、DynamoDB、Redis（支持最终一致性模式）。 |
| 权衡策略 | CP vs AP：在分区时选择牺牲可用性或一致性。 | BA + EC：通过降级和服务限制保证可用性，最终达成一致性。 |
4. NoSQL 数据库的 CAP/BASE 实践
不同 NoSQL 数据库根据 CAP/BASE 理论设计了不同的权衡策略：
1. CP 系统（强一致性优先）
-
MongoDB
- 一致性：主从复制中，写操作默认同步到大多数副本（W=majority）。
- 可用性：在分区期间，主节点不可用时，选举新主节点（Primary）以恢复服务。
- 适用场景：需要强一致性的业务（如订单管理、库存系统）。
-
HBase
- 一致性：基于 HDFS 的强一致性写入。
- 可用性：RegionServer 故障时，通过 Region 重新分配恢复服务。
- 适用场景：大数据分析、实时查询。
2. AP 系统（高可用性优先）
-
Cassandra
- 一致性：允许配置一致性级别（如 ONE、QUORUM、ALL）。
- 可用性：分区期间，任何节点均可响应读写请求。
- 适用场景：高写入吞吐量的场景（如日志存储、物联网数据）。
-
DynamoDB
- 一致性：支持最终一致性读和强一致性读（通过 ReadAfterWrite 参数）。
- 可用性：跨区域部署，自动故障转移。
- 适用场景：全球分布的高可用服务（如 AWS 服务）。
3. 混合策略（CA 系统）
- 传统 RDBMS（如 MySQL、PostgreSQL）
- 一致性：ACID 事务保障强一致性。
- 可用性：单点故障时服务不可用（除非启用主从复制）。
- 适用场景：本地部署的高一致性业务（如财务系统）。
5. 如何选择 CAP/BASE 策略
| 业务需求 | 推荐策略 | 典型数据库 |
|---|---|---|
| 强一致性 | CP 系统（牺牲可用性） | MongoDB、HBase、MySQL（主从强同步） |
| 高可用性 | AP 系统（牺牲一致性） | Cassandra、DynamoDB、Redis（最终一致性模式） |
| 混合需求 | 根据场景动态调整（如 MySQL + Redis 缓存） | MySQL + Redis、MongoDB + Kafka 异步同步 |
| 大规模分布式场景 | AP 系统 + 最终一致性机制 | Cassandra、Couchbase、Amazon DynamoDB |
- CAP 理论 是分布式系统设计的基石，决定了系统在一致性、可用性和分区容错性之间的权衡。
- BASE 理论 是 CAP 的灵活实践，通过 基本可用 和 最终一致性 适应大规模分布式场景。
- NoSQL 数据库 根据业务需求选择 CP 或 AP 策略，例如：
- CP 系统：适合金融、强一致性场景。
- AP 系统：适合高并发、弱一致性场景。
- 实际应用 中，通常结合 CAP 和 BASE 的优势，通过分层架构（如 MySQL + Redis）或混合部署（如 MongoDB + Kafka）实现最佳平衡。