悬赏 1000 RMB，求一个 Elasticsearch 相关的解决方案

[wukaige]

目前用 es 做了一个全文检索服务，索引 3T 大小左右。

9 点上班有个访问高峰，其他时间访问量不高，9 点的时候，Es 服务需要支撑至少 1w 人同时访问，其他时间不超过 1000 。

在这种场景下，部署一个能同时支撑 1w 人的 Es 服务开销太大。

有没有一种解决方案，动态调整 Es 资源（类似于阿里云的 Elasticsearch serverless ，按量付费），1w 个人来就给你能支撑 1w 人访问的计算资源，1000 人来就给 1000 人的资源，这样能节省很大一笔开支。

我没有表述清楚，假设用户量 60w ，这 60w 个人在一分钟内发请求过来，平均每秒 1w 个请求，并发至少 1w 是这么来的。

用户搜索词有 90% 的可能不一样，缓存可能有点用，但是光靠缓存不太行。

有信心的可直接加 V: d3VrYWlnZWUK

能帮忙部署一个 demo 更好，钱好说（反正不是我出），只要能解决这个场景。

[Aliencn]

那就直接用阿里云 ES 的弹性伸缩不就行了嘛。
自己实现的话也是够买弹性服务器加入集群。

[wukaige]

@Aliencn

阿里云 ES 的弹性伸缩，并发量上不了 1w

[bronyakaka]

简单说就是 资源可以减少，但是要上缓存，缓存层支撑高并发

[angeni]

搜索应该也讲二八原则，那给 80%的套上缓存可能行

[oudemen]

es 部署到 k8s 中，定时弹性扩缩容？

[my3157]

就用 ES 原生的 ILM 最方便, 部署用 k8s, 配置好 k8s 的 nodegroup, 每天九点之前, 扩容一批 es hot/warm 节点, 并且将 index 从 cold 节点提升上来, 完事了再降回 cold 节点, 缩掉扩容的 k8s 节点, 实现起来也不复杂

[justest123]

感觉像是个 AB 问题。。

先确认下，这 1W 人是真的都需要访问到 ES 吗，用缓存转移走部分重复请求或者没必要的请求吧

[sdoq19]

阿里云 elasticsearch serverless

[fengjianche]

这种分布式存储问题都一个样，先上多级缓存，再扛不住就加机器。1w 人同时访问，也不是很多啊。

[JunMemon]

ES 拆分节点类型，可以横向扩展非 data 节点，data 节点采用冷热数据部署

[bootvue]

k8s hpa

[hallDrawnel]

感觉像是个 XY 问题，你最终要做的可能不是扩容你的 ES 。试着从搜索分布分析一下？

[zhenjiachen]

k8s hpa 或者 node hpa 应该不行把。以为他们只扩充节点，但是数据不会同步到新节点并且节点关闭了数据也丢了

[shizhibuyu2023]

有悬赏平台吗，没有的话谁去开发一个，我要抢单

[winglight2016]

ES 的缓存就是靠内存，你要是裸机安装就内存弹性增加，如果是 k8s 安装，那就用 HPA 弹性加内存

[ss098]

部署 ElasticSearch Helm 到 Kubernetes ，声明 ElasticSearch 不同 node role 的 resources 以及 autoscaling 的配置。

https://github.com/bitnami/charts/tree/main/bitnami/elasticsearch

[ChoateYao]

阿里云有这种业务啊，包括 RDS 之类的数据库都有动态扩容方案

https://help.aliyun.com/zh/es/user-guide/perform-auto-scaling-for-a-cluster?spm=a2c4g.11186623.0.0.6f397de1Etkjdj

[wukaige]

@justest123

真的要访问，1w 可能还不保险。

[lasuar]

你需要一个 es 专家

[mightybruce]

"假设用户量 60w ，这 60w 个人在一分钟内发请求过来，平均每秒 1w 个请求，并发至少 1w 是这么来的。"

首先这个公式就是有问题， 怎么可能 60w 人都是活跃用户，并且用户量根本不能直接这样换算， 你这什么应用

就是一个 XY 问题。

[Jinnrry]

不改业务代码，纯改 es 架构不太现实，你有没有想过 3T 数据扩容的时候主节点复制到从节点要多久？如果高峰瞬间过来，这时你又加节点，从节点复制数据把主节点机器大部分 io 都占了，服务瞬间 GG ，还不如不扩容

除非你能分钟级准确预估峰值时间，否则怎么定扩容策略

另外，1 万人同时访问，这也不多啊，就算缩容，每个月省几千块钱？

[brom111]

说起来既然都用阿里云了 有没有考虑过 Lindorm 这套东西

[Coolwinds]

从 IT 的角度上来说，你假如自己做伸缩，你多出来的计算资源譬如服务器在闲时怎么办，企业一般不会允许你在一台机器上部署多个服务，除非只是测试环境节省资源

[skymei]

感觉业务描述不够清晰，数据是否有冷热区分，是只有基本的全文检索服务，还是会有 agg 聚合统计，数据有没有业务状态，目前分片和副本怎么配置的，分词粒度咋样，这些都可能影响性能。

[keakon]

计算挺奇怪的，60 万用户全在一分钟内访问，这是主动发起的，还是定时任务啊？

平时还能有 1000 qps ，他们是有多闲，每 10 分钟都会查询一次…

说实话你这问题靠扩容没法解决，比如 8:59 时还是 1000 qps ，假设 1 台机器刚好。9:00 突然到 1 万 qps ，立刻再起 9 台机器，启动要半分钟，同步数据几分钟，然后发现 qps 回到 1000 了，它们又可以下线了。

[rrfeng]

可以搞。

8 点执行扩容计划，增加节点，增加副本，9 点前 copy 完毕上线。高峰期过了就把临时节点下线。
第二天重复即可。
核心问题是 copy 数据可能会很慢，需要考虑用某种快照方式快速复制数据。


但是我觉得还是可以从业务逻辑上解决更好。

[raycj912]

可以多给点信息，不然只能给很粗方案。比如加支持 QPS 更高的组件（缓存）、要么就是弹性扩容，估计都不是你想要的

[cloudzhou]

@wukaige 我的天，你知道每秒 1w 个请求是什么样的一样概念吗

即便能完成你的需求，成本也不是你可以负担的，我简单说，你搞个 3T 内存，把内存当文件系统使用，那么肯定快很多

[dode]

还是采用超大内存机器吧，3-6 台物理服务器，一天电费是没多少钱。
不是很了解 es 在足够内存和 CPU 情况下，是否有锁限制性能？

k8s 自建 es 服务，定期，启动拉起&关闭服务。

这个 3T 数据能否拆分,提供负载均衡服务

[dode]

用户搜索词都不一样，但是每个用户每天都是一样的搜索词吗，能否预先批计算？

[dode]

非高峰期使用一个普通 ES 服务器，配置 SSD 应该就 OK 了，部署两套。

[yuedingwangji]

每秒并发 1w ， 真的可怕，这得是什么大项目

[dzdh]

搜的几个 index mapping 是怎么设计的 最多请求是什么类型的

[yoooooooo]

1w 的峰值，想自己搞这个弹性伸缩不太现实，想想看这个量级每天都要折腾多少节点，光是数据的迁移和从节点的拷贝要花多长时间，而且你们除了峰值其他时间的访问量比较小，那么每次需要操作的节点应该是非常多的，这个方案不现实。

[yoooooooo]

可以优先从业务角度考虑优化，看有没有优化空间，既然是搜索，为什么搜索词 90%都不会重叠，这个感觉好奇怪

[1018ji]

感觉不是加机器的问题，先梳理逻辑啊，看看到底啥事瓶颈


加机器解决一切问题，一个集群不够俩集群