如果有多个业务的多个垂搜，是建议单集群混部还是每个垂搜一个小的es集群？
感觉单集群的话，各个业务之间的搜索服务会不会相互影响？比如一个业务的慢查询影响了其他业务？
每个垂搜一个小的es集群的话，维护成本比较大吧，目前有没有开源的es集群平台管理方案，能按业务对es集群节点进行上下线？
感觉单集群的话，各个业务之间的搜索服务会不会相互影响？比如一个业务的慢查询影响了其他业务？
每个垂搜一个小的es集群的话，维护成本比较大吧，目前有没有开源的es集群平台管理方案，能按业务对es集群节点进行上下线？
9 个回复
JackGe
赞同来自: exceptions
laoyang360 - 《一本书讲透Elasticsearch》作者，Elastic认证工程师 [死磕Elasitcsearch]知识星球地址：http://t.cn/RmwM3N9；微信公众号：铭毅天下; 博客：https://elastic.blog.csdn.net
赞同来自: intergret
推荐阅读：https://www.loggly.com/blog/sc ... ster/
Tyler
赞同来自:
zqc0512 - andy zhou
赞同来自:
多几个索引而已，
一般cross cluster 是单个集群有瓶颈，节点数过多，master调度有压力等 才拆开的。
多个小集群性能一般比一个单集群性能高，我的理解是master调度算法的问题。
hufuman
赞同来自:
也没有必要一定要一个搜索一个集群，预算确实多请告诉我哪个公司
God_lockin
赞同来自:
如果数据量不大，机器也不多，就直接单集群+多索引，这样不管人肉还是自研系统的运维比较方便
如果数据量大，机器多，包括吞吐计算的比较多，就拆多集群
还有就是有时候有的业务数据是需要对外保密对其他人隔离的，这个时候可以考虑单独做个集群，通过xpack或者ip绑定等各种方式做隔离就好
dengwx
赞同来自:
多租户集群要的事情还是比较多的，从查询角度，业务流控、隔离，还有一些比较危险的操作都需要关注，最好自己搞一个proxy分发query；从数据角度，索引管理，包括重建、分片等等都会对集群稳定性造成影响。
多集群的问题是要虚拟化，否则成本会很高。另外集群运维也不能忽视，集群多了，扩容、更新都是需要自动化掉的。
lei2018
赞同来自:
建议单集群 然后es实例可以一台物理机部署多个 然后限制每个实例的processors 和search线程数 我估计你入库量应该不大， 索引每个业务如果数据量不大可以每个业务一个索引 或者两三个业务一个索引 并只配1个shard，这样单个索引对资源的消耗能限制住，cpu 内存 膨胀率都会节省，然后观察效果看哪些索引是搜索统计比较频繁的 再做相应调整，search节点单独部署，避免因为内存问题影响索引。
几十个索引的查询负载正常应该很轻的，除非是比较坑的那种查询或统计
intergret
赞同来自: