这是一个创建于 142 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前用 es 做了一个全文检索服务，索引 3T 大小左右。
9 点上班有个访问高峰，其他时间访问量不高，9 点的时候，Es 服务需要支撑至少 1w 人同时访问，其他时间不超过 1000 。
在这种场景下，部署一个能同时支撑 1w 人的 Es 服务开销太大。
有没有一种解决方案，动态调整 Es 资源（类似于阿里云的 Elasticsearch serverless ，按量付费），1w 个人来就给你能支撑 1w 人访问的计算资源，1000 人来就给 1000 人的资源，这样能节省很大一笔开支。
第 1 条附言 · 142 天前
我没有表述清楚，假设用户量 60w ，这 60w 个人在一分钟内发请求过来，平均每秒 1w 个请求，并发至少 1w 是这么来的。
用户搜索词有 90% 的可能不一样，缓存可能有点用，但是光靠缓存不太行。
有信心的可直接加 V: d3VrYWlnZWUK
能帮忙部署一个 demo 更好，钱好说（反正不是我出），只要能解决这个场景。
用户搜索词有 90% 的可能不一样，缓存可能有点用，但是光靠缓存不太行。
有信心的可直接加 V: d3VrYWlnZWUK
能帮忙部署一个 demo 更好，钱好说（反正不是我出），只要能解决这个场景。
36 条回复 • 2024-07-03 14:25:04 +08:00
 |
1
Aliencn 142 天前
那就直接用阿里云 ES 的弹性伸缩不就行了嘛。
自己实现的话也是够买弹性服务器加入集群。 |
 |
3
bronyakaka 142 天前
简单说就是 资源可以减少，但是要上缓存，缓存层支撑高并发
|
 |
4
angeni 142 天前
搜索应该也讲二八原则，那给 80%的套上缓存可能行
|
 |
5
oudemen 142 天前
es 部署到 k8s 中，定时弹性扩缩容？
|
 |
6
my3157 142 天前
就用 ES 原生的 ILM 最方便, 部署用 k8s, 配置好 k8s 的 nodegroup, 每天九点之前, 扩容一批 es hot/warm 节点, 并且将 index 从 cold 节点提升上来, 完事了再降回 cold 节点, 缩掉扩容的 k8s 节点, 实现起来也不复杂
|
 |
7
justest123 142 天前  1
感觉像是个 AB 问题。。
先确认下，这 1W 人是真的都需要访问到 ES 吗，用缓存转移走部分重复请求或者没必要的请求吧 |
 |
8
sdoq19 142 天前
阿里云 elasticsearch serverless
|
 |
9
fengjianche 142 天前
这种分布式存储问题都一个样，先上多级缓存，再扛不住就加机器。1w 人同时访问，也不是很多啊。
|
 |
10
JunMemon 142 天前
ES 拆分节点类型，可以横向扩展非 data 节点，data 节点采用冷热数据部署
|
 |
11
bootvue 142 天前
k8s hpa
|
 |
12
hallDrawnel 142 天前
感觉像是个 XY 问题，你最终要做的可能不是扩容你的 ES 。试着从搜索分布分析一下？
|
 |
13
zhenjiachen 142 天前
k8s hpa 或者 node hpa 应该不行把。以为他们只扩充节点，但是数据不会同步到新节点并且节点关闭了数据也丢了
|
 |
14
shizhibuyu2023 142 天前
有悬赏平台吗，没有的话谁去开发一个，我要抢单
|
 |
15
winglight2016 142 天前
ES 的缓存就是靠内存，你要是裸机安装就内存弹性增加，如果是 k8s 安装，那就用 HPA 弹性加内存
|
 |
16
ss098 142 天前
部署 ElasticSearch Helm 到 Kubernetes ，声明 ElasticSearch 不同 node role 的 resources 以及 autoscaling 的配置。
https://github.com/bitnami/charts/tree/main/bitnami/elasticsearch |
 |
17
ChoateYao 142 天前
阿里云有这种业务啊，包括 RDS 之类的数据库都有动态扩容方案
https://help.aliyun.com/zh/es/user-guide/perform-auto-scaling-for-a-cluster?spm=a2c4g.11186623.0.0.6f397de1Etkjdj |
 |
18
wukaige OP |
 |
19
lasuar 141 天前
你需要一个 es 专家
|
 |
20
mightybruce 141 天前
"假设用户量 60w ，这 60w 个人在一分钟内发请求过来，平均每秒 1w 个请求，并发至少 1w 是这么来的。"
首先这个公式就是有问题， 怎么可能 60w 人都是活跃用户，并且用户量根本不能直接这样换算， 你这什么应用 就是一个 XY 问题。 |
 |
21
Jinnrry 141 天前 via Android
不改业务代码，纯改 es 架构不太现实，你有没有想过 3T 数据扩容的时候主节点复制到从节点要多久？如果高峰瞬间过来，这时你又加节点，从节点复制数据把主节点机器大部分 io 都占了，服务瞬间 GG ，还不如不扩容
除非你能分钟级准确预估峰值时间，否则怎么定扩容策略 另外，1 万人同时访问，这也不多啊，就算缩容，每个月省几千块钱？ |
 |
22
brom111 141 天前
说起来既然都用阿里云了 有没有考虑过 Lindorm 这套东西
|
 |
23
Coolwinds 141 天前
从 IT 的角度上来说，你假如自己做伸缩，你多出来的计算资源譬如服务器在闲时怎么办，企业一般不会允许你在一台机器上部署多个服务，除非只是测试环境节省资源
|
 |
24
skymei 141 天前
感觉业务描述不够清晰，数据是否有冷热区分，是只有基本的全文检索服务，还是会有 agg 聚合统计，数据有没有业务状态，目前分片和副本怎么配置的，分词粒度咋样，这些都可能影响性能。
|
 |
25
keakon 141 天前
计算挺奇怪的，60 万用户全在一分钟内访问，这是主动发起的，还是定时任务啊？
平时还能有 1000 qps ，他们是有多闲，每 10 分钟都会查询一次… 说实话你这问题靠扩容没法解决，比如 8:59 时还是 1000 qps ，假设 1 台机器刚好。9:00 突然到 1 万 qps ，立刻再起 9 台机器，启动要半分钟，同步数据几分钟，然后发现 qps 回到 1000 了，它们又可以下线了。 |
 |
26
rrfeng 141 天前
可以搞。
8 点执行扩容计划，增加节点，增加副本，9 点前 copy 完毕上线。高峰期过了就把临时节点下线。 第二天重复即可。 核心问题是 copy 数据可能会很慢，需要考虑用某种快照方式快速复制数据。 但是我觉得还是可以从业务逻辑上解决更好。 |
 |
27
raycj912 141 天前
可以多给点信息，不然只能给很粗方案。比如加支持 QPS 更高的组件（缓存）、要么就是弹性扩容，估计都不是你想要的
|
 |
28
cloudzhou 141 天前
|
 |
29
dode 141 天前
还是采用超大内存机器吧，3-6 台物理服务器，一天电费是没多少钱。
不是很了解 es 在足够内存和 CPU 情况下，是否有锁限制性能？ k8s 自建 es 服务，定期，启动拉起&关闭服务。 这个 3T 数据能否拆分,提供负载均衡服务 |
|
30
dode 141 天前
用户搜索词都不一样，但是每个用户每天都是一样的搜索词吗，能否预先批计算？
|
|
31
dode 141 天前
非高峰期使用一个普通 ES 服务器，配置 SSD 应该就 OK 了，部署两套。
|
 |
32
yuedingwangji 141 天前
每秒并发 1w ， 真的可怕，这得是什么大项目
|
 |
33
dzdh 141 天前
搜的几个 index mapping 是怎么设计的 最多请求是什么类型的
|
 |
34
yoooooooo 141 天前
1w 的峰值，想自己搞这个弹性伸缩不太现实，想想看这个量级每天都要折腾多少节点，光是数据的迁移和从节点的拷贝要花多长时间，而且你们除了峰值其他时间的访问量比较小，那么每次需要操作的节点应该是非常多的，这个方案不现实。
|
|
35
yoooooooo 141 天前
可以优先从业务角度考虑优化，看有没有优化空间，既然是搜索，为什么搜索词 90%都不会重叠，这个感觉好奇怪
|
 |
36
1018ji 141 天前
感觉不是加机器的问题，先梳理逻辑啊，看看到底啥事瓶颈
加机器解决一切问题，一个集群不够俩集群 |
Select Language