GBase 8a全文索引常用配置文件和配置参数

本文介绍GBase 8a的全文索引功能相关的配置文件位置，各参数含义，以及对功能、性能优化的影响等。

参考

GBase 8a全文索引功能安装部署方法
GBase 8a全文索引创建、更新和删除方法
GBase 8a全文索引常用配置文件和配置参数
GBase 8a全文索引提高模糊查询性能使用样例
GBase 8a全文索引多分词器的功能介绍和使用

配置文件位置

该配置文件在 coordinator 节点和 data 节点上的路径分别如下。其中GbaseCharExt.xml是索引功能相关，gbfticfg.xml索引性能相关。其余的是元数据，比如支持的文件类型之类的，不要改动。

$GCLUSTER_HOME/lib/gbase/plugin/gbfti/cfg/
$GBASE_HOME/lib/gbase/plugin/gbfti/cfg/

[gbase@gbase_rh7_001 cfg]$ ll
total 20
-rw-r--r--. 1 gbase gbase 853 Jan 23 18:36 filter.xml
-rw-r--r--. 1 gbase gbase 161 Jul  1 09:24 GbaseCharExt.xml
-rw-r--r--. 1 gbase gbase 637 Jan 23 18:36 gbfticfg.xml
-rw-r--r--. 1 gbase gbase 550 Jan 23 18:36 mime.xml
-rw-r--r--. 1 gbase gbase 399 Jan 23 18:36 scheme.xml
[gbase@gbase_rh7_001 cfg]$

GbaseCharExt.xml

样例

如下是安装后的默认值。

[gbase@gbase_rh7_001 cfg]$ cat GbaseCharExt.xml
<?xml version="1.0" encoding="UTF-8"?>
<segment>
  <multisegmask>0</multisegmask>
  <mixedcase>0</mixedcase>
  <step>0</step>
  <dict>0</dict>
</segment>
[gbase@gbase_rh7_001 cfg]$

multisegmask 分词类型

中文都是按字分词，如下实际效果只针对字母和数字的。

• 0：自然分词；默认。自然分词就是按照文本的类型分词，通过空格和标点符号自然分开；
• 1：数字多元分词；
• 2：英文多元分词；

该参数是按位与的方式，只要配置数字的低位为1，则对应分词开启。比如3，就是同时开启数字和英文的分词。

mixedcase 是否区分大小写

主要针对英文字母。 对应配置项参数如下（

• 0：不区分；默认
• 1：区分

step 分词步长

0：默认值,等同于3元分词。其它大于0的为实际步长，最大127。

• 三元：字符串12345，会分成123，234，345；
• 二元：字符串12345，会分成12，23，34，45。

分词越小，拆分越多，额外占用的磁盘空间也就越多，对应的，查询性能也会有降低。但真的需要很短的检索吗？因为该参数是全局的，也许太短的值，特意弄长一些对整体性能和磁盘占用更好一些。

三元分词例子

可以查到3个连续数字的，但2个的查不到。

gbase> select t1.* from t1 where contains(memo,'123');
+------+------+------+------------+---------------------+
| id   | name | dept | birth      | memo                |
+------+------+------+------------+---------------------+
|    5 | Test |    3 | 1895-10-02 | Test12345678abcdefg |
+------+------+------+------------+---------------------+
1 row in set (Elapsed: 00:00:00.01)

gbase> select t1.* from t1 where contains(memo,'12');
Empty set (Elapsed: 00:00:00.01)

二元分词例子

可以检索到连续2个数字或字母，但1个的检索不到。但真的需要检索1个或2个吗？

gbase> select t1.* from t1 where contains(memo,'12');
+------+------+------+------------+---------------------+
| id   | name | dept | birth      | memo                |
+------+------+------+------------+---------------------+
|    5 | Test |    3 | 1895-10-02 | Test12345678abcdefg |
+------+------+------+------------+---------------------+
1 row in set (Elapsed: 00:00:00.16)

gbase> select t1.* from t1 where contains(memo,'1');
Empty set (Elapsed: 00:00:00.01)

dict 是否使用字典

字典需要使用工具datriedict生成。【TODO】待补充用例。

gbfticfg.xml

[gbase@gbase_rh7_001 cfg]$ cat gbfticfg.xml
<?xml version="1.0" encoding="UTF-8"?>
<gbfticfg>
  <hitFlush>64M</hitFlush>
  <segThreads>4</segThreads>
  <sortThreads>4</sortThreads>
  <outThreads>3</outThreads>
  <maxDocPerUnit>100000000</maxDocPerUnit>
  <maxLineSize>2</maxLineSize>
  <reduceMemMode>0</reduceMemMode>
  <dictDynamicLoad>0</dictDynamicLoad>
  <dictSlotPerUnit>16777216</dictSlotPerUnit>
  <quickUpdate>0</quickUpdate>
  <match>
    <maxMatch>128</maxMatch>
    <maxThreadPerTask>5</maxThreadPerTask>
  </match>
  <segment>
    <name>GBaseCharExt</name>
    <dsoPath>..//lib//libGbaseCharExt.so</dsoPath>
    <outCharset>UTF-8</outCharset>
  </segment>
</gbfticfg>
[gbase@gbase_rh7_001 cfg]$

hitFlush

单次分词任务最大hit数量。默认64MB

dictSlotPerUnit 字典哈希桶数

全文索引的字典采用静态哈希结构存储，当单词数过多时会导致字典的冲突链非常长，而更新索引需要多次查询字典，冲突链过长会导致更新速度急剧变慢。缺省哈希桶长度为 65536*256=16777216。

理论上该值越大效率越高，但内存也随之增大，需要综合考虑。

quickUpdate 快速更新模式开关

更改全文索引的哈希桶数能够有效提升更新全文索引的速度，但当字典中单词数过多，文档内容过大（尤其 URI 模式）仍然不能满足用户的需求，可以采用该模式。该模式下索引数据采用多文件并发写入，能够有效解决 IO 等待瓶颈，从而使速度大大提高。

• 0：不快速更新；
• 1：快速更新

该参数需要配合如下3个参数使用以达到性能调整目的。推荐使用CPU核数*3/4, 但还是要根据实际情况调整。

segThreads

分词线程数量，默认4

sortThreads

排序线程数量，默认4

outThreads

输出线程数量，默认3

maxDocPerUnit

单个子库最大行数，默认100000000， 超过后会自动分库。

maxLineSize

单行最大文本。【TODO 还没看懂】

reduceMemMode

全文索引数据占用内存是比较多的（尤其是单词数大的时候），全文索引数据从磁盘读入内存是一个相对比较耗时的操作，当用户的服务器内存比较大的时候建议采用常驻内存模式（缺省模式），这样节约了加载时间，从而提高性能。对应配置项参数如下

• 0：常驻内存； 默认
• 1：不常驻内存

dictDynamicLoad

字典数据的动态加载。

maxMatch

最大搜索并发数

maxThreadPerTask

每个搜索任务的并行度

dsoPath

分词器实现的动态库

outCharset

分词器输出的字符集