有数十个垂搜实例的话,是建议单集群混部还是每个垂搜一个小的es集群

作者 intergret | 发布于2018年09月03日 | 阅读数:276

如果有多个业务的多个垂搜,是建议单集群混部还是每个垂搜一个小的es集群?
 
感觉单集群的话,各个业务之间的搜索服务会不会相互影响?比如一个业务的慢查询影响了其他业务?
 
每个垂搜一个小的es集群的话,维护成本比较大吧,目前有没有开源的es集群平台管理方案,能按业务对es集群节点进行上下线?
已邀请:

JackGe

赞同来自: exceptions

单机群混布还是独立部署,主要还是为了解决业务隔离问题。如果能做到业务隔离的话,可以单集群混布,减少运维成本。

laoyang360 - [死磕Elasitcsearch]知识星球地址:http://t.cn/RmwM3N9;微信公众号:铭毅天下; 博客:blog.csdn.net/laoyang360

赞同来自: intergret

单集群部署切换多集群,前提:你遇到了单集群的性能瓶颈,你的集群状态出了问题,你想升级集群提升性能(同时又不想单纯的扩充节点、不想重启),这时候可以考虑多集群。
推荐阅读:https://www.loggly.com/blog/sc ... ster/

Tyler

赞同来自:

从维护成本角度来说,建议用单集群混部署,同时,可以在 ES 上层加个 API 层,该 API 层可以做好相关限制,比如翻页大小、请求QSP 等

zqc0512 - andy zhou

赞同来自:

关键问题是单集群刚不刚得住,刚得住就一起撒,
多几个索引而已,
一般cross  cluster 是单个集群有瓶颈,节点数过多,master调度有压力等 才拆开的。
多个小集群性能一般比一个单集群性能高,我的理解是master调度算法的问题。
 

hufuman

赞同来自:

分压力和重要性分集群,比方说应用分出重要和一般重要的,重要的一个集群,非重要的一个,至少做两个吧

也没有必要一定要一个搜索一个集群,预算确实多请告诉我哪个公司

God_lockin

赞同来自:

我的理解是这样,不一定对哦
 
如果数据量不大,机器也不多,就直接单集群+多索引,这样不管人肉还是自研系统的运维比较方便
如果数据量大,机器多,包括吞吐计算的比较多,就拆多集群
还有就是有时候有的业务数据是需要对外保密对其他人隔离的,这个时候可以考虑单独做个集群,通过xpack或者ip绑定等各种方式做隔离就好

dengwx

赞同来自:

主要是稳定性和运维成本的问题。
多租户集群要的事情还是比较多的,从查询角度,业务流控、隔离,还有一些比较危险的操作都需要关注,最好自己搞一个proxy分发query;从数据角度,索引管理,包括重建、分片等等都会对集群稳定性造成影响。
多集群的问题是要虚拟化,否则成本会很高。另外集群运维也不能忽视,集群多了,扩容、更新都是需要自动化掉的。

lei2018

赞同来自:

楼上说得对 集群前面要有个对查询任务调度管理的中间件 对查询按优先级调度管理 并可以限制请求的并发数
建议单集群 然后es实例可以一台物理机部署多个 然后限制每个实例的processors  和search线程数 我估计你入库量应该不大, 索引每个业务如果数据量不大可以每个业务一个索引 或者两三个业务一个索引 并只配1个shard,这样单个索引对资源的消耗能限制住,cpu 内存 膨胀率都会节省,然后观察效果看哪些索引是搜索统计比较频繁的 再做相应调整,search节点单独部署,避免因为内存问题影响索引。
几十个索引的查询负载正常应该很轻的,除非是比较坑的那种查询或统计

intergret

赞同来自:

考虑了一下还是每个垂搜一个cluster,但各个cluster会共用机器,主要还是怕相互影响,分进程应该好一些

要回复问题请先登录注册