全部产品

常见FAQ

更新时间:2019-07-23 19:38:39

常见FAQ

1. 建立索引的indexer映射配置、collection 配置什么关系?特别是数据类型,indexer映射配置有type,collection的schema也有各种type定义,搞不清楚什么关系?

在“建立索引详细说明”章节中描述过如下映射关系几个配置映射关系如上图,demoindex这个索引实际利用demo.xml配置描述hbase的solrdemo表喝solr的democollection的字段之间的关系。
在这个demo.xml里面,每一个field标签就是描述着一个 solrdemo的info:name列 和 democollection的name_s字段的映射关系;而field标签的type其实指定了这个info:name 列在hbase中是什么格式保存的,比如type=string,表示info:name这个列是 Bytes.toBytes(String)这个方法得来的byte[]数组。相应的,如果type=int、long、boolean等,分别对应Bytes.toBytes(int)、Bytes.toBytes(long)、Bytes.toBytes(boolean)等解析得来。这里要注意,这个type觉得这索引同步时,是否可以正确解析这个byte[]转换为对应类型。所以指定了这个类型之后,插入hbase的对应列的value,就要用对应的Bytes.toBytes方法进行拿到对应的byte[]数组。
对于field里面的name=”name_s”是指定了这个字段在solr中保存的字段名。至于这个字段是什么类型,完全由这个democollection的managed-schema配置文件指定。比如我们这里使用name_s,以”_s”结尾,暗示它是个string类型。类似的还有 _i、_s、_b、_l等,详细见 schema文件描述dynamic 类型部分。当然,我们也可以不是有这种下划线后缀方式暗示类型,而是直接在managed-schema中指定 name_s是什么类型,如下:

  1. <field name="name_s" type="string" indexed="true" stored="true"/>

查看更多schema配置详细说明

2. 索引同步失败,发现同步的document数据是过来了,但是少了几个字段

这种情况主要由于用户配置的类型没有对应,参考“上述1”中描述重新理解一下,并且检查一遍配置是否都对应。
另外,检查是否有字段插入了空值或者非对应type类型的byte[]数组到hbase中对应列了。
举个例子,如:索引demo.xml配置映射关系有如下:

  1. <field name="name_s" value="info:name" type="string"/>
  2. <field name="age_i" value="info:age" type="int"/>

而我实际插入hbase 的info:name的列的字节数组是 Bytes.toBytes(“张三”),插入info:age的列的字节数组是 Bytes.toBytes(“32”)。这个时候,其实age解析就失败了跳过了,不会同步到solr里面。
正确的应该是 Bytes.toBytes(32)拿到的int的4个字节的byte[]插入hbase。

3. 创建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。

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

没有堆积情况下, replication延时主要为框架开销,毫秒级别;如果有积压情况下,延时则不好评估,延时具体情况可以通过 hbase shell的 “status ‘replication’”进行查看,也可以ganglia查看 ageOfLastShippedOp相关指标查看实时延迟情况。
对于solr 的commitWithin默认是15000ms,可以通过配置索引动态生效。具体配置方法为 solr-indexer update/add 中添加 “-w 1000”参数即可,单位是ms。
再写入压力不大,没有积压的情况下,几乎主要决定索引的可见性即为 commitWithin时间,对于写很少的客户可以设置为1秒、3秒、5秒,对于写入量大的用户,不推荐设置过小,不然小文件会比较多,进而系统会频繁merge,也会侧面影响整体性能。

5. 索引同步的TPS是多少?

可以通过查看ganglia的 “Index_adds.${索引名字}” 关键字查找相关指标,例如Index_adds.solrdemoindex.1MinuteRate表示每分钟插入平均速度。

6. 如何清理索引、清理hbase表、清理collection再重来?

经常有用户测试过后,想清理之前的数据再重新进行一遍。常见的就是直接truncate hbase表,delete solr中collection的所有数据。这样其实没有什么问题,但如果原来的wal数据没有同步完,那么这样的truncate之后,其实之前的wal日志还会继续同步。
正确的做法是:删除索引,truncate hbase表,delete solr数据,创建索引。
注:在7.3.1.2版本及之前,删除索引之后需要手动hbase shell清理对应peer,peer id为Indexer_索引名。7.3.1.3版本及之后,不需要会自动清理。
创建索引之后,我们推荐用户list检查一下running个数是否“非0”,确保运行无异常即可。

7. 反复创建删除索引后,发现没有同步数据了?

点开solr webui,查看Dashboard 页确认你的版本是否为7.3.1.2及之前版本,如果是的话,删除索引的同时,需要hbase shell进行主动删除对应 “Indexer_索引名”的peer。具体操作为

  1. list_peers
  2. remove_peer 'Indexer_索引名'


我们推荐你升级到最新版本,后续就不需要主动维护peer的删除了。