数据库概念
关系型数据库
- 关系数据库提供了一个通用接口，使用户可以使用使用 编写的命令或查询从数据库读取和写入数据。
- 关系数据库由一个或多个表格组成，表格由与电子表格相似的列和行组成。
- 以行列形式存储数据，行包含一个条目的所有信息，列是分离不同数据点的属性
- 架构固定，输入数据前要先锁定列
- 查询方式是SQL语句
- 支持垂直扩展属性
- 每一张表都有主键， 通过引用记录的主键，表中的一条记录可以与另一个表中的记录相关。这个指针或引用被称为外键。
- 关系数据库可以分为联机事务处理OLTP 和 联机分析处理OLAP，具体取决于表的组织方式以及应用程序如何使用关系数据库。
- OLTP - 经常编写和更改数据(例如数据输入和 电子商务)的面向事务的应用程序，OLTP事务频繁发生但相对简单
- OLAP - 应用于数据仓库的领域，指的是报告或分析大型数据集。OLAP事务 的发生频率要低得多，但要复杂得多
- 大型应用程序经常混合使用OLTP和OLAP数据库。一个数据库作为其OLTP事务的主生产 数据库，另一个数据库作为他们的数据仓库为OLAP。
- 数据库包括： MySQL，PostgreSQL，Microsoft SQL Server和Oracle
- SQL 数据库的默认端口
- Oracle： 1521
- MS SQL ： 1433
- MySQL ： 3306
DB2： 5000
数据仓库
- 数据仓库为可以来自一个或多个源的数据的中央储存库。
- 此数据存储库通常是专用类型的关系数据库，可用于通过OLAP进行报告和分析，组织通常使用数据仓库来编译报告并使用高度复杂 的查询搜索数据库。
NoSQL数据库
- 相比关系型数据库，NoSQL更加简单易用，更加灵活，
- 传统数据库在单台服务器外扩展成本极高，而NoSQL可以在商用硬件上实现水平伸缩性
- 使用众多模型（如键值对、文档和图表）中的一种来存储数据
- 数据结构
- 集合 Collection ： 相当于表
- 文档 Document： 相当于行
- 键值 Key Value Pairs： 相当于列
- 动态的架构，行无需包含与每个列对应的数据
- 查询更关注文档集合
- 支持水平扩展属性
- NoSQL的其他特性
- 对于某些应用程序可以替代关系型数据库
- 支持以高可用性处理大量数据
- 可以形成一个包含不同实施方案和数据模型的大类别
- 具备分布式容错的能力
- NoSQL 可以提高灵活性、可用性、扩展性和高性能
- 主要的NoSQL数据库包括
- EC2： Cassandra、Hbase、Redis、MongoDB、Couchbase、Riak
- AWS托管：DynamoDB、ElastiCache(Redis)、Elastic Map Reduce（HBase）
- NoSQL 数据库常用端口
- MongoDB：27017
- Redis：6379
- Memcached：11211
- 采用NoSQL主要考虑几个限制
- 应用程序的事务支持
- ACID合规（ACID=原子性、一致性、隔离性和持久性）
- 联接需求
- SQL需求
- 常见场景：
- 排行榜、快速导入点击流或日志数据、购物车临时数据需求、热表、元数据或查找表、会话数据
数据库选择
- 将非关系型数据放在NoSQL中（如DynamoDB）
- 将技术与工作负载匹配，从各种关系型数据库， NoSQL数据库，数据仓库和其他针对搜索优化的数据存储中选择。
- 数据库选择要考虑的事项：
- 读取和写入要求
- 总存储容量
- 典型对象大小及其访问特性
- 持久性需求
- 延迟要求
- 同时支持的最大用户量
- 查询特性
- 所需完整性控制强度
Amazon RDS存储关系型数据
RDS综述
- RDS是一个全托管的数据库
- 开发人员可以专注于查询结构和查询优化
- 减轻运维负担包括数据库迁移、备份和恢复、修补、软件升级、存储升级、频繁服务器升级、硬件故障处理
- RDS可以通过公用的客户端软件连接并执行SQL操作，包括使用相同的工具来查询，分析，修改和管理数据库。例如，当前的提取，转换， 加载(ETL)工具和报告工具
RDS 数据库实例
- 数据库实例是云上专用网段中部署的隔离的数据库环境
- 每个实例运行了一个商业或者开源的数据库引擎，包括MySQL，PostgreSQL，MS SQL，Oracle，MariaDB以及AWS Aurora 六种。
- 可以通过API创建和管理RDS实例
- 可以利用AWS工具或者数据库引擎本身的工具将数据从本地迁移到AWS上
- 每个用户默认最多托管40个RDS数据库
- 每个实例上只能运行1个Oracle和30个MS SQL数据库，其余没有限制
- RDS支持预留实例，且只支持区域预留，可用于多可用区部署和只读副本
- 使用Parameter Group 对数据库参数进行设置
存储选项
- RDS构建在EBS上
- 通过预配置支持最大16TB （MSSQL） - 32TB，32000 IOPS - 40000 IOPS
- 支持HDD，通用SSD和预配置IOPS SSD 三种类型
备份与恢复
- 自动备份
- 备份存储在S3中
- RDS备份整个数据库实例，为它创建存储卷快照
- 自动备份建期间IO会挂起3-5秒钟，但对高可用部署的数据库不受影响
- 自动备份默认开启且保留1天（API或CLI创建）或者7天（控制台创建），最大可保留35天，自动删除
- 自动备份支持时间点恢复功能，最小间隔为5分钟
- 删除实例时所有自动备份都会被删除
- 可以禁用自动备份，但是非常不建议。 禁用自动备份后，即使再重新启用，被禁用的期间将不可恢复。
- 手动数据库快照
- 快照存储在S3中
- 随时手工对数据库进行快照
- 默认永久保留除非手工明确删除
- 使用多可用区部署可以最小化快照的影响，因为快照可以从备用数据库发起，只是RPO会有一定影响
- 恢复
- 所有RDS数据库恢复都会创建一个全新的数据库实例
- 还原时只会关联默认的数据库参数和安全组参数被关联，需要重新手工设置
- 不支持将VPC内的数据恢复到VPC外部
多可用区的高可用
- 高可用是传统关系型数据库部署的难点
- 利用RDS可以轻松实现，实现最短几分钟的RPO和RTO要求
- 开启多可用区部署后，自动在不同可用区创建备用RDS实例，并利用数据库实例URL endpoint来实现DNS寻址
- RDS 数据会同步复制到从数据库，复制本身产生的数据传输不收费
- 支持故障自动切换和手动转移，转移时间为1-2分钟
- 跨可用区部署后由于数据同步复制，会有一定的性能影响，备份是也会有更长的延迟
- 从数据库不能用作只读副本提升IO
规模扩大或缩小
- RDS支持垂直扩展
- 数据库实例的资源大小可以随需求决定，支持1-32 vCPU，1-244GB Memory，用户可以更改实例大小，RDS会自动完成数据迁移
- RDS采用数据库参数和数据库选项对数据库实例进行配置，每次更改都需要重启实例
- SQL Server不支持存储扩展
- 可以通过数据库分片技术实现有限度的水平扩展
- RDS 支持实时配置更多的存储而无需停机
- RDS IOPS（除SQL Server）还可以扩展数据库实例的吞吐量，1000 到 30000 IOPS分别对应100GB 到 6TB的存储空间
- 可以在RDS前端的EC2选择放置Redis 缓存服务，EC2 首选自我管理型缓存解决方案
只读副本扩展
- RDS允许从主数据库创建一个或多个只读副本来分流读取事务
- 读取繁重的任务
- 当主数据库不可用时处理读取操作
- 离线数据分析场景
- MySQL、PostgreSQL、MariaDB和Aurora支持只读副本
- 要使用只读副本，需要先开启自动备份功能
- 只读副本是异步的
- 可以为只读副本创建只读副本，每个数据库最多创建5个只读副本，Aurora最多15个
- 可以在多可用区部署只读副本，每个只读副本都有自己的URL Endpoint
- 只读副本可以被提升为独立的数据库，但是不能用来做灾备
RDS安全性
- IAM权限管理
- 采用IAM用户来对数据库进行操作
- AMI可以控制每一个单独的用户对RDS操作的权限
- RDS初次创建时会基于AWS开发人员账户创建一个有主用账户并成为数据库根管理员权限，他可以单独分配给不同数据库实例的主用户名和密码
- 可以使用主用户凭证连接数据库
- 接收RDS重要事件通知
- 网络隔离
- RDS实例需要创建在VPC的私有子网中
- 可以使用IPSec ×××网关将RDS连接到现有的企业内部的IT基础架构中
- 在多可用区部署时，可以创建全局子网组，这样在创建RDS时只需要制定可用区即可从全局子网组中分配响应的子网和IP地址
- 所有从VPC外部的EC2或者Internet对RDS的访问，都必须经过×××或堡垒机实现，并且堡垒机需要充当SSH Bastion的角色
- 自动补丁
- RDS软件始终与最新的补丁保持同步
- 默认首周需要30分钟进行维护
- 建议每一周需要计划30分钟的维护时间以完成补丁操作
- 一般仅有规模计算相关的补丁需要脱机执行，通常每几个月发生一次
- RDS增强型监控
- 增强型监控能够捕获 RDS 实例的系统级指标，如 CPU、内存、文件系统和磁盘 I/O 等
- 最多可以查看所有指标在 1 个小时之前的性能值，粒度最高为 1 秒
- RDS 增强型监控提供了一系列将以 JSON 有效负载形式发送到您的 CloudWatch Logs 账户的指标。JSON 有效负载会按照上次为 RDS 实例配置的粒度进行发送。
- 增强型监控在 CloudWatch Logs 中配置的默认保留期是 30 天。
- RDS采用四层安全模型
- RDS安全组
- 用于控制传入和传出数据库实例的流量，默认情况下不能进行网络访问，但可以通过ACL设置允许特定IP端口进行访问。
- 数据库安全组
- 控制对VPC外部数据库实例的访问
- 默认情况下RDS必须在VPC内才能启动，但是仍然存在VPC外部托管RDS的情况
- 数据库安全组仅适用于入站流量，目前不允许数据库安全组有出站流量。
- 可以使用RDS API 或 AWS 控制台的 RDS部分创建数据库安全组
- 安全组来控制对RDS的数据库实例访问， 类似于EC2安全组，但不可以互换
- 默认拒绝所有访问，所有允许权限都需要显式声明
- 可以授权IP或安全组访问
- 仅允许访问数据库服务器端口
- 数据库安全组无需指定目标端口，默认由实例自动定义
- 可以在不重启数据库实例的情况下对安全组策略进行更新
- RDS安全组
AWS Redshift
概念
- 完全托管的PB级数据仓库服务
- 基于SQL-based 设计的关系型数据库
- 基于行业标准的PostgreSQL，因此大多数现有的SQL客户端应用程序只能进行极少的更改。
- 针对OLAP设计的高性能数据分析和报告
- Redshift使您可以使用标准SQL命令快速查询结构化数据的功能，以支持在大型数据集上进 行交互式查询。
- 使用柱状存储，数据压缩和区域映射等技术减少查询所需的IO量。
- 通过ODBC或JDBC连接与各种数据加载，报告，数据挖掘和分 析工具集成。
- Redshift负责管理设置，操作和扩展数据仓库所需的工作，从设置基础架构容量到自动执 行备份和修补等持续管理任务。
- Redshift会自动监控您的节点和驱动器，以帮助从故障中恢复。
集群
- 集群由一个领导者节点和多个计算节点组成
- 支持从160GB - 1PB甚至更大的
- 最多支持128个计算节点
- Redshift集群不能使用竞价实例
- 仅能在一个可用区部署
- 客户端只与领导者节点交互，计算节点对外部是完全透明的
- Redshift目前支持6种节点类型，分为两大类
- 密集计算型 - 最大支持SSD 326TB
- 密集存储型 - 最大支持HDD 2PB
- 每个集群都包含一个或多个数据库，并且分布在各个计算节点中，每个节点的数据库数据都是同步的
- 计算节点的磁盘存储会分片，切片通常在2-16之间，所有节点都会参与并行查询。
- 通常计算节点越多，查询性能越强
- 可以随时调整节点大小和类型，调整后都会创建一个新的集群并将数据迁移过去，调整期间数据库只读。
表设计
- 每个Redshift表都可以指定表名称、列及其数据类型等。
- 数据类型：
- 常见数据类型包括： INTEGER，DECIMAL和 DOUBLE，文本数据类型(如CHAR和VARCHAR)以及日期数据类型(如DATE和TIMESTAMP)
- 压缩编码
- 首次将数据加载入新表时，自动对数据进行采样并且为每列选择最佳压缩方案
- 分发策略
- 创建表格时指定如何在集群的节点进行切片进行分发，以及使用哪种查询模式
- 分发风格对查询性能，存储要求，数据加载和维护影响很大
- EVEN 分发： 默认，对数据以统一方式进行切片和分发
- Key 分发：基于某一列的值进行分发，匹配的值会存储在一起
- All 分发： 将整个表完整的分发到每个节点
- 排序Key
- 在创建表时指定一个或多个列作为排序key，这样在处理一定范围的查询时可以跳过大量的块
- 表格的排序Key可以复合和交错，查询使用前缀可以让复合排序的查询更加高效
数据加载
- 使用标准的SQL Intert/update进行表的创建和修改记录
- 在Redshift中使用COPY命令是一个更高效的方式，如从S3或者DynamoDB中进行批量数据加载
- 大量数据加载完成后，建议使用VACUUM命令重新组织数据并用ANALYZE来统计更新表格统计信息
- UPLOUD命令可以从Redshift中导出数据
查询数据
- 也是用标准的SQL Select命令进行查询
- 对于多用户的大型Redshift，可以使用WLM工作负载管理对查询进行排队，WLM可以对每个队列设置并发级别。
- 使用Redshift Spectrum
- 可以对 Amazon S3 中 EB 级非结构化数据运行查询，而无需进行加载或 ETL 操作。
- 当您发布查询时，查询会进入 Amazon Redshift SQL 终端节点，该终端节点会生成查询方案并对其进行优化。
- Amazon Redshift 会确定哪些数据存储在本地以及哪些数据存储在 Amazon S3 中，然后生成一种方案来尽可能减少需要读取的 + Amazon S3 数据量，从共享资源池中请求 Redshift Spectrum 工作线程来读取和处理 Amazon S3 中的数据。
- Redshift Spectrum 可根据需要扩展到数千个实例
备份快照
- 自动快照到期后会自动删除，设置时间为1-35天
- 支持跨区域快照，手工快照可跨区域甚至跨账户存储，需要手工明确删除
- Redshift快照和备份数据存储在S3中
- 免费的快照存储空间与当前节点容量相当，所以需要及时清除不需要的快照文件
安全
- 安全级别
- 基础架构级别安全，使用IAM来限制用户的可执行操作及生命周期
- 网络级别安全， 将Redshift部署到私有的VPC中（必须），并利用ACL和安全组限制细粒度网络访问
- 数据库级别安全，可以通过Redshift的主用户名和密码创建更多的用户并给他们相应授权
- 数据加密存储
- 数据加密是可选项，利用硬件随机生成的AES256密钥对每个数据块进行加密，但加密影响性能
- 多种静态加密技术，符合HIPAA和PCI DSS合规要求
- KMS
- HSM
- Redshift Enhanced VPC Routing
- 强制将所有的COPY和UNLOAD流量指定走AWS VPC 内部
- 若不开启，则所有流量默认走Internet，包括从AWS内部读取
- 数据加密传输
- 采用硬件加速的SSL连接与S3或者DynamoDB进行通信
- 可以在客户端上安装SSL证书pem公钥文件实现对Redshift 服务器的连接和管理
- 支持椭圆曲线HCDHE协议提供更强大的密码套件确保SSL的私密性
- 同时也可以启用Perfect Forward Secrecy使用短暂会话密钥防止密钥泄露
- 记录所有的SQL操作信息用于监控和审计，包括连接尝试、查询和对数据库的更改等操作
- 在维护窗口中进行自动补丁更新
例外
- 不适用于大规模对少数对象的读写操作，这种场景需要考虑Aurora 或者RDS
DynamoDB
主要特性
- 是NoSQL的的托管版本
- 低延迟 - 基于SSD，延迟小于10ms
- 大规模无缝可扩展 - 无表大小和吞吐限制、可针对存储和吞吐量进行实时重新分区
- 性能可预测 - 预配置吞吐量模型
- 持久性和可用性 - 自动执行区域内三向复制，确保一致性、仅限磁盘写入
- 安全性- 成熟的加密方案对用户身份进行验证
- 零管理- 完全托管的NoSQL服务
- 同时连接和访问多个NoSQL存储（如RDS、S3、MongoDB、Hbase等），对组合数据集进行复杂分析
- 通过在多个分区上自动分配表的数据和流量提供一致的性能级别，其性能是以读写容量的吞吐量级衡量的
- 根据实际需求可以随时调整读取和写入容量，DynamoDB会自动添加或删除基础架构或调整内部分区，默认最大支持20000个读取和20000个写入容量
- DynamoDB 按照存储数据大小和读写能力进行收费
- 应用场景
- 支持与Amazon EMR集成
- 支持即插即用的Hadoop分析
- 支持储存会话数据
数据模型
- 没有架构，一个表有多个项目，项目具有可变属性
- 数据类型
- 对每一个主键及其属性都必须指定一个数据类型
- Scalar数据类型 - 表示某一个值的类型， 包括字符串、数值、二进制、布尔值、空
- Set数据类型 - 表示某一个list的类型，包括 字符串set，数值set和二进制set
- Document 数据类型- 表示多个嵌套的属性，类似于JSON文件结构，包括List和Map两种文档类型
- List - 用于储存不同数据类型的属性的有序列表
- Map - 每个可用于Key/Value的无序列表，可以用来表示任何JSON对象结构
- 对每一个主键及其属性都必须指定一个数据类型
- 主键
- 主键是每个项目的唯一标识也是唯一强制属性，DB通过它来进行GET/PUT
- 每个主键属性必须是字符串、数字或二进制。
- 两种类型的主键
- 分区键 - 一个属性一个分区哈希值组成，用于构建无序散列索引
- 分区+排序键 - 两个属性组成，由分区和排序组合起来作为唯一标识
- DynamoDB 调用包头类型
- host
- x-amz-date
- x-amz-target
- content-type
- 预置容量
- DynamoDB需要调配一定数量的读写容量来处理预期工作负载
- 选择适宜的容量已持续的提供低延迟的响应时间，可以通过Updatetable指令缩放。
- 读操作每4K为一个单位容量，写操作每1K为一个单位容量。
- 最终一致性 - 1个单位容量可以读写两次
- 强一致性 - 1个单位容量可以读写一次
- 事务一致性 - 2个单位容量才能读写一次
- 可以CloudWatch 监控DynamoDB容量并制定扩展决策。
- 二级索引
- 只有使用分区+排序主键时，可以定义一个或多个二级索引
- 支持全局二级索引和本地二级索引等灵活方法来查询非主键值
- 全局二级索引索引整个分区+排序键的值
- 本地二级索引索引相同分区键但不同排序键的值
- 主键分为单属性分区或复合属性分区
- 单分区以UserID为唯一标识
- 复合分区以UserID（分区键）和TimeStamp（排序键）进行组合标识一对一关联关系，支持交叉检索功能
- 当数据集大小和预配置容量增加时会发生自动分区
- 只支持一个本地二级索引，但可以创建多个全局二级索引
- 项目大小不能超过400KB，必须包含属性名称和属性值长度两个二进制长度
DynamoDB属性
- 一致性
- AWS同一区域内的多个可用区之间自动复制每个DynamoDB表
- 读取一致性：通过控制成功写入或更新的读取操作的方式和时间，指定最终一致性或强一致性读取，默认是最终一致性读取
- 最终一次性读取： 数据副本的一致性能够需要1秒实现，仅验证数据一致而不会验证写入完成，所以可能读取的是旧数据
- 强一致性读取：读取时验证写入成功完成，并且确保数据读取的一致性，在网络延迟或者中断的情况下可能不可用。
- 批量操作
- 可以通过单个操作执行最多25个项目的创建或更新
- 项目搜索
- 查询 - 用于仅限主键属性的查找和索引操作，用排序键值可以优化搜索结果，结果会按主键排序，
- 扫描- 会返回每个项目的所有属性，返回限制1MB
- 每个查询或扫描结果返回最多1MB，若超过则需要对增量结果进行翻页
- 缩放和分区
- DynamoDB可以无限数量的扩展并且提供一致的低延迟性能
- 通过分区来进行水平扩展
- 好的程序设计需要考虑表的分区结构，以平均分配读写事务，实现低延迟处理
- 随着表中项目的增加，可以不断拆分现有分区来添加额外分区
- 预置吞吐量将在个分区之间平均分配，且不可跨区共享
- 一个分区可容纳10GB数据和最多3000个读取容量以及1000个写入容量，对于未充分利用的容量分区，可以用于处理突发流量
- AWS DynamoDB Stream
- 获取DynamoDB最近24小时内的项目修改列表用于分析和审计。
- 通过Stream中读取的活动修改日志，可以在不修改原始应用程序的情况下扩展和构建新的功能。
- 自动备份
- 需要通过AWS Data Pipeline的专用配置模板，将DynamoDB完整或增量备份到同一地区或不同地区进行备份
- DAX
- DynamoDB 数据库性能加速
- DynamoDB 自动扩展
- DynamoDB在创建时，可以指定读取和写入流量以及每个大小的平均大小来配置所需的请求容量
- 可以通过第三方工具（如 CloudFormation模板）启用 Dynamic DynamoDB 配置自动扩展和缩减表格
- 支持将扩展活动限制在一定时间段，使用上下限预置单独扩展读取和写入吞吐量
- 支持断路器，确保每次扩展和缩减活动之前检查应用程序是否正常以避免当应用程序发生问题而触发的虚假缩减活动
安全
- DynamoDB 需要与IAM服务集成，用策略最大限度控制权限。
- 所有操作都必须通过身份验证，建议使用EC2实例配置文件或角色来管理密钥
- 在数据库级别可以创建权限，以细粒度的允许或拒绝对项目和属性的访问
- 对DynamoDB的服务请求都必须包含HMAC-SHA-256的签名
- 移动端的最佳做法是使用Web身份联合与AWS安全令牌服务提供临时密钥
- DynamoDB本身不提供服务器端加密存储数据，需要存储前使用客户端或KMS加密
DynamoDB最佳实践
- 保持较小的项目大小
- 将元数据存储在DynamoDB中，将大型BLOB存储在S3中
- 按日、周、月进行Hash计算使用表来存储实践序列数据用于强制分区
- 使用有条件更新或者开放式并发控制更新（OCC）
- OCC是假定多个事务可以频繁完成且相互不会干扰
- 获取资源时无需提前锁定，提交时需要确认没有冲突的修改，若有则回滚
- 仅适用于低争用环境，从而提高吞吐量，否则反而会大大降低性能
- 避免热键和热分区
- 更加适合于无状态的服务设计
- 支持JSON对象的存储
Amazon Aurora
概述
- 是一种面向服务的架构交付的关系型数据库，是mySQL的托管版本，还兼容PostgreSQL
- 速度是MySQL的5倍，成本是其他商用数据库的1/10
- 容量支持10GB - 64TB；每10GB一增量，仅为使用的容量付费。
- 支持Schema Changes
- 利用S3实现可扩展和高可用性，默认支持6个副本,
- 复制到3个可用区，每个可用区2个副本
- 2个以下副本丢失，不影响写入
- 3个以下副本丢失，不影响读取
- 与MySQL 5.6简易兼容 - 现有程序可正常运行，可轻松迁移，可直接导入数据文件
其他特性
- 扩展性能
- 与S3集成，可实现最多三个可用区之间6个副本的持续备份
- 将日志记录和存储层转移到可扩展的多租户服务层
- MySQL支持跨区域副本（最多5个区域）建立全球数据库，使用Read Replicate 技术， PostgreSQL不支持，跨区域DR需要手工完成
- 弹性设计
- 最多15个副本，约10ms副本滞后
- 99.99%可用
- 即时崩溃恢复（60s），故障转移30s内
- 与单一线程重放所有日志的传统数据库相当
- 在磁盘读取时重放重做记录
- 自动备份，且不会影响数据库性能
- 支持快照，并且可以跨账户共享快照，也可以跨区域共享，但是不能同时 跨账户和区域共享
- 平行的分布式异步恢复
- 缓存层可在数据库重启时继续使用，从而改善读取响应
- 支持KMS加密，但必须在创建数据库时即开启加密选项
- 主数据库出现故障时，只读副本可以实现即时提升为主数据库
- 支持Aurora Serverless
- 适用于 Amazon Aurora 的 MySQL 兼容版的按需 autoscaling 配置。
- Aurora Serverless 数据库集群会根据您应用程序的需求自动启动、关闭以及扩展或缩减容量。
- Aurora Serverless 是简单且更具成本效益的选择，适用于不频发的、间歇性的或不可预测的工作负载。
- Parallel Query
- Amazon Aurora Parallel Query 是一项功能，能够将单个查询的计算负载下移并分布到 Aurora 存储层中的数千个 CPU。如果不使用 Parallel Query，则对 Amazon Aurora 数据库发出的查询将全部在数据库集群的一个实例中执行；这与大多数数据库的运作方式类似。
- Parallel Query 非常适合需要新数据和良好查询性能的分析工作负载，即使在大型表上也是如此。这种类型的工作负载在本质上通常是可操作的。
好处：
- 速度更快：Parallel Query 可将分析查询的运行速度提高多达 2 个数量级。
- 操作简易性和数据新鲜度：您可以直接对 Aurora 集群中的当前事务数据发出查询。
- 同一数据库上的事务工作负载和分析工作负载：借助 Parallel Query 功能，Aurora 可以在处理并行分析查询的同时保持较高的事务吞吐量。
数据库架构示例
