全部产品

常见FAQ

更新时间:2020-06-02 17:26:56

创建索引的shard个数、replica个数设置多少合适?

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

  1. 索引的总数据量 > n X m X 21亿

对于一个索引而言,每个服务节点放一个shard开始,即m=1,如果不满足,我们再m = 2、3…直到能满足“索引的总数据量 > n X m X 21亿” 这个公式为止即可。
如果你发现一个服务节点的m的个数太大了,比如超过节点cpu的个数,那就可能要考虑扩容集群或者升配。
4)对于单个shard在条数不能超过 int的最大值,大概21亿的情况下,它的存储也尽量不能太大,如果比如一个shard保存了20亿,按照1k一个doc,总数据量达到2T左右, 这对一个server来说可能会有点大了,对应如果大量扫描估计扛不住,推荐扩容节点,分担大量存储扫描取数据的压力。控制在单个shard的总量数据也不要太大。当然这个要结合查询特点和数据特点,比如单个document就10k和200字节碰到这种情况都是不一样的。
注:shard、replica后期可以调整,但我们建议在创建索引时就设计好。

HBase同步数据到Search索引的延时是多少?多少秒可见?
  1. 索引同步的延时时间 = 数据同步延迟 + commit时间

没有堆积情况下, 同步延时主要为框架开销,毫秒级别(如果有积压情况下,延时会变长,需要增加节点来增加同步能力)
默认commit时间为15s,对于写很少的客户可以设置为1秒、3秒、5秒,对于写入量大的用户,不推荐设置过小,不然小文件会比较多,服务会频繁的执行文件合并操作,影响整体的性能。

如何使用预排序功能?

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

  • 修改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”是不准确的