(二)读写分离架构、冷热分离架构

读写分离架构

什么是读写分离结构

读写分离架构针对于数据库。数据库原本负责读写两个功能。 读写分离架构就是添加多台数据库服务器, 其中主数据库一般负责写, 从数据库一般负责读。

读写分离架构也叫做主从分离架构, 一台数据库服务器作为主服务器, 然后为这台主服务器添加冗余(从服务器)。 这样做的好处有很多, 下面优缺点提到。

架构模型

在这里插入图片描述

在这里插入图片描述

优缺点

优点

  • 可以应对更高的并发量, 读写分离,从数据库分担了主数据库的读请求。
  • 高可用性, 增加了系统的冗余, 当主数据库崩溃时, 从数据快速顶替主数据库,不影响用户体验。
  • 从数据库可以进行横向扩展,使数据库对于读具有扩展性。读请求理论上不再称为瓶颈。
  • 主数据和从数据库通过网络实现数据同步一致。

缺点

  • 硬件资源的成本增加, 运维成本增加
  • 单点写瓶颈, 写并发极高时主数据称为瓶颈
  • 数据不一致性, 数据网络同步需要时间, 用户写入后想要立即读取,可能读取不到最新更新信息。
  • 主数据库同步时崩溃会导致数据丢失。

技术案例

写情况

  • 用户使用域名访问服务器,先访问dns, dns返回一个IP地址。
  • 用IP地址进行路由访问应用服务器。访问哪一个? 先到达最外层的负载均衡服务器, 由最外层的负载均衡服务器将这个请求分发下层自己管理的某个服务器。
  • 这个服务器接收到请求, 如果这个服务器还是一个负载均衡服务器, 就重复刚刚类似的操作。
  • 如果这个服务器是一个应用服务器, 那么应用服务器对请求进行解析。
  • 如果是写请求, 就去主数据库中写入数据,将数据通过网络发送给主数据库服务器。 然后就返回写入情况, 是写入成功还是失败。对于应用服务集群来说, 应用服务器集群一层一层向上返回请求处理情况; 对于主从数据库集群来说, 主数据库要将刚刚写入的数据同步给从数据库。

在这里插入图片描述

读情况

  • 用户拿着 域名 访问应用服务器, 然后域名交给dns进行解析, 返回IP地址。
  • 浏览器用IP地址路由到对应的服务集群中。 具体访问哪一个应用服务节点, 由上层的负载均衡服务器一层

一层向下分发决定。

  • 应用服务节点拿到请求后, 对请求进行解析。 解析成功认为是读请求, 那么就直接去主从数据库集群里面的从数据库节点读取数据。 然后返回读取结果。

在这里插入图片描述

冷热分离架构

什么是冷热分离架构?

冷热分离是将数据分为冷数据和热数据。 热数据存放在内存缓存中。 冷数据放在磁盘中。 一个数据库服务器或者集群作为缓存数据库服务器, 存储热数据。 然后另一个数据库集群用来存储冷数据。

架构模型

在这里插入图片描述

优缺点

优点

  • 分担了读取的压力, 减少了从库的数量, 优化成本。
  • 利用内存存储数据, 内存的读取速度远高于磁盘IO。 提高了数据查询的效率, 优化效率。

缺点

  • 增加系统的复杂性, 增加运维成本。
  • 数据同步过程中如果数据库崩溃, 造成数据丢失和数据不一致问题。
  • 写的高并发仍然可能是系统的瓶颈。

技术案例

读数据

  • 发送请求, dns返回IP地址, 然后路由到应用服务集群, 应用服务集群再一系列分发处理将请求送到应用服务器。
  • 当解析后, 如果是读数据, 那么就看一下缓存服务器中是否有这个数据, 如果有直接返回。
  • 如果没有找到对应的数据, 就要去主从数据库集群中去读取数据。

在这里插入图片描述

写数据

  • 写入数据时是否写入到缓存数据中还是写入到主数据库中根据业务场景决定, 一般情况下直接写入到主数据库。
  • 写入到主数据库后, 主数据库有两种策略: 一种是直接同步到缓存数据库, 一种是给缓存数据库发送一个数据失效标记。 第一种的优点是高一致性, 但是高延迟。 第二种的优点是低延迟, 但是最终一致性(允许数据短暂不一致)

在这里插入图片描述

<think>嗯,用户之前问过Elasticsearch是否支持ODBC,现在又问冷热数据分离架构的详解。看来他们可能在使用Elasticsearch进行数据存储和分析,并且对数据管理优化感兴趣。冷热架构通常用于优化存储成本和性能,所以用户可能遇到了数据量增长的问题,想要了解如何有效管理不同访问频率的数据。 首先,我需要确认冷热架构的基本概念,确保自己理解正确。冷热架构指的是将高频访问的热数据存储在高速存储(如SSD)上,而低频访问的冷数据迁移到成本更低的存储(如HDD或云存储)。Elasticsearch通过节点角色分配来实现这一点。 接下来,用户可能需要具体的步骤或配置方法,比如如何设置节点角色、配置索引生命周期策略等。需要详细说明每个步骤,可能还要包括示例,比如如何定义ILM策略,如何分配属性到热、温、冷节点。 还需要注意不同版本ES的支持情况,比如7.x之后的功能变化,是否有必要提到版本差异。用户之前的问题中提到ODBC需要7.0以上,可能他们使用的版本较新,可以假设他们使用7.x或更高版本,但最好还是涵盖版本兼容性。 另外,用户可能关心这种架构的优势和挑战,比如成本节省、性能优化,以及可能的数据迁移开销。需要平衡优缺点,给出实际应用中的注意事项,比如监控和调整策略。 最后,总结应用场景,比如日志分析、电商数据等,帮助用户理解何时适用这种架构。可能还需要提到第三方工具或插件是否有助于实现更高效的管理,比如Curator,但ES现在主要推荐使用ILM,所以重点在ILM上。 需要确保回答结构清晰,分步骤解释,同时用示例和注意事项来增强实用性。避免使用过于专业的术语,但又要准确,所以需要平衡技术细节和易懂性。</think>以下是Elasticsearch(ES)冷热数据分离架构的详细解析,分步骤说明其设计原理和实现方式: --- ### 一、**冷热架构的核心目标** - **优化成本**:高频访问的“热数据”使用高性能存储(如SSD),低频访问的“冷数据”迁移到低成本存储(如HDD或云存储)。 - **平衡性能**:确保热数据的读写速度,同时降低冷数据的维护成本。 - **自动化管理**:通过生命周期策略(ILM)自动迁移数据。 --- ### 、**架构实现原理** #### 1. **节点角色划分** ES通过为节点分配不同角色实现冷热分层: - **热节点(Hot Node)** - 存储最新写入或高频访问的数据 - 配置高性能硬件(SSD、高内存) - 承担实时写入和查询负载 - **温节点(Warm Node)** - 存储近期不再频繁访问的“温数据” - 硬件配置介于热节点和冷节点之间 - **冷节点(Cold Node)** - 存储极少访问的历史数据 - 使用低成本大容量磁盘(HDD或云存储) - **冻结节点(Frozen Node,可选)** - 存储归档数据(如合规性备份) - 数据以只读形式存储,查询需先解冻 #### 2. **数据分层规则** - 通过**索引生命周期管理(ILM)**自动控制数据迁移流程: $$ \text{热阶段} \rightarrow \text{温阶段} \rightarrow \text{冷阶段} \rightarrow \text{删除阶段} $$ - 迁移触发条件:基于时间(如30天后)、文档数量或索引大小。 --- ### 三、**配置步骤示例** #### 1. **节点角色分配** 在`elasticsearch.yml`中定义节点角色: ```yaml # 热节点配置 node.roles: ["data_hot", "ingest"] # 冷节点配置 node.roles: ["data_cold"] ``` #### 2. **定义ILM策略** ```json PUT _ilm/policy/hot_cold_policy { "policy": { "phases": { "hot": { "actions": { "rollover": { "max_size": "50GB", "max_age": "7d" } } }, "warm": { "min_age": "7d", "actions": { "allocate": { "require": { "data": "warm" } } } }, "cold": { "min_age": "30d", "actions": { "allocate": { "require": { "data": "cold" } } } }, "delete": { "min_age": "365d", "actions": { "delete": {} } } } } } ``` #### 3. **创建索引模板** 关联ILM策略与索引模板: ```json PUT _index_template/logs_template { "index_patterns": ["logs-*"], "template": { "settings": { "index.lifecycle.name": "hot_cold_policy", "index.routing.allocation.require.data": "hot" } } } ``` --- ### 四、**关键特性与注意事项** #### 1. **优势** - **成本节省**:冷数据存储成本可降低50%以上(根据存储类型)。 - **查询优化**:热节点专注于实时请求,避免历史数据拖累性能。 - **扩展性**:可横向扩展冷节点存储容量,适应海量历史数据。 #### 2. **挑战** - **硬件异构**:需混合部署不同硬件类型的节点。 - **迁移延迟**:数据跨节点迁移时可能短暂影响集群性能。 - **监控需求**:需通过Kibana监控ILM执行状态和节点负载。 --- ### 五、**典型应用场景** 1. **日志分析** - 近7天日志存于热节点,供实时排查 - 历史日志归档至冷节点 2. **电商数据** - 热节点存储当天订单数据 - 冷节点存储3个月前的订单 3. **时序数据** - 热节点处理实时监控指标 - 冷节点存储历史指标供审计 --- ### 六、**版本兼容性** - **ES 6.6+**:支持基础ILM功能 - **ES 7.4+**:完整支持冷热分层和自动化迁移 - **ES 8.0+**:优化冻结层(Frozen Tier)查询性能 --- ### 总结 冷热数据分离架构通过硬件分层和自动化策略,显著降低了ES的运维成本,同时保持关键业务数据的性能。实际部署时需结合业务需求设计ILM策略,并监控数据迁移与节点负载的平衡。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值