架构设计基础设施保障IaaS存储3

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,高可用系列 2核4GB
简介: 架构设计基础设施保障IaaS存储3

8. 新一代原生数据库

  1. 新一代原生数据库 VS 云数据库
  • 更强的性能与扩展性
    云原生数据库由于原生设计, 专门为云设计的专业化存储架构, 可以支撑更大规模的数据量,关系型云原生数据库能够脱离典型的数 TB 的容量上限,达到单库数十 TB 甚至百 TB 的级别。
    云原生数据库可以利用云快速地进行水平扩展,迅速调整、提升数据库的处理能力, 能够有效应对高并发场景。
  • 更高的可用性与可靠性
    云原生数据库默认就具备多副本高可用的,数据同步、读写分离等高级特性,比如Amazon Aurora云原生数据库, 就自动包含了分布在 3 个可用区、多达 6 份的数据副本。

对于多种数据模型也有很好的支持, 除了兼容关系型数据库外,

  • 还会推出适合不同形态和查询范式的云数据库,与 NoSQL 数据库形成竞争, 比如说AWS的图数据库 Neptune,Azure Cosmos DB的NoSQL 数据库服务。
  • 低成本与易维护性
  • 大部分云原生数据库, 在存储上不需要预先设置大小, 会随着存储占用自动扩展;在计算上, 也有部分云数据库推出了无服务器版本,比如 亚马逊 的 Aurora Serverless,在面对间歇偶发性工作负载时,都能节省较多的成本。
  1. 阿里云PolarDB

阿里云 PolarDB 放弃了通用分布式数据库OLTP多路并发写的支持,采用一写多读的架构设计,存储与计算分离的技术架构,简化了分布式系统难以兼顾的理论模型,又能满足绝大多数OLTP的应用场景和性能要求。

PolarDB 的设计革新:

  1. 通过重新设计特定的文件系统来存取 Redo log 这种特定的 WAL I/O 数据。
  2. 通过高速网络和高效协议将数据库文件和 Redo log 文件放在共享存储设备上,避免了多次长路径 I/O 的重复操作,并且针对 Redolog的I/O 路径,专门设计了多副本共享存储块设备。
  1. 产品架构设计

  • 一写多读
    主节点处理读写请求,只读节点仅处理读请求。一个集群版集群包含一个主节点和最多15个只读节点。
  • 计算与存储分离
  • 计算与存储分离的设计,计算节点仅存储元数据, 存储节点负责数据文件、Redo Log等存储。
  • 共享分布式存储
    多个计算节点共享一份数据,并非每个计算节点都存储一份数据, 降低存储成本。存储节点的数据采用多副本形式,确保数据的可靠性,并通过Parallel-Raft协议保证数据一致性。基于全新设计的分布式块存储和文件系统,存储容量可以在线平滑扩展。
  1. POLARDB 2.0 vs POLARDB 1.0

PolarDB-X 1.0 是基于DRDS + RDS 的分布式云数据库服务, 产品的特征是采用 Share-Nothing 架构、以解决存储扩展性为出发点、提供面向用户的产品化交付能力。

PolarDB-X 2.0 主要是解决企业的各种复杂需求:

  1. 在功能性方面, 既要保障SQL通用性, 又要具备NoSQL的扩展性;既要高并发, 又要支持实时复杂分析。
  2. 企业的历史沉淀数据是一大痛点, 要以最少的成本保障数据能够顺利稳定的迁移, 并且不影响现有服务的稳定性。
  3. 各种应用对GIS数据的处理需求会越来越旺盛,使用开源版本GIS性能、功能无法满足,需要有一个功能强大的存储介质。
  4. 海量数据的运维管理, 高级DBA非常欠缺,在维护方面需要高昂的成本。

针对以上问题, POLARDB2.0应运而生,不但完全继承了1.0的架构体系,同时兼容了另外两个流行数据库Oracle与PostgreSQL。POLARDBv2.0forOracle,高度兼容Oracle;POLARDBv2.0 for PostgreSQL,完全兼容PostgreSQL。

9 阿里云PolarDB生产最佳实践

  1. 创建PolarDB-X 2.0实例

创建实例一定要选择专有的网络和交换机, 注意可用区要匹配正确。

创建好专有网络和交换机

  1. 配置外网
  • 设置白名单

这里为便于测试,允许所有外网地址连入, 实际使用当中, 应设置为指定的IP。
  • 申请外网连接地址

如果是内部虚拟机, 通过vpc内部网络接入, 要选择内网地址。
  1. 客户端连接

外网接入测试:

(如果不能连接出现超时, 可以尝试再添加只读实例, 还是不行的话, 可以提请工单请后台人员处理)

如果应用服务连接, 直接修改application.yml中的数据库连接配置即可。

  1. 分区的使用

根据用户标识与时间字段相结合作为拆分键,并按照一周七天进行分表:

CREATE TABLE user_log (
  userId INT(11) NOT NULL,
  name VARCHAR(64) NOT NULL,
  operation VARCHAR(128) DEFAULT NULL,
  actionDate DATE DEFAULT NULL
) DBPARTITION BY HASH(userId) TBPARTITION BY WEEK(actionDate) TBPARTITIONS 7

PolarDB-X将拆分键值通过拆分函数计算得到一个计算结果,然后根据这个结果将数据分拆到私有定制RDS实例上。

创建完成之后, 可以看到对应的信息:

  1. 如何配置分片数

在实际应用中, 经常会面临分库分表的场景, PolarDB-X建议单个物理分表的容量不超过500万行数据。通常可以预估1~2年内的数据增长量,用估算出的总数据量除以总的物理分库数,再除以建议的单个物理分表的最大数据量(即500万),即可得出每个物理分库上需要创建的物理分表数。

计算公式:

物理分库上的物理分表数=向上取整(估算的总数据量/(私有定制RDS实例数 x 8)/ 5,000,000)

示例:

假设预估一张表在2年后的总数据量约为1亿行,如果已购买了2个私有定制RDS实例,那么按照分片数公式进行如下计算:

物理分库上的物理分表数= CEILING(100,000,000 / ( 2 * 8 ) / 5,000,000) = CEILING(1.25) = 2

结果为2,那么需要在每个物理分库上再创建2张物理分表。

  1. 连接池配置

在实际生产当中, 官方推荐使用Druid连接池(最低要求版本1.1.11)

Druid与Spring的集成配置示例:

 <bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource" init-method="init" destroy-method="close">
        <property name="driverClassName" value="com.mysql.jdbc.Driver" />
        <!-- 基本属性 URL、user、password -->
        <property name="url" value="jdbc:mysql://ip:port/db?autoReconnect=true&rewriteBatchedStatements=true&socketTimeout=30000&connectTimeout=3000" />
        <property name="username" value="root" />
        <property name="password" value="123456" />
        <!-- 配置初始化大小、最小、最大 -->
        <property name="maxActive" value="20" />
        <property name="initialSize" value="3" />
        <property name="minIdle" value="3" />
        <!-- maxWait 获取连接等待超时的时间 -->
        <property name="maxWait" value="60000" />
        <!-- timeBetweenEvictionRunsMillis 间隔多久才进行一次检测,检测需要关闭的空闲连接,单位是毫秒 -->
        <property name="timeBetweenEvictionRunsMillis" value="60000" />
        <!-- minEvictableIdleTimeMillis 一个连接在池中最小空闲的时间,单位是毫秒-->
        <property name="minEvictableIdleTimeMillis" value="300000" />
        <!-- 检测连接是否可用的 SQL -->
        <property name="validationQuery" value="select 'z' from dual" />
        <!-- 是否开启空闲连接检查 -->
        <property name="testWhileIdle" value="true" />
        <!-- 是否在获取连接前检查连接状态 -->
        <property name="testOnBorrow" value="false" />
        <!-- 是否在归还连接时检查连接状态 -->
        <property name="testOnReturn" value="false" />
        <!-- 是否在固定时间关闭连接。此参数默认可以不加,但是增加此参数可以均衡后端服务节点参数 -->
        <property name="phyTimeoutMillis" value="1800000" />
        <!-- 是否在固定SQL使用次数之后关闭连接,此参数默认可以不加,但是增加此参数可以均衡后端服务节点参数-->
        <property name="phyMaxUseCount" value="10000" />
    </bean>
  1. 如何平滑扩容

首先判断是否需要扩容:

  1. CPU 及 IOPS 指标

如果发现任何一个指标长期保持在80%以上, 并且通过优化手段也无法解决, 那么可以考虑扩容。
  1. 磁盘空间

当数据空间将要或预期要超出磁盘容量时,可以通过扩容的方式将数据分散到多个 RDS。
  1. 扩容前注意事项
  • 如果需要新增5个或5个以上 RDS 实例,需要事先提工单,以防平台后端迁移资源不足造成迁移不成功。
  • 源 RDS 实例扩容过程中会有读压力,尽量在低负载时操作。
  • 扩容期间请勿在控制台提交 DDL 任务或连接 PolarDB-X 直接执行 DDL SQL,否则会导致扩容任务失败。
  • 扩容需要源库表中有主键,如果没有需要事先加好主键。
  • 扩容的切换动作会将读写流量切换到新增的 RDS 上,切换过程大约持续3~5分钟,建议在停业务的情况下进行切换。
  • 在执行切换前,扩容动作不会对 PolarDB-X 产生任何影响。因此在切换前都可以通过回滚来放弃本次扩容。
  1. 扩容操作步骤

扩容主要分为配置>迁移>切换>清理 四个步骤。

详情可以查阅 官方文档


目录
相关文章
|
2月前
|
JSON 前端开发 关系型数据库
如何物业管理(园区式)系统的房屋及设备设施板块?(附架构图+流程图+代码参考)
本文介绍了园区物业管理系统中房屋与设备设施管理的核心内容,涵盖设备信息、巡检、报修、保养四大功能模块,提供系统架构图、数据模型设计、关键实现建议及可落地的代码样例。通过打通资产与运维流程,实现降本增效、减少停机与投诉,助力运维数据化、智能化。
|
4月前
|
存储 机器学习/深度学习 缓存
软考软件评测师——计算机组成与体系结构(分级存储架构)
本内容全面解析了计算机存储系统的四大核心领域:虚拟存储技术、局部性原理、分级存储体系架构及存储器类型。虚拟存储通过软硬件协同扩展内存,支持动态加载与地址转换;局部性原理揭示程序运行特性,指导缓存设计优化;分级存储架构从寄存器到外存逐级扩展,平衡速度、容量与成本;存储器类型按寻址和访问方式分类,并介绍新型存储技术。最后探讨了存储系统未来优化趋势,如异构集成、智能预取和近存储计算等,为突破性能瓶颈提供了新方向。
|
2月前
|
存储 弹性计算 运维
AI 时代下阿里云基础设施的稳定性架构揭秘
十五年磨一剑,稳定性为何是今天的“命门”?
|
3月前
|
人工智能 物联网 测试技术
智能化测试基础架构:软件质量保障的新纪元
本文介绍了智能化测试基础架构的核心构成与优势。该架构融合AI、领域工程与自动化技术,包含智能测试平台、测试智能体、赋能引擎和自动化工具链四部分,能自动生成用例、调度执行、分析结果,显著提升测试效率与覆盖率。其核心优势在于实现专家经验规模化、质量前移和快速适应业务变化,助力企业构建新一代质量保障体系。建议从构建知识图谱和试点关键领域智能体起步,逐步推进测试智能化转型。
|
4月前
|
存储 关系型数据库 MySQL
成本直降30%!RDS MySQL存储自动分层实战:OSS冷热分离架构设计指南
在日均订单量超500万的场景下,MySQL数据年增200%,但访问集中在近7天(85%)。通过冷热数据分离,将历史数据迁移至OSS,实现存储成本下降48%,年省72万元。结合RDS、OSS与Redis构建分层架构,自动化管理数据生命周期,优化查询性能与资源利用率,支撑PB级数据扩展。
231 3
|
4月前
|
存储 关系型数据库 数据库
高性能云盘:一文解析RDS数据库存储架构升级
性能、成本、弹性,是客户实际使用数据库过程中关注的三个重要方面。RDS业界率先推出的高性能云盘(原通用云盘),是PaaS层和IaaS层的深度融合的技术最佳实践,通过使用不同的存储介质,为客户提供同时满足低成本、低延迟、高持久性的体验。
|
11月前
|
存储 数据采集 弹性计算
Codota的存储架构通过多种方式保障数据安全
Codota的存储架构通过多种方式保障数据安全
101 4
|
7月前
|
存储 数据采集 机器学习/深度学习
新闻聚合项目:多源异构数据的采集与存储架构
本文探讨了新闻聚合项目中数据采集的技术挑战与解决方案,指出单纯依赖抓取技术存在局限性。通过代理IP、Cookie和User-Agent的精细设置,可有效提高采集策略;但多源异构数据的清洗与存储同样关键,需结合智能化算法处理语义差异。正反方围绕技术手段的有效性和局限性展开讨论,最终强调综合运用代理技术与智能数据处理的重要性。未来,随着机器学习和自然语言处理的发展,新闻聚合将实现更高效的热点捕捉与信息传播。附带的代码示例展示了如何从多个中文新闻网站抓取数据并统计热点关键词。
273 2
新闻聚合项目:多源异构数据的采集与存储架构
|
11月前
|
存储 缓存 弹性计算
Codota的服务器存储架构
Codota的服务器存储架构
119 5
|
11月前
|
存储 缓存 弹性计算
Codota的存储架构
Codota的存储架构
118 3