全部产品
云市场

常见FAQ

更新时间:2019-12-16 17:26:35

常见FAQ

创建solr collection的shard个数、replica个数设置多少合适?

我们先列举一下几条规则,尽量满足如下规则即可:
1)单个shard的最大document条数不能超过 int的最大值,大概21亿。否则就会因lucene底层循环复用int值而导致覆盖。
2)对于replicationFactor副本数,我们推荐默认设置为1,并且把autoAddReplicas属性设置为false。对于有特殊要求的,比如写入非常少,读非常多,且读可能会有大量热点,那可以考虑使用replicationFactor=2、3这种,可以缓解读负载均衡。
3) 我们假设实例有n个solr server节点,每个节点放m个shard。我们得遵循如下公式:

  1. 这个collection未来的总数据量 > n X m X 21亿

对于一个collection而言,每个solr server节点放一个shard开始,即m=1,如果不满足,我们再m = 2、3…直到能满足“未来collection的总数据量 > n X m X 21亿” 这个公式为止即可。
如果你发现一个server要放的m的个数太大了,比如超过物理linux机器cpu的个数了,那就可能要考虑扩容节点了。推荐一个solr server节点尽量不要太多相同collection的shard
4)对于单个shard在条数不能超过 int的最大值,大概21亿的情况下,它的存储也尽量不能太大,如果比如一个shard保存了20亿,按照1k一个doc,总数据量达到2T左右, 这对一个server来说可能会有点大了,对应如果大量扫描估计扛不住,推荐扩容节点,分担大量存储扫描取数据的压力。控制在单个shard的总量数据也不要太大。当然这个要结合查询特点和数据特点,比如单个document就10k和200字节碰到这种情况都是不一样的。
注:对于solr的shard、replica分配,是可以后期再调整和split的,按照上述设置之后,后续有变化再调整也可以。另外,我们推荐用户后续如果需要调整shard、replica个数的,请联系“云hbase答疑”进行沟通,在solr在solr 7.3.1.4版本之前,请勿自行split shard。

hbase同步数据到solr索引的延时是多少?多少秒可见?
  1. 索引同步的延时时间 = 数据同步延迟 + solr commitWithin时间

没有堆积情况下, 同步延时主要为框架开销,毫秒级别(如果有积压情况下,延时会变长,需要增加节点来增加同步能力)
对于solr 的commitWithin,默认是15000ms。再写入压力不大,没有积压的情况下,几乎主要决定索引的可见性即为 commitWithin时间,对于写很少的客户可以设置为1秒、3秒、5秒,对于写入量大的用户,不推荐设置过小,不然小文件会比较多,进而系统会频繁merge,也会侧面影响整体性能。

Solr如何使用预排序功能?

我们都知道排序是非常消耗资源的,在数据量特别大的时候,不仅查的慢,还特别占用系统资源,如果本身存储的数据已经按照某个字段预先排好序,那么solr的检索会有明显的提升,特别是在大数据量上对比的时候,此特点效果更明显。那么在solr层面是怎么支持的呢?下面我们简单描述下步骤:

  • 修改solrconfig.xml中的MergePolicy, 详见链接
  • 查询时,指定参数segmentTerminateEarly=true即可
    下面简单给个demo演示:
    1. <mergePolicyFactory class="org.apache.solr.index.SortingMergePolicyFactory">
    2. <str name="sort">timestamp desc</str>
    3. <str name="wrapped.prefix">inner</str>
    4. <str name="inner.class">org.apache.solr.index.TieredMergePolicyFactory</str>
    5. <int name="inner.maxMergeAtOnce">10</int>
    6. <int name="inner.segmentsPerTier">10</int>
    7. </mergePolicyFactory>
    此时,我们主要关心“< str name=”sort”>timestamp desc< /str>”配置,此时插入数据将会按照timestamp字段进行预先倒序排序,执行查询如下:
    1. curl "http://localhost:8983/solr/testcollection/query?q=*:*&sort=timestamp+desc&rows=10&segmentTerminateEarly=true"
    参数上加上“segmentTerminateEarly=true”后,显示效果会比没有设置预排序的快很多,尤其是排序数据量T级别之后,效果更明显。

需要注意的是:

  • 查询时,指定的sort必须与配置的MergePolicy中指定的一致,否则不起效果
  • 查询时需要指定segmentTerminateEarly参数,否则也会进行全排
  • 使用了这个预排序返回的结果中,“numFound”是不准确的
关于solr的各种客户端连接使用说明

在云hbase 全文服务solr的使用中,我们一共提供了几个地址:zk内网地址、和zk公网地址、solr的webui公网地址、solr的CloudSolrClient连接地址。下面分别描述这几种地址的使用:

  • solr CloudSolrClient内网链接地址cloudSolrClient访问地址

见上图,作为java api 中 CloudSolrClient的内网访问地址,此时CloudSolrClient的构造方法如下:

  1. List<String> zkHostList = new ArrayList<>();
  2. zkHostList.add("
  3. hb-m5eXXXX-master1-001.hbase.rds.aliyuncs.com:2181");
  4. zkHostList.add("
  5. hb-m5eXXXX-master2-001.hbase.rds.aliyuncs.com:2181");
  6. zkHostList.add("
  7. hb-m5eXXXX-master3-001.hbase.rds.aliyuncs.com:2181");
  8. CloudSolrClient cloudSolrClient = new Builder(zkHostList, Optional.of("/solr");

注意,替换“hb-m5eXXXX…..” 为你的对应zk 单个host地址。

  • solr webui公网地址,见如下图solr webui地址

如上图,直接点击即可打开solr WebUI,其访问控制和hbase WebUI一样,详见文档链接
注意这个仅为公网浏览器打开的solr admin WebUI访问地址,不能用其浏览器显示的url进行solr数据访问。

  • solr HttpSolrClient、curl 公网单点开发测试访问地址solr公网访问地址如上图,当用户在“数据库链接”中,也打开 zk公网时,同样solr也具备了公网开发测试的单点访问功能,其开通的节点为 关键字带有“master3-1”的 host名字。如这里为的公网单点访问地址为:
    1. http://hb-proxy-pub-m5eXXXX-master3-001.hbase.rds.aliyuncs.com:8983
    此时,如果想公网访问solr进行开发测试,命令行运维是可以直接类似如下即可:
    1. curl "http://hb-proxy-pub-m5eXXXX-master3-001.hbase.rds.aliyuncs.com:8983/solr/admin/collections?action=list"
    如果是想公网通过java api的HttpSolrClient单点公网开发测试访问solr,可以初始化实例如下:
    1. HttpSolrClient solrClient = new HttpSolrClient.Builder("http://hb-proxy-pub-m5eXXXX-master3-001.hbase.rds.aliyuncs.com:8983/solr").build();
    注意,solr的路由核心是在server端的,所以客户端访问任何一个节点都可以访问整个集群,当然如果您是内网访问solr集群,推荐使用CloudSolrClient api,它会有一些负责均衡相关的功能,这里的HttpSolrClient仅推荐用来做开发测试使用。