关系型数据库和非关系型数据库

日月星辰Ace
156 阅读24分钟

NoSQL 数据库和 SQL 数据库的区别

SQL 数据库（关系型数据库）和 NoSQL 数据库（非关系型数据库）是两种不同类型的数据库系统，它们在数据模型、查询方式、扩展性等方面有显著区别。以下是它们的主要区别：

1. 数据模型

  • SQL 数据库：

    • 使用 关系型数据模型，数据存储在表格中，表由行和列组成。
    • 数据具有严格的结构化模式（Schema），每一行必须遵循表的定义。
    • 适合存储结构化数据。
    • 示例：MySQL、PostgreSQL、Oracle、SQL Server。

  • NoSQL 数据库：

    • 使用 非关系型数据模型，数据可以是键值对、文档、列族或图形结构。
    • 数据没有固定的模式（Schema-less），可以灵活存储不同结构的数据。
    • 适合存储非结构化或半结构化数据。
    • 示例：MongoDB（文档型）、Redis（键值型）、Cassandra（列族型）、Neo4j（图形型）。

2. 查询语言

  • SQL 数据库：

    • 使用 结构化查询语言（SQL）  进行数据操作。
    • 查询语句如：SELECT * FROM table_name WHERE condition;
    • SQL 提供强大的查询功能，支持复杂的 JOIN 和事务操作。

  • NoSQL 数据库：

    • 没有统一的查询语言，不同数据库有各自的查询方式。

    • 例如：

      • MongoDB 使用 JSON 风格的查询语法：db.collection.find({ key: value })
      • Redis 使用命令行操作：GET key

    • 查询方式通常更简单，但不支持复杂的关系查询。

3. 扩展性

  • SQL 数据库：

    • 垂直扩展（Scale-Up） ：通过增加单台服务器的硬件资源（如 CPU、内存）来提升性能。
    • 垂直扩展有硬件限制，扩展性较差。

  • NoSQL 数据库：

    • 水平扩展（Scale-Out） ：通过增加更多的服务器节点来提升性能。
    • 天然支持分布式架构，扩展性更强，适合大规模数据存储和高并发场景。

4. 事务支持

  • SQL 数据库：

    • 支持 ACID（原子性、一致性、隔离性、持久性）事务，确保数据一致性。
    • 适合对数据一致性要求高的场景（如银行、财务系统）。

  • NoSQL 数据库：

    • 通常不完全支持 ACID，而是遵循 BASE（基本可用、软状态、最终一致性）模型。
    • 更注重性能和可用性，适合对一致性要求不高的场景（如社交媒体、日志存储）。

5. 性能和适用场景

  • SQL 数据库：

    • 性能较高，但在处理大规模数据和高并发时可能会遇到瓶颈。
    • 适用于结构化数据、事务性操作和复杂查询的场景。
    • 示例场景：银行系统、ERP 系统、电子商务平台。

  • NoSQL 数据库：

    • 性能优异，特别是在大规模数据存储和高并发访问场景下。
    • 适用于非结构化数据、实时分析和分布式存储的场景。
    • 示例场景：社交网络、物联网、日志分析、缓存系统。

6. 灵活性

  • SQL 数据库：

    • 数据模式固定，修改表结构需要迁移数据，灵活性较低。
    • 适合数据结构稳定的场景。

  • NoSQL 数据库：

    • 数据模式灵活，可以随时存储不同结构的数据。
    • 适合数据结构经常变化的场景。

7. 社区和工具支持

  • SQL 数据库：

    • 历史悠久，社区成熟，工具和文档丰富。
    • 适合需要长期维护和支持的项目。

  • NoSQL 数据库：

    • 起步较晚，社区和工具支持相对较少，但发展迅速。
    • 适合快速开发和创新项目。

总结

特性SQL 数据库NoSQL 数据库
数据模型关系型（表格结构）非关系型（键值、文档、列族、图形）
查询语言SQL各自定义的查询方式
扩展性垂直扩展（Scale-Up）水平扩展（Scale-Out）
事务支持支持 ACID 事务遵循 BASE 模型
性能适合结构化数据和复杂查询适合大规模数据和高并发场景
灵活性数据模式固定数据模式灵活
适用场景银行、ERP、电子商务等社交网络、物联网、日志分析等

选择建议

  • 选择 SQL 数据库：

    • 如果你的数据是结构化的，且需要复杂查询和事务支持（如银行、财务系统）。

  • 选择 NoSQL 数据库：

    • 如果你的数据是非结构化或半结构化的，且需要高并发和分布式存储（如社交网络、实时分析）。

垂直扩展和水平扩展

垂直扩展（Vertical Scaling）和水平扩展（Horizontal Scaling）的介绍

垂直扩展和水平扩展是两种常见的系统扩展方式，用于提升系统的性能和处理能力。以下是它们的详细介绍：

1. 垂直扩展（Vertical Scaling）

定义：

垂直扩展是通过增加单台服务器的硬件资源（如 CPU、内存、存储等）来提升系统性能。

特点：
  • 单节点增强：增强单台服务器的性能，而不是增加服务器数量。
  • 硬件依赖：需要升级现有服务器的硬件配置（如更换更强的 CPU、增加内存或存储）。
  • 简单性：实现相对简单，因为不需要改变系统架构。
优点：
  1. 实现简单：无需对应用程序或架构进行复杂的修改。
  2. 一致性：所有数据和服务都在同一台服务器上，避免了分布式系统中的一致性问题。
  3. 适合小规模系统：对于小型应用或初期阶段的系统，垂直扩展是快速提升性能的有效方式。
缺点：
  1. 硬件限制：单台服务器的硬件资源有上限（如 CPU 核心数、内存容量等）。
  2. 成本高：高性能硬件（如高端服务器）通常价格昂贵。
  3. 单点故障：系统依赖单台服务器，若服务器出现故障，整个系统可能会不可用。
适用场景：
  • 数据量和并发量较小的系统。
  • 需要快速提升性能，但不希望改变系统架构。
  • 例如：小型网站、初创阶段的应用。

2. 水平扩展（Horizontal Scaling）

定义：

水平扩展是通过增加更多的服务器节点（即扩展服务器的数量）来提升系统性能。

特点：
  • 多节点扩展：通过增加服务器数量来分担负载。
  • 分布式架构：通常需要支持分布式系统架构（如负载均衡、分布式存储等）。
  • 灵活性：可以根据需求动态增加或减少服务器数量。
优点：
  1. 高扩展性：可以通过增加服务器数量来无限扩展系统的处理能力。
  2. 高可用性：多个节点分担负载，单个节点故障不会导致系统不可用。
  3. 成本可控：可以使用多台低成本服务器代替单台高性能服务器。
缺点：
  1. 复杂性增加：需要实现分布式架构（如负载均衡、数据分片、一致性管理等）。
  2. 一致性问题：在分布式系统中，数据一致性和同步可能成为挑战。
  3. 网络依赖：节点之间的通信依赖网络，可能会引入额外的延迟。
适用场景：
  • 数据量和并发量较大的系统。
  • 需要高可用性和容错能力的系统。
  • 例如：大型电商平台、社交网络、分布式存储系统。

垂直扩展 vs 水平扩展

特性垂直扩展（Vertical Scaling）水平扩展（Horizontal Scaling）
扩展方式增加单台服务器的硬件资源增加服务器节点数量
实现复杂度简单较复杂，需要分布式架构支持
扩展性有限（受硬件上限限制）高（理论上可以无限扩展）
成本高（高性能硬件价格昂贵）较低（使用多台低成本服务器）
单点故障存在单点故障风险无单点故障，容错能力强
适用场景小型系统、初期阶段的应用大型系统、高并发、高可用性场景

总结

  • 垂直扩展：

    • 适合小型系统或初期阶段的应用，快速提升性能。
    • 受硬件限制，扩展能力有限，成本较高。

  • 水平扩展：

    • 适合大型系统或高并发场景，具有更高的扩展性和容错能力。
    • 实现复杂度较高，需要分布式架构支持。

在实际应用中，很多系统会结合两种扩展方式：先通过垂直扩展提升单节点性能，随后通过水平扩展实现更高的扩展性和可用性。

为什么 SQL 数据库是垂直扩展，NoSQL 是水平扩展？

1. SQL 数据库（关系型数据库）是垂直扩展的原因

SQL 数据库（如 MySQL、PostgreSQL、Oracle 等）通常依赖于单一服务器来存储和管理数据，以下是其垂直扩展的主要原因：

  • 强一致性要求：

    • SQL 数据库遵循 ACID（原子性、一致性、隔离性、持久性）事务模型，确保数据的强一致性。
    • 为了实现强一致性，SQL 数据库通常需要集中式的存储和管理，依赖单一节点来处理事务和查询。

  • 复杂的关系查询：

    • SQL 数据库支持复杂的 JOIN、嵌套查询等操作，这些操作需要在单一节点上处理大量数据。
    • 如果分布式存储，跨节点的关系查询会变得非常复杂，性能也会显著下降。

  • 扩展方式：

    • 为了提升性能，SQL 数据库通常通过增加单台服务器的硬件资源（如 CPU、内存、存储）来扩展性能，这就是垂直扩展（Scale-Up）。
    • 这种方式简单直接，但受限于单台服务器的硬件上限。
2. NoSQL 数据库（非关系型数据库）是水平扩展的原因

NoSQL 数据库（如 MongoDB、Cassandra、Redis 等）设计之初就考虑了分布式架构，以下是其水平扩展的主要原因：

  • 弱一致性模型：

    • NoSQL 数据库通常遵循 BASE（基本可用、软状态、最终一致性）模型，允许数据在短时间内不一致，但最终会达到一致性。
    • 这种弱一致性模型使得数据可以分布在多个节点上，便于水平扩展。

  • 无固定模式：

    • NoSQL 数据库通常是 Schema-less（无固定模式）的，数据可以灵活存储在不同节点上。
    • 这种灵活性使得数据分片（Sharding）和分布式存储更加容易。

  • 分布式架构：

    • NoSQL 数据库天然支持分布式存储和计算，数据可以分布在多个节点上，每个节点独立处理一部分数据。
    • 通过增加节点数量（水平扩展，Scale-Out），可以轻松提升系统的存储能力和并发处理能力。

  • 扩展方式：

    • NoSQL 数据库通过增加更多的服务器节点来扩展性能，这就是水平扩展（Scale-Out）。
    • 这种方式扩展性强，理论上可以无限扩展。

SQL 和 NoSQL 的存储原理

1. SQL 数据库的存储原理

SQL 数据库使用关系型数据模型，数据存储在表中，表由行和列组成。以下是其存储原理的关键点：

  • 行存储（Row-Oriented Storage） ：

    • 数据按行存储，每一行表示一个完整的记录。
    • 适合事务性操作（如插入、更新、删除），因为一行数据可以快速读取和修改。
    • 示例：
Table: Users
+----+-------+-------+
| ID | Name  | Age   |
+----+-------+-------+
| 1  | Alice | 25    |
| 2  | Bob   | 30    |
+----+-------+-------+

  • 索引：

    • SQL 数据库使用索引（如 B+树、哈希索引）来加速查询。
    • 索引存储在单一节点上，依赖集中式管理。

  • 事务日志：

    • SQL 数据库使用事务日志（WAL，Write-Ahead Logging）来确保数据的持久性和一致性。

  • 存储限制：

    • 数据通常存储在单一服务器上，受限于单台服务器的存储容量和性能。
2. NoSQL 数据库的存储原理

NoSQL 数据库根据类型不同，存储原理也有所不同。以下是几种常见的 NoSQL 数据库存储方式：

  • 键值存储（Key-Value Store） ：

    • 数据以键值对的形式存储，类似于一个巨大的哈希表。
    • 示例：Redis、DynamoDB。
Key: "user:1"
Value: { "name": "Alice", "age": 25 }

文档存储（Document Store） ：

  • 数据以文档的形式存储，通常使用 JSON 或 BSON 格式。
  • 每个文档可以有不同的结构，适合存储非结构化或半结构化数据。
  • 示例：MongoDB。
{
  "_id": 1,
  "name": "Alice",
  "age": 25,
  "address": { "city": "New York", "zip": "10001" }
}

列族存储（Column-Family Store） ：

  • 数据按列存储，每一列族可以独立存储和查询。
  • 适合大规模数据分析场景。
  • 示例：Cassandra、HBase。
RowKey: 1
ColumnFamily: PersonalInfo
  Name: Alice
  Age: 25

图存储（Graph Store） ：

  • 数据以图的形式存储，节点和边表示实体及其关系。
  • 适合社交网络、推荐系统等场景。
  • 示例：Neo4j。
Node: User { "name": "Alice" }
Edge: Follows -> User { "name": "Bob" }

  • 分布式存储：

    • 数据通过分片（Sharding）分布在多个节点上，每个节点存储一部分数据。
    • 数据分片通常基于键值的哈希值或范围。
    • 示例：Cassandra 使用一致性哈希分片，MongoDB 使用范围分片。

总结

特性SQL 数据库NoSQL 数据库
扩展方式垂直扩展（Scale-Up）水平扩展（Scale-Out）
一致性模型强一致性（ACID）最终一致性（BASE）
存储模型关系型（表格结构）非关系型（键值、文档、列族、图形）
存储位置集中式存储，依赖单一服务器分布式存储，数据分布在多个节点上
适用场景事务性操作、复杂查询高并发、大规模数据、非结构化数据存储

  • SQL 数据库 是垂直扩展的，因为它依赖单一服务器来保证强一致性和复杂查询的性能。

  • NoSQL 数据库 是水平扩展的，因为它设计之初就考虑了分布式存储和高并发场景，能够通过增加节点轻松扩展性能。- 分布式存储：

    • 数据通过分片（Sharding）分布在多个节点上，每个节点存储一部分数据。
    • 数据分片通常基于键值的哈希值或范围。
    • 示例：Cassandra 使用一致性哈希分片，MongoDB 使用范围分片。

总结

特性SQL 数据库NoSQL 数据库
扩展方式垂直扩展（Scale-Up）水平扩展（Scale-Out）
一致性模型强一致性（ACID）最终一致性（BASE）
存储模型关系型（表格结构）非关系型（键值、文档、列族、图形）
存储位置集中式存储，依赖单一服务器分布式存储，数据分布在多个节点上
适用场景事务性操作、复杂查询高并发、大规模数据、非结构化数据存储
  • SQL 数据库 是垂直扩展的，因为它依赖单一服务器来保证强一致性和复杂查询的性能。
  • NoSQL 数据库 是水平扩展的，因为它设计之初就考虑了分布式存储和高并发场景，能够通过增加节点轻松扩展性能。

DynamoDB 和 MySql 存储方式

DynamoDB 的数据存储方式

你对 DynamoDB 的理解是正确的。DynamoDB 使用 Partition Key 和 Hash 算法 来决定数据的存储位置：

  1. Partition Key 和 Hash 算法：

    • 每条记录的 Partition Key 会通过 Hash 算法计算出一个 Hash 值。
    • 这个 Hash 值决定了数据存储在哪个分区（Partition）上。
    • DynamoDB 的分区是逻辑上的存储单元，每个分区可以分布在不同的物理服务器上。

  2. 数据存储在分区中：

    • 同一个 Partition Key 的所有数据（包括不同的 Sort Key）会存储在同一个分区中。
    • 这使得基于 Partition Key 的查询非常高效，因为 DynamoDB 只需要访问对应的分区即可。

  3. 分布式存储：

    • DynamoDB 是分布式数据库，数据会根据 Partition Key 的 Hash 值分布在多个分区上。
    • 这种设计使得 DynamoDB 能够轻松扩展，支持大规模数据存储和高并发访问。

MySQL 的数据存储方式

MySQL 是关系型数据库，其数据存储方式与 DynamoDB 不同。以下是 MySQL 的数据存储原理：

1. 数据存储在表中
  • MySQL 使用表（Table）来存储数据，表由行（Row）和列（Column）组成。
  • 每一行表示一条记录，每一列表示记录的一个字段。
2. 数据存储在页（Page）中
  • MySQL 的底层存储引擎（如 InnoDB）将数据存储在 页（Page）  中。
  • 每个页的大小通常为 16KB（InnoDB 默认值）。
  • 一个页可以存储多行数据。
3. 数据存储在数据文件中
  • 表的数据存储在数据文件中（如 .ibd 文件）。
  • 数据文件由多个页组成，页是 MySQL 存储的基本单位。
4. 数据的组织方式

MySQL 的数据存储方式取决于存储引擎，以下是 InnoDB 的存储方式：

  • 聚簇索引（Clustered Index） ：

    • InnoDB 使用聚簇索引存储数据。
    • 表中的数据按主键（Primary Key）的顺序存储在同一个数据页中。
    • 每个数据页存储一部分主键范围内的数据。
    • 如果没有定义主键，InnoDB 会选择一个唯一非空索引作为聚簇索引；如果没有这样的索引，InnoDB 会自动生成一个隐藏的主键。

  • 二级索引（Secondary Index） ：

    • 二级索引存储的是索引列的值和对应的主键值。
    • 查询时，MySQL 通过二级索引找到主键值，再通过主键值访问聚簇索引获取完整数据。
5. 什么样的数据存储在一块？

  • 同一个数据页中的数据：

    • 按主键顺序相邻的记录会存储在同一个数据页中。
    • 例如，主键为 1、2、3 的记录可能存储在同一个页中，而主键为 4、5、6 的记录可能存储在另一个页中。

  • 分区表（Partitioned Table） ：

    • 如果使用分区表，数据会根据分区键（Partition Key）分布到不同的分区中。
    • 每个分区存储一部分数据，分区可以存储在不同的文件中。

DynamoDB 和 MySQL 数据存储方式的对比

特性DynamoDBMySQL
存储模型键值对（Key-Value）关系型表（Row 和 Column）
数据分布基于 Partition Key 的 Hash 值分布到分区数据存储在页中，按主键顺序存储
存储单元分区（Partition）页（Page），每页通常为 16KB
数据存储在一块的依据同一个 Partition Key 的数据存储在一起按主键顺序相邻的记录存储在同一个数据页中
扩展方式水平扩展（分布式存储）垂直扩展（单节点存储）

总结

  • DynamoDB：

    • 数据根据 Partition Key 的 Hash 值分布到不同的分区中。
    • 同一个 Partition Key 的数据存储在同一个分区中，便于高效查询。

  • MySQL：

    • 数据按主键顺序存储在页中，相邻的主键记录存储在同一个页中。
    • 如果使用分区表，数据会根据分区键分布到不同的分区中。

两者的存储方式反映了它们的设计目标：

  • DynamoDB 设计为分布式数据库，强调水平扩展和高并发。
  • MySQL 设计为关系型数据库，强调数据一致性和复杂查询支持。

MySql 分区表

分区表（Partitioned Table）  是 MySQL 中的一种表结构优化技术，用于将一张大表的数据按照某种规则分成多个物理存储单元（分区）。每个分区独立存储数据，但对用户来说，这些分区逻辑上仍然是一个整体表。

分区表的主要目的是提高查询性能、优化存储管理，并支持更高效的操作（如删除或归档数据）。

分区表的特点

  1. 逻辑上是一个表：

    • 对用户来说，分区表仍然是一个完整的表，查询和操作方式与普通表一致。

  2. 物理上分为多个分区：

    • 数据根据分区规则存储到不同的分区中，每个分区可以存储在不同的文件中。

  3. 分区是透明的：

    • 用户无需关心数据存储在哪个分区，MySQL 会根据分区规则自动将数据路由到正确的分区。

  4. 分区的限制：

    • 分区表的分区键必须是表中的某一列，且分区键必须出现在分区规则中。
    • 分区表不支持某些功能（如外键）。

分区表的类型

MySQL 支持以下几种分区类型（通过 PARTITION BY 指定）：

1. RANGE 分区
  • 按照范围划分数据，每个分区存储一个范围内的数据。
  • 适用场景：按时间、数值范围划分数据。
  • 示例：
CREATE TABLE orders (
    order_id INT,
    order_date DATE,
    customer_id INT
)
PARTITION BY RANGE (YEAR(order_date)) (
    PARTITION p0 VALUES LESS THAN (2000),
    PARTITION p1 VALUES LESS THAN (2010),
    PARTITION p2 VALUES LESS THAN (2020),
    PARTITION p3 VALUES LESS THAN MAXVALUE
);
    • 数据会根据 order_date 的年份划分到不同的分区中。
2. LIST 分区
  • 按照离散值划分数据，每个分区存储特定值的数据。
  • 适用场景：按分类字段（如地区、状态）划分数据。
  • 示例：
CREATE TABLE customers (
    customer_id INT,
    customer_name VARCHAR(50),
    region VARCHAR(20)
)
PARTITION BY LIST (region) (
    PARTITION p_north VALUES IN ('North', 'Northeast'),
    PARTITION p_south VALUES IN ('South', 'Southeast'),
    PARTITION p_west VALUES IN ('West'),
    PARTITION p_east VALUES IN ('East')
);
    • 数据会根据 region 的值存储到对应的分区中。
3. HASH 分区
  • 使用哈希函数对分区键进行计算，将数据均匀分布到多个分区中。
  • 适用场景：需要均匀分布数据以避免热点问题。
  • 示例：
CREATE TABLE logs (
    log_id INT,
    log_message TEXT
)
PARTITION BY HASH(log_id) PARTITIONS 4;
    • 数据会根据 log_id 的哈希值分布到 4 个分区中。
4. KEY 分区
  • 类似于 HASH 分区，但使用 MySQL 内置的哈希函数。
  • 适用场景：与 HASH 分区类似，但不需要用户指定哈希函数。
  • 示例：
CREATE TABLE logs (
    log_id INT,
    log_message TEXT
)
PARTITION BY KEY(log_id) PARTITIONS 4;

分区表的优点

  1. 提高查询性能：

    • 查询时，MySQL 只会扫描相关的分区，而不是整个表，减少了 I/O 操作。

  2. 优化存储管理：

    • 每个分区可以存储在不同的文件中，便于管理大表的数据。

  3. 高效的删除和归档：

    • 可以通过删除分区快速清理数据，而不需要逐行删除。

  4. 支持大规模数据：

    • 分区表可以存储更多的数据，突破单个表的存储限制。

分区表的缺点

  1. 功能限制：

    • 分区表不支持外键。
    • 某些存储引擎（如 MyISAM）不支持分区。

  2. 复杂性增加：

    • 分区表的设计和维护比普通表更复杂，需要合理设计分区规则。

  3. 分区键限制：

    • 分区键必须出现在查询条件中，否则无法利用分区优化。

  4. 性能问题：

    • 如果分区设计不合理，可能导致数据分布不均，影响性能。

分区表的适用场景

  1. 按时间划分数据：

    • 例如，按年份或月份存储日志、订单等时间序列数据。

  2. 按分类字段划分数据：

    • 例如，按地区、状态等字段存储用户或订单数据。

  3. 大规模数据存储：

    • 例如，存储超过单表容量限制的大量数据。

  4. 需要快速删除或归档数据：

    • 例如，定期删除过期数据或归档历史数据。

总结

  • 分区表 是 MySQL 中的一种优化技术，用于将大表的数据分成多个分区存储。
  • 分区表可以提高查询性能、优化存储管理，并支持更高效的数据操作。
  • 常见的分区类型包括 RANGE、LIST、HASH 和 KEY 分区。
  • 分区表适用于大规模数据存储、时间序列数据管理和高效数据归档等场景，但需要合理设计分区规则以避免性能问题。

DynamoDB GSI 不能确定唯一性

为什么 DynamoDB 的 Partition Key 可以保证数据唯一性，而 GSI 不能？

1. Partition Key 的唯一性

在 DynamoDB 中，Partition Key 是表的主键的一部分（如果是复合主键，则包括 Partition Key 和 Sort Key）。DynamoDB 的主键具有以下特性：

  • Partition Key 唯一性：

    • 在 DynamoDB 表中，每个 Partition Key 必须是唯一的（如果没有 Sort Key）。
    • 如果表定义了复合主键（Partition Key + Sort Key），则 Partition Key 和 Sort Key 的组合必须唯一。
    • DynamoDB 会根据 Partition Key 的值计算出一个 Hash 值，并将数据存储到对应的分区中。如果插入一条数据时，Partition Key 的值已经存在，则 DynamoDB 会覆盖该记录。

  • 保证唯一性：

    • 由于 Partition Key 是主键的一部分，DynamoDB 会强制确保主键的唯一性，因此可以通过定义 Partition Key 来保证一条数据是唯一的。
2. GSI（全局二级索引）的特性

GSI（Global Secondary Index）  是 DynamoDB 提供的一种索引机制，用于支持基于非主键字段的查询。GSI 的特性如下：

  • GSI 的独立性：

    • GSI 是基于表中某些字段的索引，独立于主表的主键。
    • GSI 的 Partition Key 和 Sort Key 不需要唯一，多个记录可以有相同的 GSI Partition Key 和 Sort Key。

  • 数据同步：

    • GSI 是通过异步方式从主表同步数据的，主表的更新会异步反映到 GSI 中。
    • 由于是异步同步，可能会出现短暂的不一致性（例如，主表更新后，GSI 中的数据尚未更新）。

  • 不能强制唯一性：

    • GSI 的设计目标是支持高效查询，而不是强制数据唯一性。
    • DynamoDB 不会对 GSI 的 Partition Key 和 Sort Key 进行唯一性检查，因此无法通过 GSI 来保证数据的唯一性。
3. 为什么 GSI 不能保证唯一性？

以下是 GSI 无法保证唯一性的主要原因：

  1. GSI 的设计目标：

    • GSI 的目的是提供灵活的查询能力，而不是用于强制约束数据的唯一性。
    • 唯一性约束需要在主表的主键上实现，而不是在索引上。

  2. GSI 的异步更新机制：

    • GSI 的数据是从主表异步同步的，可能会出现短暂的不一致性。
    • 如果允许通过 GSI 强制唯一性，可能会导致数据冲突或一致性问题。

  3. GSI 的多对多关系：

    • GSI 的 Partition Key 和 Sort Key 可以重复，多个主表记录可以映射到同一个 GSI 索引项。
    • DynamoDB 不会对 GSI 的键进行唯一性检查，因此无法保证唯一性。
4. 如何在 DynamoDB 中实现唯一性约束？

虽然 GSI 本身不能保证唯一性，但可以通过以下方式实现唯一性约束：

  1. 使用主表的主键（Partition Key 或 Partition Key + Sort Key） ：

    • 主表的主键天然保证唯一性，因此可以通过设计主键来实现唯一性约束。

  2. 在主表中存储唯一标识：

    • 将需要唯一的字段（如 email、username）作为主表的 Partition Key 或 Sort Key。

  3. 使用事务（Transaction） ：

    • DynamoDB 支持事务操作，可以在插入数据时检查是否存在重复记录，从而实现唯一性约束。

  4. 在应用层实现唯一性检查：

    • 在写入数据之前，先查询 GSI 或主表，检查是否存在重复记录。
    • 注意：这种方式可能会有并发问题，需要结合事务或其他机制确保一致性。
总结

  • Partition Key 的唯一性：

    • DynamoDB 的主键（Partition Key 或 Partition Key + Sort Key）是表的唯一标识，DynamoDB 会强制确保主键的唯一性。

  • GSI 的非唯一性：

    • GSI 是为了支持灵活查询而设计的，Partition Key 和 Sort Key 可以重复，且数据是异步同步的，因此无法保证唯一性。

  • 实现唯一性约束的建议：

    • 如果需要唯一性约束，应通过主表的主键实现，或者在应用层结合事务进行检查。
avatar
文章
阅读
粉丝