基于容量估算

主要问题:

  • 每天将索引多少原始数据(GB)?保留数据多少天?
  • 原始数据膨胀率
  • 您将强制执行多少个副本分片?
  • 您将为每个数据节点分配多少内存?
  • 您的内存:数据比例是多少?

原则

  • 保留 +15% 以保持在磁盘水位以下。
  • 保留 +5% 用于误差和后台活动的余量。
  • 保留相当于一个数据节点的资源来处理故障。

公式:

总数据量 GB = 原始数据 GB/天 * 保留天数 * 膨胀率 * (副本数 + 1)

总存储 GB = 总数据 GB * 1.15(包括磁盘 watermark threshold 和误差范围)

总数据节点数 = ROUNDUP(总存储 GB / (每个数据节点的内存 * 内存/数据比例)) + 1(用于故障转移)

举例:

假设 需要存储的源数据 50TB 大小

膨胀率 10% 副本数 1

每个节点 256G 内存

计算出:

总数据量 TB

= 50TB * (1 + 0.10) * (1 + 1)

= 110TB

总存储 TB

= 110TB * 1.15(考虑磁盘 watermark threshold 和误差范围)

= 126.5TB

如果有 256GB 的物理内存,128GB 会用于 JVM 堆,剩下的 128GB 将用于操作系统、文件缓存和其他系统进程。

按照常见的 1:30 的 RAM 到磁盘比例来计算,那么每个节点能处理的数据存储大约是:

256GB 内存 * 30 = 7680GB,大约等于 7.68TB

总数据节点数

= ROUNDUP(126.5TB / 7.68TB) + 1(用于故障转移)

= ROUNDUP(16.47) + 1

= 18

基于搜索吞吐量估算

在存储容量层面之外,还要考虑搜索响应时间和搜索吞吐量的目标,这些目标可能需要更多的内存和计算资源。

搜索响应时间受太多变量的影响,无法预测任何给定容量计划会如何影响它。但通过经验性测试搜索响应时间并估计预期的搜索吞吐量,我们可以估算出满足这些需求所需的集群资源。

主要问题:

  • 你每秒的最高搜索次数是多少?
  • 你的平均搜索响应时间(毫秒)是多少?
  • 你的数据节点上有多少个核心和每个核心有多少个线程

经验方法:

与其确定资源将如何影响搜索速度,不如将搜索速度视为一个常数,通过在计划的硬件上进行测量来处理。然后确定集群需要多少个核心来处理预期的搜索吞吐量峰值。最终目标是防止线程池队列增长速度超过它们被消耗的速度。如果计算资源不足,搜索请求有被丢弃的风险。

公式:

峰值线程数 = 向上取整(每秒的峰值搜索次数 * 平均搜索响应时间(毫秒) / 1000 毫秒)

线程池大小 = 向上取整((每个节点的物理核心数 * 每个核心的线程数 * 3 / 2) + 1)

总数据节点数 = 向上取整(峰值线程数 / 线程池大小)

举例:

假设每秒 2 万搜索请求,平均响应时间 50 毫秒,每个节点有 16 个线程数,计算需要多少节点

峰值线程数 = 20000 * 50 /1000 = 1000

线程池大小 = (16 * 1 * 3/2) + 1 = 25

总数据节点数 = 1000 / 25 = 40

大概需要 40 个数据节点来处理每秒 2 万的搜索请求,平均响应时间为 50 毫秒,每个节点有 16 个线程。这是一个粗略的估计,实际需求可能会因多种因素而有所不同。建议进行实际测试以确认这些数字。

Hot, Warm, Frozen

根据索引使用情况不同,通常分为种存储。

这是一种经济高效的方法,用于存储大量数据,同时优化了对较新数据的性能。在容量规划期间,每个层次必须独立进行规模确定,然后进行合并。

层面 目标 示例存储 示例内存:存储比
Hot 搜索为主 SSD DAS/SAN (>200Gb/s) 1:30
Warm 存储为主 HDD DAS/SAN (~100Gb/s) 1:100
Frozen 存档为主 Cheapest DAS/SAN (<100Gb/s) 1:500

实际情况要把搜索吞吐量估算和容量估算结合考虑。

关于 Easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。 与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档:https://www.infinilabs.com/docs/latest/easysearch

下载地址:https://www.infinilabs.com/download

Easysearch 容量规划建议的更多相关文章

  1. MongoDB的容量规划及硬件配置

    mongo是基于内存的数据库,应尽量将工作集中的数据全部加载到内存中,即内存应大于工作集 本文译自Chad Tindel的英文博客: http://www.mongodb.com/blog/post/ ...

  2. Hbase集群类型|集群配置|服务器选型|磁盘容量规划

    HBase和Hadoop的集群类型 1.单机模式 主要用于开发工作,一台机器上运行所有的守护进程,或者一台机器运行多个虚拟机.一般用于评估和测试. 2.小型集群 20台机器以内的集群,不同的机器运行不 ...

  3. Elasticsearch集群规模和容量规划的底层逻辑

    转载自: https://mp.weixin.qq.com/s?__biz=MzI2NDY1MTA3OQ==&mid=2247484628&idx=1&sn=666e416ae ...

  4. 二 mysql容量规划,性能测试

    何为基线- 当前运行状态记录.快照- 用于和未来的状态进行对比- 未来时刻产生关键事件后的新状态,作为下一个基线基线数据收集,关注哪些要点- 系统负载- MySQL运行状态- 相应的业务指标1.系统& ...

  5. MySQL容量规划之tcpcopy应用之道

    官方文档:https://github.com/session-replay-tools/mysql-replay-module tcpcopy可以将正式环境上来自客户端的请求复制一份到测试端并复现, ...

  6. web容量规划

    容量和性能   容量规划是基于当前性能判断系统需要什么及什么时候需要,它既是资本支出合理化证明过程也是一个技术变更;   性能调优是优化已存在的系统性能;   一般服务的升级步骤是:性能调优 -> ...

  7. oracle数据库规划建议

    之前负责的项目有用到oracle的,oracle dba给过一些建议,自己整理了一下,写再这里做个备忘 数据库需求分析: 1. 创建的数据库名称为maildb,并且字符集为UTF8. 2. 提供可连接 ...

  8. 数据库分库分表容量划分建议参考阿里云DRDS原则

    做分库分表的时候 一直想知道分库分表容量的最优规则有什么好的建议,以下是参考阿里云 DRDS 分库分表的规则,还是有一定的参考意义 .

  9. MySQL容量规划和性能测试

    性能容量关键指标: 每秒tps,峰值tps 基础数据量,日均增长数据量 最大连接数 内存分配 IOPS 重点关注指标: 业务指标: 每秒并发用户请求.每秒订单数.用户请求响应时长 折算成性能指标: q ...

  10. elasticsearch容量规划

    https://docs.bonsai.io/article/123-capacity-planning Capacity Planning Capacity planning is the proc ...

随机推荐

  1. 【Oracle】year must be between -4713 and +9999,and not be 0

    [Oracle]year must be between -4713 and +9999,and not be 0 year must be between -4713 and +9999,and n ...

  2. 力扣596(MySQL)-超过5名学生的课(简单)

    题目: 表: Courses 编写一个SQL查询来报告 至少有5个学生 的所有班级. 以 任意顺序 返回结果表. 查询结果格式如下所示 示例1:  解题思路: 使用group by按 班级 进行分组后 ...

  3. EasyNLP集成K-BERT算法,借助知识图谱实现更优Finetune

    导读 知识图谱(Knowledge Graph)的概念⾸次出现2012年,由Google提出,它作为⼀种⼤规模语义⽹络, 准确地描述了实体以及实体之间的关系.知识图谱最早应⽤于搜索引擎,⽤于准备返回⽤ ...

  4. 小白也能懂的 Nacos 服务模型介绍

    简介: 理解了 Nacos 的服务模型,也有利于我们了解 Nacos 背后的工作原理,从而确保我们正确地使用 Nacos. 作者:岛风 前言 按照目前市场上的主流使用场景,Nacos 被分成了两块功能 ...

  5. 使用 rocketmq-spring-boot-starter 来配置、发送和消费 RocketMQ 消息

    简介: 本文将 rocktmq-spring-boot 的设计实现做一个简单的介绍,读者可以通过本文了解将 RocketMQ Client 端集成为 spring-boot-starter 框架的开发 ...

  6. 走完线上 BUG 定位最后一公里

    简介: 因为线上线下环境隔离的问题,线上的输入很多时候难以在日常环境中构造,定位 bug 效率低下.是否有简单快捷的办法呢? 一个小故事 周末12点的闹钟在回龙观均价3000的出租屋急促的响起,程序员 ...

  7. 阿里云图数据库GDB V3引擎发布,加速开启“图智”未来

    ​简介:无论是学术界还是产业界,都对图数据库有比较高的预期.Gartner发布的<2021年十大数据和分析技术趋势>中提到:"到2025年图技术在数据和分析创新中的占比将从202 ...

  8. Forrester云原生开发者洞察白皮书,低代码概念缔造者又提出新的开发范式

    简介: 云原生时代的到来为开发者群体带来了前所未有的机遇,让开发者可以更加专注业务价值创造与创新,并使得人人成为开发者成为现实.广大开发者如何转型成为云原生开发者?运维等专业人员在云原生时代如何避免边 ...

  9. [Go] golang 时间格式化 12小时制 与 24小时制

    timestamp := int64(1591271169) # 12小时制 time.Unix(timestamp, 0).Format("2006-01-02 03:04:05" ...

  10. 深入理解 Swift Combine

    Combine 文中写一些 Swift 方法签名时,会带上 label,如 subscribe(_ subscriber:),正常作为 Selector 的写法时会忽略掉 label,只写作 subs ...