【问题标题】:Solr scaling multiple instance and shard or multiple solr for different collectionSolr 为不同的集合缩放多个实例和分片或多个 solr
【发布时间】:2018-07-13 06:14:16
【问题描述】:

我是 solr 的新手,并且有一些缩放案例。我计划在 solr 中收集 2 个集合并计划对其进行扩展

  • 歌曲集(主要用于搜索)。目前约 2000 万条数据,每天索引 10 万条数据
  • 流量收集(主要用于稍后分面),目前约 1 亿数据,每天索引 1 百万数据

目前我有 3 个 solrcloud 与 zk 连接,并且由于流量收集的索引数据过多而导致 solr 关闭的情况很少见。

哪一个对性能都有好处,而且服务器只有 3 个服务器,每个是 32x3GB RAM 和 16 核(共享)

  • 使用多个实例部署 solrcloud,即我有 6 个 solr 与 zk 连接
  • 部署多个 solrcloud 和分离的集合,
    • 3 solr with zk 仅用于歌曲收藏
    • 另外 3 个带有 zk 的 solr 仅用于流量收集(这个与前一个分离的 solr)

或者任何其他解决方案。

【问题讨论】:

    标签: solr


    【解决方案1】:

    您应该考虑在可管理的范围内保持单个集群。但是您可以改进处理流量收集的方式(歌曲收集听起来不错):

    • 以这种速度,最终对于单个集合来说太大了
    • 显示为什么不在每日/每周/或每年的集合中索引流量?
    • 您的集合将保持可管理的大小,并且在查询时您的效率会更高,因为您无需查询整个历史记录,只需查询最后一天、上个月等

    这是一个非常频繁的设置。

    【讨论】:

    • 那么,单集群云中的歌曲+收藏更受欢迎?每天/每周意味着仅从每天/每周恢复模型数据,还是所有数据将每天/每周(即凌晨 3 点)索引?
    • 不,我的意思是收集 1 首歌曲,以及每天收集 1 次流量(而不是每天,可以是每周或每月等)。
    • 哦。如果我分成每月收集,即收集已经1y.o。如果 solr 中有很多集合,是否会影响性能?还是我应该归档它们?
    • 存在一个集合太多的点,但是拥有例如 100 个集合不会有问题(关于集合本身的数量),所以当它开始成为一个问题,然后您可以移动到新集群或将它们归档/将它们折叠成更少
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-01-20
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多