本文介绍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
分词器输出的字符集