【实战ES】实战 Elasticsearch：快速上手与深度实践-8.2.2成本优化与冷热数据分离

👉 点击关注不迷路
👉 点击关注不迷路
👉 点击关注不迷路

文章大纲

  • 8.2.2AWS OpenSearch Serverless 成本优化与冷热数据分离深度实践
    • 1. 成本构成分析与优化机会识别
      • 1.1 Serverless模式成本分布
      • 1.2 冷热数据特征分析
        • 数据特征矩阵
    • 2. 冷热数据分离技术实现
      • 2.1 生命周期管理策略
        • 策略效果验证
      • 2.2 索引分片优化方案
    • 3. 成本优化策略矩阵
      • 3.1 存储成本优化
      • 3.2 计算成本优化
      • 3.3 综合优化效果预测
    • 4. 企业级优化案例
      • 4.1 电商日志分析场景
      • 4.2 物联网时序数据场景
    • 5. 自动化成本管控
      • 5.1 基于`AI`的成本预测
      • 5.2 预算告警与自动治理
        • 自动治理策略
    • 6. 工具链与监控体系
      • 6.1 AWS原生工具栈
      • 6.2 自定义监控看板
    • 7. 未来演进方向
      • 7.1 `智能分层技术`
      • 7.2 边缘计算协同

8.2.2AWS OpenSearch Serverless 成本优化与冷热数据分离深度实践
成本优化与冷热数据分离架构
数据摄入层
冷热分层策略
存储优化层
查询路由层
生命周期管理
监控与成本优化
Kinesis Firehose实时摄入
Lambda数据预处理
基于时间/访问频率的冷热标签
OpenSearch ILM策略
热数据驻留SSD
冷数据迁移至S3/Glacier
Serverless Collection隔离
查询自动路由热数据
冷数据通过SQL/REST访问
自动索引滚动
冷数据归档与删除
CloudWatch监控OCU消耗
Cost Explorer分析成本
预留OCU节省30%-50%

  • 流程图说明：

    • 数据摄入层
      • 使用 Kinesis Firehose 实时采集日志 / 指标数据
      • 通过 Lambda 进行数据清洗、格式转换和冷热标签标注
    • 冷热分层策略
      • 基于时间戳（如 7 天内为热数据）或访问频率（如近 30 天查询量）打标签
      • 利用 OpenSearch 索引生命周期管理（ILM）自动执行冷热迁移
    • 存储优化层
      • 热数据存储于 OpenSearch Serverless SSD
      • 冷数据通过 S3 集成或直接迁移至 Glacier
      • 按业务维度创建独立的 Serverless Collection
    • 查询路由层
      • 热数据查询直接命中内存缓存
      • 冷数据通过 SQL 接口或 REST API 访问 S3 归档
    • 生命周期管理
      • 自动滚动索引（如每天创建新索引）
      • 冷数据归档后定期删除原始数据
    • 监控与成本优化
      • 监控 OCU 使用量和存储成本
      • 通过预留 OCU 和按需计费组合降低成本
      • 分析历史成本趋势优化策略

  • Cost Explorer 深度解析与实战指南

    • 核心功能与架构
Cost Explorer核心功能
成本趋势分析
成本分配标签
预留实例建议
成本预测
AWS服务对比
每日/月度成本曲线
成本异常波动检测
按标签过滤（如环境/业务线）
自定义成本分配规则
RI/Savings Plan优化建议
未充分利用资源警示
未来30天成本预测
预留实例ROI分析
各服务成本占比
跨区域成本对比

  • 冷热分离场景操作指南-关键分析维度

    • 冷热数据成本构成
      热数据成本 = OCU费用（实时计算） + SSD存储费用冷数据成本 = S3标准存储（30天内） + S3 Glacier（长期归档）
    • 查询路由成本追踪
      在这里插入图片描述
    • 监控仪表盘建议
    指标阈值范围监控频率
    OCU利用率>80%5分钟
    冷数据查询延迟>500ms1小时
    存储成本环比增长>15%每日
    预留实例覆盖率<70%每周

1. 成本构成分析与优化机会识别

1.1 Serverless模式成本分布

成本类型占比计费模型优化潜力点
计算资源65%$0.48/OCU小时自动缩容/查询优化
热数据存储22%$0.023/GB/月冷热分层/压缩算法
冷数据存储8%$0.012/GB/月生命周期管理
数据传输5%$0.01/GB（跨AZ）流量调度优化

行业数据：合理实施冷热分层可降低存储成本58%，整体成本节省27%-35%

1.2 冷热数据特征分析
>10次/天
1-10次/天
<1次/天
7天
30天
1年+
数据温度
访问频率
热数据
温数据
冷数据
保留策略
数据特征矩阵
维度热数据温数据冷数据
访问频率>100次/天1-10次/天<1次/周
延迟敏感度<100ms<500ms<2s
存储成本$0.023/GB$0.015/GB$0.012/GB
典型场景实时监控/搜索周报生成/审计合规归档/历史分析

2. 冷热数据分离技术实现

2.1 生命周期管理策略

# 定义一个 AWS OpenSearch Serverless 的生命周期策略资源，名称为 hot_cold
resource "aws_opensearchserverless_lifecycle_policy" "hot_cold" {# 生命周期策略的名称，这里设置为 hot-warm-cold-policyname        = "hot-warm-cold-policy"# 对该生命周期策略的描述，说明这是一个用于冷热数据分层的策略description = "冷热数据分层策略"# 定义生命周期策略的具体内容，使用 jsonencode 函数将 JSON 格式的策略转换为字符串policy = jsonencode({# 策略中包含多个规则，使用 Rules 数组来定义"Rules" : [{# 规则的名称，用于标识该规则，这里表示将热数据转换为温数据的规则"Name" : "HotToWarm",# 规则触发的条件"Conditions" : {# 数据的年龄条件，当数据的年龄达到 7 天，单位为天"Age" : { "Value" : 7, "Unit" : "DAYS" },# 文档数量条件，当索引中的文档数量达到 1000000 个"DocCount" : { "Value" : 1000000 }},# 当满足上述条件时要执行的操作"Actions" : {# 操作类型为 TRANSITION，表示数据层的转换"Type" : "TRANSITION",# 转换的目标层为 WARM，即将数据从热数据层转换到温数据层"Target" : "WARM"}},{# 规则的名称，用于标识该规则，这里表示将温数据转换为冷数据的规则"Name" : "WarmToCold",# 规则触发的条件"Conditions" : {# 数据的年龄条件，当数据的年龄达到 30 天，单位为天"Age" : { "Value" : 30, "Unit" : "DAYS" }},# 当满足上述条件时要执行的操作"Actions" : {# 操作类型为 TRANSITION，表示数据层的转换"Type" : "TRANSITION",# 转换的目标层为 COLD，即将数据从温数据层转换到冷数据层"Target" : "COLD"}},{# 规则的名称，用于标识该规则，这里表示删除冷数据的规则"Name" : "DeleteCold",# 规则触发的条件"Conditions" : {# 数据的年龄条件，当数据的年龄达到 365 天，单位为天"Age" : { "Value" : 365, "Unit" : "DAYS" }},# 当满足上述条件时要执行的操作"Actions" : {# 操作类型为 DELETE，表示删除数据"Type" : "DELETE"}}]})
}
策略效果验证
策略阶段数据量存储成本/月查询延迟存储压缩率
热数据（7天）500GB$11.585ms1.5:1
温数据（30天）2TB$30220ms3:1
冷数据（1年）10TB$120650ms5:1

2.2 索引分片优化方案

// 向 _serverless/settings 端点发送 PUT 请求，用于配置 OpenSearch Serverless 的索引设置
PUT _serverless/settings
{"index": {// 配置不同数据层（热、温、冷）的索引分片数量"number_of_shards": {// 热数据层的索引分片数量设置为 6// 热数据通常是频繁访问的数据，较多的分片可以提高读写性能，因为可以并行处理更多的请求"hot": 6,// 温数据层的索引分片数量设置为 3// 温数据的访问频率相对热数据较低，所以可以适当减少分片数量以节省资源"warm": 3,// 冷数据层的索引分片数量设置为 1// 冷数据很少被访问，使用较少的分片可以降低存储和管理成本"cold": 1},// 配置不同数据层（热、温、冷）的索引压缩编解码器"codec": {// 热数据层使用 ZSTD 编解码器// ZSTD 编解码器在压缩比和压缩/解压缩速度之间取得了较好的平衡，适合热数据频繁读写的场景"hot": "ZSTD",// 温数据层同样使用 ZSTD 编解码器// 考虑到温数据的读写频率和存储需求，ZSTD 仍然是一个合适的选择"warm": "ZSTD",// 冷数据层使用 BEST_COMPRESSION 编解码器// 冷数据很少被访问，更注重压缩比以节省存储空间，BEST_COMPRESSION 可以提供更高的压缩率"cold": "BEST_COMPRESSION"},// 配置索引的路由分配规则"routing": {"allocation": {"include": {// 要求索引的数据必须分配到具有 "hot_content" 数据层属性的节点上// 这有助于将索引数据集中在特定类型的节点上，以满足不同数据层的性能和存储要求"data_tier": "hot_content"}}}}
}
  • 分片配置黄金法则：
数据温度分片大小副本数段合并策略刷新间隔
热数据30-50GB2tiered（分层）1s
温数据50-100GB1log_byte_size30s
冷数据100-200GB0log_doc关闭

3. 成本优化策略矩阵

3.1 存储成本优化

策略实施方式成本节省影响范围
数据压缩ZSTD/BEST_COMPRESSION编解码器35%-60%存储成本
冷热分层生命周期自动迁移40%-55%存储成本
副本数调整热数据2副本→冷数据0副本30%存储/计算成本
索引滚动按时间/大小滚动创建新索引25%管理成本

3.2 计算成本优化

策略实施方式成本节省性能影响
查询优化避免全扫描/使用过滤条件15%-40%延迟降低
自动缩容基于负载动态调整OCU数量20%-35%扩展延迟
缓存利用结果缓存+分片请求缓存30%查询速度提升
定时降级夜间降低副本数/合并分片25%查询性能波动

3.3 综合优化效果预测

优化组合成本节省实施复杂度适合场景
基础策略25%-30%★★中小规模业务
高级策略35%-45%★★★大型企业
激进策略50%+★★★★成本敏感型业务

4. 企业级优化案例

4.1 电商日志分析场景

  • 原始成本结构：

    • 日均数据量：50TB
    • 存储成本：$3,450/月
    • 计算成本：$8,200/月

  • 优化措施：

      1. 热数据保留3天 → 存储节省40%
      1. 启用ZSTD压缩 → 存储节省35%
      1. 夜间自动降级副本 → 计算节省25%
      1. 查询结果缓存 → 计算节省30%

  • 实施效果：

指标优化前优化后节省比例
存储成本$3,450$1,85046.4%
计算成本$8,200$5,30035.4%
P99查询延迟620ms480ms-22.6%

4.2 物联网时序数据场景

// 向 _serverless/_index_template/iot_metrics 端点发送 PUT 请求
// 此请求用于创建或更新名为 iot_metrics 的索引模板
PUT _serverless/_index_template/iot_metrics
{// 指定该索引模板所适用的索引名称模式// 这里设置为 ["iot-*"]，意味着所有以 "iot-" 开头的索引都会应用此模板"index_patterns": ["iot-*"],// 定义具体的模板内容，当创建符合上述模式的索引时，会应用这些设置"template": {"settings": {// 指定索引生命周期管理策略的名称// 这里设置为 "iot-lifecycle"，意味着以 "iot-" 开头的索引将遵循此生命周期策略// 生命周期策略可用于管理索引的各个阶段，如热数据、温数据、冷数据阶段，以及数据的删除等操作"index.lifecycle.name": "iot-lifecycle",// 指定索引使用的压缩编解码器为 ZSTD// ZSTD 编解码器在压缩比和压缩/解压缩速度之间取得了较好的平衡// 可以减少索引数据的存储空间，同时保持相对较快的读写性能"index.codec": "ZSTD",// 配置索引的路由分配规则// 要求索引的数据必须分配到具有 "hot_content" 数据层属性的节点上// 这有助于将索引数据集中在特定类型的节点上，以满足不同数据层的性能和存储要求"index.routing.allocation.include.data_tier": "hot_content"},"mappings": {// 定义索引中文档的字段映射关系"properties": {// 定义 @timestamp 字段的类型为日期类型// 通常用于存储文档的时间戳信息，方便进行时间范围的查询和分析"@timestamp": { "type": "date" },// 定义 value 字段的类型为浮点型// 适用于存储数值类型的数据，如传感器的测量值等"value": { "type": "float" },// 定义 device_id 字段的类型为关键字类型// 关键字类型用于精确匹配，通常用于存储设备 ID 等唯一标识信息"device_id": { "type": "keyword" }}}}
}
  • 优化效果：
指标优化前优化后提升幅度
存储成本/TB$23$9.2-60%
写入吞吐量50,000 docs/s75,000 docs/s+50%
长期存储保留1年3年+200%

5. 自动化成本管控

5.1 基于AI的成本预测

# 定义一个名为 predict_cost 的函数，用于根据历史数据进行成本预测
# 参数 historical_data 是一个包含历史成本数据的序列，例如列表或数组
def predict_cost(historical_data):# 从 statsmodels 库的 tsa.arima.model 模块中导入 ARIMA 类# ARIMA（Autoregressive Integrated Moving Average）是一种常用的时间序列预测模型from statsmodels.tsa.arima.model import ARIMA# 创建一个 ARIMA 模型实例# order=(5,1,0) 是 ARIMA 模型的参数设置# 第一个参数 5 表示自回归阶数（p），即使用过去 5 个时间步的数据进行自回归计算# 第二个参数 1 表示差分阶数（d），对数据进行一阶差分以使其平稳# 第三个参数 0 表示移动平均阶数（q），这里不使用移动平均项model = ARIMA(historical_data, order=(5,1,0))# 对 ARIMA 模型进行拟合# 拟合过程是根据历史数据来估计模型的参数，使得模型能够尽可能准确地描述历史数据的特征model_fit = model.fit()# 使用拟合好的模型进行未来 30 个时间步的成本预测# steps=30 表示预测未来 30 个时间步的成本值forecast = model_fit.forecast(steps=30)# 返回预测结果return forecast
  • 预测准确率：
时间范围MAE（美元）RMSE（美元）R²得分
7天预测1201500.92
30天预测4505800.87
季度预测220028000.78

5.2 预算告警与自动治理

# 使用 Terraform 定义一个 AWS Budgets 预算资源，名称为 opensearch
resource "aws_budgets_budget" "opensearch" {# 预算的名称，这里设置为 monthly-opensearch-budget# 方便在 AWS 控制台或其他管理界面中识别该预算name              = "monthly-opensearch-budget"# 预算的类型，设置为 COST 表示这是一个基于成本的预算# 用于控制 AWS 服务的使用成本budget_type       = "COST"# 预算的限额金额，这里设置为 5000# 意味着在该预算周期内，AWS OpenSearch 服务的成本不能超过 5000limit_amount      = "5000"# 预算限额的货币单位，设置为 USD 表示以美元为单位limit_unit        = "USD"# 预算的时间周期单位，设置为 MONTHLY 表示按每月进行预算控制# 即每个月的成本不能超过 5000 美元time_unit         = "MONTHLY"# 配置预算的通知规则notification {# 比较运算符，设置为 GREATER_THAN 表示当实际成本超过某个阈值时触发通知comparison_operator = "GREATER_THAN"# 阈值，设置为 90 表示当实际成本达到预算限额的 90%（即 4500 美元）时触发通知threshold           = 90# 通知类型，设置为 ACTUAL 表示基于实际发生的成本进行通知# 还有一种类型是 FORECASTED 表示基于预测成本进行通知notification_type   = "ACTUAL"# 订阅通知的电子邮件地址列表# 当触发通知时，会向 finops@example.com 发送邮件提醒subscriber_email_addresses = ["finops@example.com"]}# 配置预算的自动调整规则auto_adjust {# 自动调整类型，设置为 FORECAST 表示根据成本预测自动调整预算限额# 例如，如果预测下个月的成本会增加，预算限额会相应地自动提高auto_adjust_type = "FORECAST"}
}
自动治理策略
触发条件动作冷却时间效果验证
成本超预算80%自动切换冷数据副本为01小时成本降低15%
连续3天低负载缩减50%计算单元6小时成本降低22%
存储增长>10%/天触发归档审查流程立即存储节省30%+

6. 工具链与监控体系

6.1 AWS原生工具栈

工具名称功能定位关键指标集成方式
Cost Explorer成本分析与预测每日成本/预测偏差API/SDK
CloudWatch性能监控与告警OCU利用率/查询延迟自动集成
Trusted Advisor优化建议生成潜在节省金额/优化项控制台
Lambda自动执行治理任务治理动作触发次数EventBridge调度
  • EventBridge
    • 核心功能架构
EventBridge调度核心
规则定义
目标集成
监控与报警
Cron表达式
事件模式匹配
时区配置
Lambda函数
Step Functions状态机
EC2实例
OpenSearch Serverless
CloudWatch指标
警报通知
执行历史查询
  • 关键参数说明
参数描述
schedule_expressionCron表达式，支持UTC时区，例如：rate(5 minutes) 或 cron(0 3 * * ? *)
input传递给目标的JSON格式参数，支持动态变量引用
dead_letter_config失败任务的死信队列配置，支持SQS或SNS
retry_policy任务失败重试策略，默认最多重试185次
  • 典型应用场景
    • 数据生命周期管理
EventBridge Lambda S3 OpenSearch 触发冷数据迁移 复制数据到冷存储 更新索引元数据 EventBridge Lambda S3 OpenSearch
  • 成本自动化报告
  • 总结
    • EventBridge 调度是实现 AWS 资源自动化的核心工具，通过结合 Lambda、Step Functions 等服务，可实现数据生命周期管理、成本优化、故障自愈等复杂场景。
    • 合理配置 Cron 表达式、监控指标和报警规则，可确保调度任务的可靠性和成本效率。

6.2 自定义监控看板

{"widgets": [{"type": "metric","properties": {// 定义要显示的指标列表"metrics": [// 第一个指标：OpenSearch集群的可搜索文档数量["AWS/OpenSearch", "SearchableDocuments", "CollectionName", "prod-logs"],// 第二个指标：使用相对路径简化重复维度，等价于：// ["AWS/OpenSearch", "FreeStorageSpace", "CollectionName", "prod-logs"][".", "FreeStorageSpace", ".", "."]],// 数据聚合周期：5分钟（300秒）"period": 300,// 统计方法：平均值"stat": "Average",// 监控的AWS区域"region": "us-west-2",// 图表标题"title": "存储容量监控"}},{"type": "text","properties": {// 使用Markdown格式显示文本"markdown": "## 实时成本\n当前月份支出：${{cost.current}} \n预测月底：${{cost.forecast}}"}}]
}
  • 关键监控指标：
指标名称阈值告警级别响应动作
小时成本增长率>10%P1触发自动缩容
热数据存储占比>70%P2审查生命周期策略
冷数据查询量突增>500次/分钟P1临时提升冷数据副本
压缩率下降<基准值20%P3检查压缩算法配置

7. 未来演进方向

7.1 智能分层技术
高频访问
常规访问
低频访问
几乎不访问
原始数据
机器学习预测
极热层
热层
温层
冷层
  • 预测模型效果：
模型类型预测准确率存储节省实施复杂度
基于规则65%25%★★
时间序列预测78%35%★★★
深度学习模型92%48%★★★★

7.2 边缘计算协同

方案延迟带宽消耗成本效益适用场景
全云端处理100-200ms高低集中式业务
边缘预处理20-50ms中中分布式IoT
混合分层处理50-80ms低高实时分析场景
  • 实施路线图建议：
      1. 第一阶段：基础生命周期策略+压缩优化（1-2周）
      1. 第二阶段：引入自动扩缩容+缓存机制（3-4周）
      1. 第三阶段：部署AI预测模型+智能分层（5-8周）
      1. 持续优化：建立FinOps团队进行成本治理

“真正的成本优化不是一次性的项目，而是需要融入持续运营的体系” —— AWS Well-Architected Framework*

该方案通过以下技术创新实现成本优化目标：

  1. 动态生命周期策略：基于访问模式自动迁移数据
  2. 智能压缩算法：ZSTD与BEST_COMPRESSION混合使用
  3. 预测式扩缩容：结合时间序列预测提前调整容量
  4. 分层存储架构：热/温/冷/归档四级数据管理体系
  5. FinOps自动化：成本治理策略代码化

  • FinOps

    • FinOps（Financial Operations）是一种通过云成本治理、资源优化和自动化策略，实现技术与财务团队协同的运营模式。其核心目标是：
      • 成本透明化：实时跟踪云资源使用与支出。
      • 资源高效化：消除浪费，提升 ROI。
      • 决策数据化：基于成本分析优化架构设计。
    • FinOps 核心组件
    FinOps核心
    成本治理
    资源优化
    自动化策略
    跨团队协作
    标签策略
    预算管理
    合规审计
    预留实例优化
    按需实例调度
    数据归档策略
    生命周期管理
    成本预测
    自动化报警
    成本分摊机制
    绩效考核指标
    培训与文化

  • 实施时建议优先进行成本审计（Cost Audit），识别主要开支来源，再分阶段推进优化措施。建议每季度进行一次成本健康检查，确保持续获得最优TCO。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.rhkb.cn/news/35343.html

如若内容造成侵权/违法违规/事实不符，请联系长河编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

安卓edge://inspect 和 chrome://inspect调试移动设备上的网页

安卓edge://inspect 和 chrome://inspect调试移动设备上的网页

edge://inspect 和 chrome://inspect 是用于调试浏览器中运行的网页和移动设备上的网页的工具。这两个工具分别属于 Microsoft Edge 和 Google Chrome 浏览器。以下是它们的详细介绍&#xff1a; chrome://inspect 如果是直接使用数据线调试&#xff0c;则只需要执行下面的第一…
阅读更多...
checkpoint机制

checkpoint机制

1、什么是checkpoint 将缓冲池中的脏页刷新到磁盘&#xff0c;并更新redo log的checkpoint位点&#xff0c;确保数据库在发生故障时可以快速恢复到一致的状态。 2、checkpoint执行过程 确保需要刷新的脏页&#xff1a;从缓冲池中选取一部分需要刷新的页数据页刷新&#xff1…
阅读更多...
【微服务日志收集①】使用FileBeat+Logstash+ES搭建ELK日志系统

【微服务日志收集①】使用FileBeat+Logstash+ES搭建ELK日志系统

使用FileBeatLogstashES搭建ELK日志系统&#xff0c;架构图如下&#xff1a; 1、 使用docker快速创建ES服务和Kibana服务 前置条件&#xff1a;需要在linux上提前安装好docker和docker-compose 1.1、在linux创建好一个用于存放docker-compose配置文件的文件夹 我的目录是/app/…
阅读更多...
Centos 7 安装达梦数据库

Centos 7 安装达梦数据库

一、环境准备 1. 确认操作系统的版本和数据库的版本是否一致 cat /etc/redhat-release 2. 关闭防火墙 查看防火墙状态 firewall-cmd --state 停止firewall systemctl stop firewalld.service 禁止firewall开机启动 systemctl disable firewalld.service 3. 修改文件l…
阅读更多...
仿“东方甄选”直播商城小程序运营平台

仿“东方甄选”直播商城小程序运营平台

在公域直播流量红利趋于饱和、流量成本大幅攀升的当下&#xff0c;私域直播为企业开辟了新的流量聚集和转化渠道&#xff0c;特别是对于那些希望在私域流量领域取得突破的品牌商家来说&#xff0c;直播场景以其独特的高频互动氛围&#xff0c;相比其他运营方式&#xff0c;展现…
阅读更多...
ZED X系列双目3D相机的耐用性与创新设计解析

ZED X系列双目3D相机的耐用性与创新设计解析

在工业自动化和学术研究领域&#xff0c;高精度的视觉设备正成为提升效率和质量的关键。ZED X系列AI立体相机&#xff0c;凭借其先进的技术和耐用的设计&#xff0c;为这一领域带来了新的可能。 核心技术&#xff1a;深度感知与精准追踪 ZED X系列的核心技术之一是Neural Dept…
阅读更多...
Cursor的使用感受，帮你使用好自动化编程工具，整理笔记

Cursor的使用感受，帮你使用好自动化编程工具，整理笔记

使用感受 说实话&#xff0c;我觉得cursor还是好用的&#xff0c;可能我刚开始使用&#xff0c;没有使用的非常的熟练&#xff0c;运用也没有非常的透彻&#xff0c;总体体验还是不错的&#xff0c;在使用它时&#xff0c;我优先考虑&#xff0c;前端页面功能复用的时候&#…
阅读更多...
《C#上位机开发从门外到门内》3-5：基于FastAPI的Web上位机系统

《C#上位机开发从门外到门内》3-5：基于FastAPI的Web上位机系统

文章目录 一、项目概述二、系统架构设计三、前后端开发四、数据可视化五、远程控制六、系统安全性与稳定性七、性能优化与测试八、实际应用案例九、结论 随着互联网技术的快速发展&#xff0c;Web上位机系统在工业自动化、智能家居、环境监测等领域的应用日益广泛。基于FastAPI…
阅读更多...
vue3单独引用element-plus的Infinite Scroll无限滚动；vue3自定义指令

vue3单独引用element-plus的Infinite Scroll无限滚动；vue3自定义指令

文章目录 1.正常单独使用element-plus其他功能组件2.引入类似与指令的插件3.自定义指令钩子 1.正常单独使用element-plus其他功能组件 引入即可使用 import { ElSelect, ElOption } from "element-plus"2.引入类似与指令的插件 需要先引入&#xff0c;再注册&…
阅读更多...
CMake学习笔记(二):变量设值,源文件/文件查找

CMake学习笔记(二):变量设值,源文件/文件查找

一_变量设值: 在上一节中我们知道了如何去链接起来多个源文件并且生成可执行文件&#xff0c;但是当我们的源文件过多的时候会导致我们在add_executable里面写很长的一串&#xff0c;所以我们可以使用变量来进行设值: set(<variable> <value>... [PARENT_SCOPE])…
阅读更多...
【Function】Azure Function通过托管身份或访问令牌连接Azure SQL数据库

【Function】Azure Function通过托管身份或访问令牌连接Azure SQL数据库

【Function】Azure Function通过托管身份或访问令牌连接Azure SQL数据库 推荐超级课程： 本地离线DeepSeek AI方案部署实战教程【完全版】Docker快速入门到精通Kubernetes入门到大师通关课AWS云服务快速入门实战目录 【Function】Azure Function通过托管身份或访问令牌连接Azu…
阅读更多...
案例5_1:单位数码管显示0

案例5_1:单位数码管显示0

文章目录 文章介绍效果图仿真图5_1放置单位数码管 代码5_1.c 文章介绍 效果图 仿真图5_1 复制案例1_2的仿真图&#xff0c;在此基础上修改 注意&#xff1a;栅格大小需要缩小 放置单位数码管 代码5_1.c #include <reg52.h>#define uchar unsigned char #define uint un…
阅读更多...
helm部署metricbeat

helm部署metricbeat

背景 在Elastic Stack 7.5版本之前&#xff0c;系统默认采用内置服务进行监控数据采集&#xff08;称为内部收集机制&#xff09;&#xff0c;这种设计存在显著局限性&#xff1a; 当ES集群崩溃时自带的节点监控也会随之崩溃&#xff0c;直到集群恢复前&#xff0c;崩溃期间的…
阅读更多...
基于 Python 爬取 TikTok 搜索数据 Tiktok爬虫（2025.3.17）

基于 Python 爬取 TikTok 搜索数据 Tiktok爬虫（2025.3.17）

1. 前言 在数据分析和网络爬虫的应用场景中&#xff0c;我们经常需要获取社交媒体平台的数据&#xff0c;例如 TikTok。本篇文章介绍如何使用 Python 爬取 TikTok 用户搜索数据&#xff0c;并解析其返回的数据。 结果截图 2. 项目环境准备 在正式运行代码之前&#xff0c;我…
阅读更多...
阿里云、腾讯云云主机如何提升远程桌面安全（VNC登录）

阿里云、腾讯云云主机如何提升远程桌面安全（VNC登录）

远程桌面连接&#xff08;RDP&#xff09;是管理主机的常用方式&#xff0c;但同时也带来了安全风险。黑客会对远程桌面进行暴力破解攻击和撞库攻击。作为云主机&#xff0c;在远程桌面方面有天然的安全优势&#xff1a;可以关闭远程桌面服务或端口&#xff0c;限制只能通过网页…
阅读更多...
【etcd】

【etcd】

一、ETCD 简介 etcd是一个由CoreOS团队开发的开源项目&#xff0c;旨在提供一个高可用的、分布式的、一致的键值存储&#xff0c;用于配置共享和服务发现。尽管它看起来像一个键值存储&#xff0c;但etcd的设计目标远远超出了传统数据库的功能范围。 etcd的核心特性包括&…
阅读更多...
深圳南柯电子｜医疗设备EMC检测测试整改：保障患者安全的第一步

深圳南柯电子｜医疗设备EMC检测测试整改：保障患者安全的第一步

在医疗设备领域&#xff0c;电磁兼容性&#xff08;EMC&#xff09;是确保设备安全、有效运行的关键指标。随着医疗技术的飞速发展&#xff0c;医疗设备日益复杂&#xff0c;其电磁环境也愈发复杂多变。EMC检测测试及整改因此成为医疗设备研发、生产、销售过程中不可或缺的一环…
阅读更多...
项目实战系列：基于瑞萨RA6M5构建多节点OTA升级-系统设计＜一＞

项目实战系列：基于瑞萨RA6M5构建多节点OTA升级-系统设计＜一＞

项目背景 原嵌入式控制系统采用分布式模块化架构&#xff0c;由12个功能板卡&#xff08;通信控制、信号采集、驱动执行等&#xff09;组成。系统维护阶段存在以下痛点&#xff1a; 低效的本地烧录机制&#xff1a;各板卡固件升级需通过JTAG接口逐一手动连接JLINK仿真器&#x…
阅读更多...
五大方向全面对比 IoTDB 与 OpenTSDB

五大方向全面对比 IoTDB 与 OpenTSDB

对比系列第三弹&#xff0c;详解 IoTDB VS OpenTSDB&#xff01; 之前&#xff0c;我们已经深入探讨了时序数据库 Apache IoTDB 与 InfluxDB、Apache HBase 在架构设计、性能和功能方面等多个维度的区别。还没看过的小伙伴可以点击阅读&#xff1a; Apache IoTDB vs InfluxDB 开…
阅读更多...
RAGFlow部署与使用（开源本地知识库管理系统，包括kibana配置）

RAGFlow部署与使用（开源本地知识库管理系统，包括kibana配置）

一、RAGFlow 简介 戳我访问RAGFlow RAGFlow 是一款基于深度文档理解构建的开源 RAG&#xff08;Retrieval-Augmented Generation&#xff09;引擎。它可以给我们搭建本地知识库&#xff0c;将用户的知识文档上传到RAGFlow后&#xff0c;通过文档切分、向量入库&#xff0c;在…
阅读更多...
最新文章
推荐文章

Copyright @ 2022~2023