数据管理之数据存储

一、数据存储如何操作

1.1 数据存储与操作的目标： 1）在整个数据生命周期中管理数据的可用性：说白了就是数据保存了，别人需要用的时候能找到。 2）确保数据资产的完整性：录入的数据不能乱，比如年龄录成负数这种错误。数据被修改时必须有规则，不能随便乱改。 3）管理数据交易事务的性能：意思是当系统对数据进行操作（比如存、取、改、删）时，要保证这些操作能快速完成，不卡顿、不失败。

简单总结：

• 第一条是保证数据“随时能用”。
• 第二条是保证数据“真实准确”。
• 第三条是保证系统“操作数据时又快又稳”。

定义存储的需求:

在正常的业务运营中，数据存入存储介质，取决于是要永久性存放还是临时性存放。在真正提供存储空间之前，做好增加额外空间的规划是很重要的。紧急情况下的任何维护操作都是危险的。所有项目都应该作第一年运营的初始容量估算，以及未来几年内的空间增长预测。空间和增长的评估，不要只考虑数据自身所需空间，还要考虑索引、日志以及其他任何的冗余特征。

1.2 数据架构类型（就是数据库分类）

    数据库可以分为**集中式数据库**和**分布式数据库**。集中式系统管理单一数据库，而分布式系统管理多个系统上的多个数据库。分布式系统组件可以根据组件系统的自治性分为两类：**联邦的（自治的）或非联邦的（非自治的）**。

   联邦模式还分紧耦合和松耦合。

   区块链数据库属于一种联邦数据库，用于安全管理金融交易。它们也能用来进行合同管理或健康信息交换。

什么是组件系统的自治性？ 看一个组件在分布式系统里能不能“独立完成自己的事情”，而不是总要靠别人帮忙或者指挥。举例就是电商系统中的订单和库存服务，订单系统接到订单之后，如果不检查库存是否充足，而是先把订单创建好了、通过MQ发送消息，订单database和库存database都是独立，那他俩就是高自治的

1.3 分布式系统两个定理

CAP定理：

CAP 定理是分布式系统的核心理论之一，提出了在一个分布式系统中，不可能同时满足以下三个条件：

• 一致性 (Consistency)：每个读操作都能返回最新的写入数据，系统中的所有节点始终看到相同的数据。例如，你更新了一个账号的余额，所有人看到的余额都要立刻是最新的。
• 可用性 (Availability)：每个请求都会得到响应，无论请求是否成功（即使无法访问最新的数据，系统仍会返回响应）。系统随时可以使用，不管发生什么问题。例如，如果你想查看余额，系统一定会给你一个响应，哪怕这个余额不一定是最新的。
• 分区容忍性 (Partition Tolerance)：系统在网络分区的情况下仍能继续正常运行，系统中的部分节点间可能无法通信，但系统依然能处理请求。即使系统的某些部分因为网络问题无法通信，系统仍然能继续正常工作。例如，某两个服务器之间失去了联系，但系统仍然能接受你的请求。

BASE 定理：

BASE 定理可以看作是对 CAP 定理 的一种“折中”，它告诉我们，如果系统选择牺牲 一致性 来提高 可用性，可以使用一些技巧来处理数据的不一致性。简单来说，BASE 定理关注的是“最终一致性”，也就是说系统最终会确保所有数据是一致的，但并不是马上就能一致。BASE对强一致性是不要求的，只需要最终一致。

• 基本可用 (Basically Available)：大部分时候，系统能响应你的请求，就算可能会暂时不返回最新的数据。
• 软状态 (Soft State)：系统状态不固定，可能会有暂时的数据不一致，但这不影响系统运行。
• 最终一致性 (Eventually Consistent)：系统最终会变得一致，虽然在某个时刻可能不一致。

BASE 定理的意思是：你可以选择让系统在短时间内不一致（为了更高的可用性），但它会在一定时间后通过一些机制修复这些不一致，保证最终一致。

1.4 数据库管理过程

    以下的管理过程，是不区分数据库类型，不管是关系型数据库还是NoSQL数据库都适用。

（1）数据归档

      我理解的数据归档，是对那些历史数据适用的，当历史数据很大，已经影响到现有数据的查询使用的时候，就需要归档。
      归档（Archiving）是将数据从**可立即访问的存储介质**迁移到**查询性能较低的存储介质**上的过程。归档后的数据可以恢复到原系统，供短期使用。不需要活跃地支持应用程序处理的数据，应迁移到价格较低的磁盘、磁带或CD/DVD光盘中进行归档。从归档中恢复的过程简单来说是将归档文件中的数据复制回原系统。

    归档过程必须与分区策略保持一致，以确保最佳的可用性和数据保留度。稳妥的方法包括：

1）创建一个辅助存储区域，优先建在辅助数据库服务器上。大白话就是创建一个新的数据库，拷贝原有的数据，可以考虑多台服务器，区分主数据库和存档数据库，数据库支持分区、迁移就行。 2）将当前的数据库表分区成可以归档的单元。大白话：把大表切成小块，每个小块都可以单独存储和管理。这些小块可以按照不同的标准划分，比如按时间、类别等。这样，你就能轻松地把不常用的“块”迁移到辅助存储区。这里就要考虑分区策略，常见的分区策略就是范围分区，也就是北京地区的分表单独拎出来，这样查询北京地区的数据会很快，不用全表扫描再用where语句筛选。需要注意分区策略不涉及用户权限，北京地区的人还是可以查询所有地区数据。 3）将不经常使用的数据复制到单独的数据库。 4）创建磁带或磁盘备份。 5）创建数据库任务，定期清理不再使用的数据。

 有归档就有**恢复归档**：

方法一：直接从辅助数据库恢复

如果归档数据保存在一个辅助数据库中：

1. 查询需要恢复的数据：例如通过 SQL 查询找到需要恢复的部分数据。
2. 导入到主数据库：可以通过以下方式完成：
   • SQL语句：使用 INSERT INTO 或 SELECT INTO 将辅助数据库的数据插入主数据库。
   • ETL工具：使用数据迁移工具（如 Talend、DataX 等）进行数据迁移。

方法二：从文件恢复

如果归档数据存储在文件（如 .csv、.json 或 .sql）中：

1. 加载文件：使用数据库的工具加载文件，例如：
   • MySQL：LOAD DATA INFILE 或 mysqlimport

2.检查并插入数据：加载后需要确认数据正确性，然后插入主数据库。

（2）容量和增长预测

    数据库的容量受到存储硬件的限制，数据库的数据最终存储在磁盘中，**磁盘的大小**是数据库容量的硬性限制。**普通硬盘（HDD）**：容量大但速度较慢，适合归档数据。**固态硬盘（SSD）**：容量相对较小，但速度快，适合高性能需求的主数据库。
    **案例**：一个网站需要存储所有订单信息，预计每天会有 10,000 个订单，每秒有 100 个用户请求查看自己的订单，订单数量持续增加，每年会新增 365 万条记录。如果数据库容量固定（盒子不能扩展），需要采取措施：
    定期**归档历史订单**，比如将一年前的订单移到另一个数据库。定期**清理无用数据**，比如删除 5 年前的已完成订单。如果数据库容量可以扩展（比如分布式数据库），则需要**规划增长速度**。

（3）变动数据捕获

   变动数据捕获（Change Data Capture，CDC）是指**检测**到数据的变动并确保与变动相关的信息被**适当记录**的过程。在一个简化的CDC语境中，一台计算机系统的数据可能在前一个时间点发生了改变，在第二台计算机系统里需要反映这一变化。与通过网络复制整个数据库的数据来反映一些微小的变化不同，CDC只发送变化的内容（增量信息），接收系统就可以进行恰当的更新。

    **CDC** 就像是一个监控工具，它在数据发生变化时能立刻察觉到，并把这个变化告诉其他系统。CDC 只关注数据的变化部分，节省了大量的时间和存储空间。

如何捕捉数据变化？

• 一种方法是通过版本控制：给数据加个标记（比如更新时间戳、版本号等），系统通过这些标记来判断数据是否发生了变化。
• 另一种方法是通过读取日志：数据库记录所有的操作（比如插入、更新、删除），CDC 就可以通过读取这些操作日志来识别和捕捉数据变化。

MySQL 是一个数据库管理系统，而 CDC 是一种通过数据库日志或其他方式捕获数据变化的技术，CDC并不是工具，MySQL 可以实现 CDC 功能：

外部工具实现 CDC：

• 虽然 MySQL 自带一些日志功能，但在实际的生产环境中，许多工具或服务会帮助实现更完善的 CDC。
  • Debezium：一个开源工具，可以实时捕获 MySQL 的数据变动并通过 Kafka 等消息队列同步到其他系统。（待开发）
  • Maxwell：一个 MySQL 数据变动捕获工具，通过读取 MySQL binlog 将数据变动发布到 Kafka 或其他目标系统。（待开发）

（4）数据清除

   数据长期存储会占用空间并影响性能，因此需要定期存档或清除。清除（Purging）指永久删除不再有价值的数据。这样可以降低存储成本和数据被滥用的风险。过期数据从监管角度也被视为不必要的负担。

（5）数据复制

数据复制（Replication）指在多个存储设备上保存相同数据，用于提高系统可用性和负载均衡。主要分为两种模式：

1）主动复制：所有副本都可以创建和存储数据，无主副本之分。 2）被动复制：先在主副本创建数据，再同步到其他副本。

复制可以通过两种方式扩展： 1）水平扩展：增加副本数量 2）垂直扩展：将副本分布在不同地理位置

复制对用户是透明的，他们无法知道正在使用哪个副本。复制主要通过两种方式实现：

1）镜像：主库更新立即同步到辅助库 2）日志传送：辅助库定期接收并应用主库的事务日志

特性	数据复制（Replication）	数据归档（Archiving）
目的	保证数据一致性、提高系统可用性、负载均衡	保留历史数据，减轻活跃数据库的负担，降低成本
数据访问	数据副本是实时可用的，通常是在线的，支持高频次访问	归档的数据不常访问，通常是离线存储的，不频繁使用
数据更新	多个副本之间的数据保持同步，支持更新操作	一旦数据归档，通常不再更新
性能影响	复制增加网络带宽、存储需求和管理复杂度	归档减少主数据库存储和操作负担，提升性能

（6）韧性与恢复

  数据库韧性（Resiliency）是衡量系统对错误条件容忍度的指标。如果一个系统能够容忍高级别的处理错误，并且仍能像预期的那样工作，那么它就具有很强的韧性。如果应用程序一碰到意外条件就崩溃，那么系统就没有韧性。如果数据库可以检测异常，并提前终止或从通用的错误处理办法（如失控查询）中自动恢复，则认为它具有韧性。   

3种恢复类型，如何快速恢复：

1）立即恢复（Immediate Recovery）。有些问题有时需要通过设计来解决的。例如，可以通过预判并自动解决问题，切换到备用系统

实现方式：

1. 故障转移（Failover）：
   • 配置主-从架构或多副本架构（如 MySQL 主从复制或 MongoDB 的 Replica Set）。
   • 使用负载均衡器和自动故障检测工具（如 Keepalived、HAProxy），当主节点宕机时自动切换到备用节点。
2. 自动化恢复机制：
   • 部署监控系统（如 Prometheus、Zabbix）实时检测数据库健康状态。
   • 检测到数据库异常后，触发脚本或预定义规则自动重启服务或清理失控任务。
3. 冗余架构（Redundant Architecture）：
   • 利用分布式数据库架构（如 Apache Cassandra、CockroachDB），确保数据多副本存储，即使一个节点发生故障，其他节点可以立即接管。
4. 预判并自动解决：
   • 查询优化：对可能导致失控的查询设置时间限制（如 MySQL 的 max_execution_time）。
   • 连接池管理：配置连接池上限，防止数据库超载。

2）关键恢复（Critical Recovery）。它是指尽快恢复以尽量减少业务延迟或业务中断的恢复计划。尽快恢复核心业务，最小化业务中断时间。

实现方式：

1. 备份与恢复策略：
   • 定期备份：启用增量备份和全量备份（如 MySQL 的 mysqldump 或 Percona XtraBackup）。
   • 使用工具如 AWS RDS 快速恢复到最近的备份点。
2. 事务日志恢复：
   • 启用事务日志（如 MySQL 的 binlog、PostgreSQL 的 WAL），在发生崩溃后通过重放日志恢复数据库到最近状态。
3. 灾难恢复计划（DRP）：
   • 设置异地容灾中心（如异地多活架构）。
   • 利用云服务（如 AWS Aurora 或 Azure SQL Database）进行快速恢复，保证业务快速切换到云端。
4. 缩短恢复时间目标（RTO）：
   • 使用工具（如 Percona Cluster、Vitess）以秒级恢复数据库服务。
   • 缩短备份文件的读取和恢复时间，如将备份存储在 SSD 上。

3）非关键恢复（Non-critical Recovery）。它是指该类业务可以延迟恢复，直到更关键的系统恢复完毕。在优先恢复核心系统后，逐步恢复非关键业务，减少恢复过程中资源的竞争。

实现方式：

1. 分级恢复：
   • 使用应用优先级分类系统（如核心交易系统为高优先级，统计报表系统为低优先级）。
   • 利用分级计划，先恢复高优先级系统，延迟低优先级系统恢复。
2. 冷备和归档恢复：
   • 对非关键数据采用冷备方式存储在更经济的介质（如云归档服务、磁带存储）。
   • 利用分阶段恢复策略，逐步加载数据回主系统。
3. 弹性计算：
   • 在非关键业务中使用容器化技术（如 Docker 和 Kubernetes）部署服务，按需扩展资源，减少业务恢复对关键资源的依赖。
4. 监控和通知：
   • 配置监控系统对非关键业务进行监控，一旦核心业务恢复完成，可以自动调度恢复非关键业务。

1.5 数据库存储的度量指标

1）数据库类型的数量。关系型数据库、非关系型数据库、时序数据库，类型的数量可以帮助理解系统的复杂性和多样性。 2）汇总交易统计。指事务的数量、成功率、失败率等。此指标有助于了解数据库系统的整体负载和活动水平。 3）容量指标。数据库总容量、表、索引和数据文件的大小。 4）已使用存储的数量。衡量当前数据库中已使用的存储空间的数量，与总存储容量进行对比，可以了解剩余的可用存储空间。 5）存储容器的数量。 6）数据对象中已提交和未提交块或页的数量。未提交的块通常属于事务的一部分，只有在事务提交后才会变成已提交的块。 7）数据队列。衡量数据库中排队的操作或任务数量。数据库系统在进行大量并发操作时，可能会有数据操作被排队等待处理。此指标反映了系统的并发处理能力。 8）存储服务使用情况。衡量数据库系统对存储服务的使用情况，可能包括磁盘、云存储等。此指标帮助了解数据库如何使用存储资源，以及是否达到了存储资源的瓶颈。 9）对存储服务提出的请求数量。例如，数据读写操作或对存储设备进行请求的次数。这个指标有助于了解存储服务的使用负载。 10）对使用服务的应用程序性能的改进。

性能度量评估指标，包括： 1）事务频率和数量。衡量单位时间内数据库系统处理的事务数量。事务频率高通常意味着数据库系统的负载较大，系统的并发处理能力较强。 2）查询性能。衡量数据库查询的执行效率，通常通过查询响应时间或查询执行的吞吐量来衡量。优化查询性能是提升数据库效率的重要方式。 3）API服务性能。衡量数据库提供的API服务的响应时间、吞吐量、可用性等指标。数据库系统通常通过API向应用程序提供数据访问，API性能直接影响应用程序的响应速度。

操作度量指标，包括： 1）有关数据检索时间的汇总统计。 2）备份的大小。 3）数据质量评估。 4）可用性。

服务度量指标，包括： 1）按类型的问题提交、解决和升级数量。 2）问题解决时间。