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

[wukaige]

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

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

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

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

[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]

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


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