SuMingXuan (苏铭轩)

浅析 PostgreSQL + zhparser 进行中文搜索的分词与排序优化

SuMingXuan — Fri, 10 Nov 2023 20:49:44 +0800

背景

之前在做 gitlab resource center 搜索功能时，初版上线的搜索结果未能令人满意。因此便开始着手对分词和排序进行了改进。

在第一版搜索功能上线后，当输入关键字安全高效和安全时，系统能够正确返回相关文章。然而，在搜索高效关键字时，却发现返回的文章为空。期望的功能是，只要文章标题、内容或描述中包含关键字高效，就能够返回相关结果。

分词

首先我们看看怎么在 PostgreSQL 中启用 zhparser 插件的：

CREATE EXTENSION IF NOT EXISTS zhparser;
DROP TEXT SEARCH CONFIGURATION IF EXISTS chinese_zh;
CREATE TEXT SEARCH CONFIGURATION chinese_zh (PARSER = zhparser);
ALTER TEXT SEARCH CONFIGURATION chinese_zh ADD MAPPING FOR a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z WITH simple;

这里的 a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z 均对应了一种词性。

下面是词性的关系映射表，先列举出来，用于我们后面分析。

(97,  a, "adjective,        形容词")
(98,  b, "differentiation,  区别词")
(99,  c, "conjunction,      连词")
(100, d, "adverb,           副词")
(101, e, "exclamation,      感叹词")
(102, f, "position,         方位词")
(103, g, "root,             词根")
(104, h, "head,             前连接成分")
(105, i, "idiom,            成语")
(106, j, "abbreviation,     简称")
(107, k, "tail,             后连接成分")
(108, l, "tmp,              习用语")
(109, m, "numeral,          数词")
(110, n, "noun,             名词")
(111, o, "onomatopoeia,     拟声词")
(112, p, "prepositional,    介词")
(113, q, "quantity,         量词")
(114, r, "pronoun,          代词")
(115, s, "space,            处所词")
(116, t, "time,             时语素")
(117, u, "auxiliary,        助词")
(118, v, "verb,             动词")
(119, w, "punctuation,      标点符号")
(120, x, "unknown,          未知词")
(121, y, "modal,            语气词")
(122, z, "status,           状态词")

我们直接通过 zhparser 分词策略分词之后的看看他的返回结果

SELECT * FROM ts_parse('zhparser', '这种将安全高效整合进研发和运维流程中的安全构建方式');

 tokid |  token
-------+----------
   114 | 这种
   100 | 将
   110 | 安全高效
   118 | 整
   110 | 合进
   106 | 研发
    99 | 和
   118 | 运
   113 | 维
   110 | 流程
   102 | 中
   117 | 的
    97 | 安全
   118 | 构建
   110 | 方式
(15 rows)
-- 对应的词性可以在上面的关系映射表里面看

此时 zhparser 会拆分出 安全高效 和 安全 这两个词，并没有拆分出我们所需要的 高效 关键词。

zhparser 有以下配置，且所有配置默认值均为 false。

zhparser.punctuation_ignore = f #忽略所有的标点等特殊符号: 
zhparser.seg_with_duality = f #闲散文字自动以二字分词法聚合: 
zhparser.dict_in_memory = f #将词典全部加载到内存里: 
zhparser.multi_short = f #短词复合: 
zhparser.multi_duality = f #散字二元复合: 
zhparser.multi_zmain = f #重要单字复合: 
zhparser.multi_zall = f #全部单字复合:

因为 zhparser 插件是一个基于 SCWS 能力开发的 PG 中文分词插件。所以我们可以去 SCWS 在线测试平台根据需要做一些调整。最终我们决定将短词复合配置打开。有以下两种方式去配置（具体怎么应用看对应的云服务商怎么方便处理。）：

修改 postgresql.conf 文件配置

将 zhparser.multi_short = true 添加到 postgresql.conf 文件中，然后进入数据库执行 SELECT pg_reload_conf(); 使 PostgreSQL 重新加载配置文件。

通过 sql 命令配置

SELECT set_config('zhparser.multi_short', 'true', false);
ALTER SYSTEM SET zhparser.multi_short = true;
SELECT pg_reload_conf();

需要注意：执行 sql 必须是原生的 superuser 权限，并且执行 sql 的时候不能在事务中运行

将以上配置完毕之后再来看看 zhparser 分词结果是什么

SELECT * FROM ts_parse('zhparser', '这种将安全高效整合进研发和运维流程中的安全构建方式');

 tokid |  token
-------+----------
   114 | 这种
   100 | 将
   110 | 安全高效
    97 | 安全
   100 | 高效
   118 | 整
   110 | 合进
   106 | 研发
    99 | 和
   118 | 运
   113 | 维
   110 | 流程
   102 | 中
   117 | 的
    97 | 安全
   118 | 构建
   110 | 方式
(17 rows)
-- 对应的词性可以在上面的关系映射表里面看

此时高效关键词已经被拆分出来了，并且它是副词词性，接下来调整下 chinese_zh 的策略，只保留我们需要的词性

-- 删除分词策略：

ALTER TEXT SEARCH CONFIGURATION chinese_zh DROP MAPPING IF exists FOR a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z;

-- 添加分词策略：
-- 添加名词（n）、动词（v）、形容词（a）、成语（i）、叹词（e）、习用语（l）和副词（d）七种分词策略：
ALTER TEXT SEARCH CONFIGURATION chinese_zh ADD MAPPING FOR n,v,a,i,e,l,d WITH simple;

然后观察 chinese_zh 的分词结果


SELECT to_tsvector('chinese_zh',  '这种将安全高效整合进研发和运维流程中的安全构建方式');
                                to_tsvector
---------------------------------------------------------------------------------------------
 '合进':6 '安全':3,9 '安全高效':2 '将':1 '整':5 '方式':11 '构建':10 '流程':8 '运':7 '高效':4
(1 row)

-- 每个单词后面跟随了对应的位置信息

至此我们分词调整策略基本告一段落，主要做两个事情

修改 zhparser 的配置
修改自定义 chinese_zh 分词策略所保留的词性

除此之外 zhparser 还支持自定义词库，所有的自定义词都放在了 zhprs_custom_word 表里面，默认添加的自定义词的词性是 (120, x, "unknown, 未知词")，可能用到的 sql 包含但不局限于如下：

-- 添加自定义词
insert into zhparser.zhprs_custom_word values('资金压力');
-- 自定义词库也支持停止词功能，例如我们不希望词语'这是'单独作为一个分词，同样可以在自定义词库中插入对应的词语和控制符停止特定分词：
insert into zhparser.zhprs_custom_word(word, attr) values('这是','!');

-- 添加/删除自定义分词之后需要执行以下命令才能使词库生效
select sync_zhprs_custom_word();

-- 查询已存在的自定义词库
select * from zhparser.zhprs_custom_word;

排序

PostgreSQL 有权重赋值的方法 setweight 当然在 pg_search 中也集成了该接口，便于直接使用。

权重设置分别可以设定为 A B C D，默认值为 A

假设权重用数字来评判的话（满分为 1 分）他们之间的梯度关系如下所示：

权重	对应系数
A	1
B	0.4
C	0.2
D	0.1

--- 设置权重为 A
select ts_rank(setweight(to_tsvector('chinese_zh', '这种将安全高效整合进研发和运维流程中的安全构建方式'), 'A'), (to_tsquery('chinese_zh', '高效')), 0);
  ts_rank
-----------
 0.6079271

--- 设置权重为 B

select ts_rank(setweight(to_tsvector('chinese_zh', '这种将安全高效整合进研发和运维流程中的安全构建方式'), 'B'), (to_tsquery('chinese_zh', '高效')), 0);
  ts_rank
------------
 0.24317084
(1 row)

--- 设置权重为 C

select ts_rank(setweight(to_tsvector('chinese_zh', '这种将安全高效整合进研发和运维流程中的安全构建方式'), 'C'), (to_tsquery('chinese_zh', '高效')), 0);
  ts_rank
------------
 0.12158542

--- 设置权重为 D

select ts_rank(setweight(to_tsvector('chinese_zh', '这种将安全高效整合进研发和运维流程中的安全构建方式'), 'D'), (to_tsquery('chinese_zh', '高效')), 0);
  ts_rank
------------
 0.06079271

这样的话我们便可以将文章的标题、描述、内容的权重分别设置为 A, B, C，以此算出一个综合的分数来做排序。但这种计算出来的分数只会和词频相关。

-- A 代表权重，0 代表使用的关注度配置
select ts_rank(setweight(to_tsvector('chinese_zh', '高效'), 'A'), (to_tsquery('chinese_zh', '高效')), 0);
  ts_rank
-----------
 0.6079271
--  即使文档长度很小，最终计算出来的分数依然是 0.6079271

由于较长的文档包含查询词的几率更高，因此可能还需要考虑文档的长度，例如具有五个搜索词实例的一百字文档可能比具有五个搜索词实例的千字文档更相关。

所以在此基础上我们需要引入 PostgreSQL 的 normalization 参数

具体怎么配置需要根据业务去调整，我们主要根据文档的长度做了些调整。

#   normalization 查询结果关注度:
#   0（缺省）表示跟长度大小没有关系
#   1 表示关注度（rank）除以文档长度的对数+1
#   2 表示关注度除以文档的长度
#   4 表示关注度除以范围内的平均谐波距离，只能使用ts_rank_cd实现。
#   8 表示关注度除以文档中唯一分词的数量
#   16 表示关注度除以唯一分词数量的对数+1
#   32 表示关注度除以本身+1

测试一下长文本（由于文本太长这里就不贴出来了）和短文本之间的使用不同的 normalization之后分数的差距。

文本长度	normalization	分数
3887	0	0.6079271
1087	0	0.6079271
3887	1	0.057773568
1087	1	0.06928112
3887	2	0.00041355583
1087	2	0.0013911375

相对来说 normalization 为 1 时，分数变化随着文章长度越长，变化曲率越平滑。

至此我们排序策略基本告一段落，主要做两个事情

为文章的标题、描述、内容分别设置不同的权重
设置对应的 normalization 值

当然 pg_search 上面还有更多的开箱即用的搜索的配置，这里就不再一一阐述了

参考

SCWS

zhparser

Postgres Fulltext Search (一)

Postgres Full Text Search with Docker Compose

【实操系列】如何通过云原生数据仓库实现“一站式全文检索”业务（链接触发到敏感词，原文可能需要自行搜索一下）

simple_combine_xls - 让你合并表格就像画图一样

SuMingXuan — Fri, 26 Mar 2021 13:37:13 +0800

使用

simple_combine_xls 让你合并表格就像画图一样

在使用 simple_combine_xls 之前你必须得知道 ruby 中的 object_id 概念

没错 simple_combine_xls 是基于你分配的 object_id 去合并的单元格，只要单元格的 object_id 相同就会合并在一起

如果你了解 object_id 之后就能很快的去合并一个单元格

示例

你必须传一个二维数组给 simple_combine_xls

city1, city2, city3 = "成都", "南充", "自贡"
spec = "特色"
# menu1, menu2, menu3 的 object_id 都是不同的
menu1, menu2, menu3 = "菜单", "菜单", "菜单"
scenic = "景点"
# 下面的 nil 将不会合并在一起
datas = [
  [spec,     spec,      spec,    spec,         spec],
  [city1,    menu1,    "串串",  scenic,      "春熙路"],
  [city1,    menu1,      nil,  scenic,      "黄龙溪"],
  [city1,    menu1,    "火锅",  scenic, "各种免费景点"],
  [city2,    menu2,    "米粉",  scenic,    "蓝天网吧"],
  [city2,    menu2,    "锅盔",  scenic,    "鼎盛网吧"],
  [city2,    menu2,      nil,  scenic,    "五星网吧"],
  [city2,    menu2,      nil,  scenic,    "各种网吧"],
  [city3,    menu3,  "鲜锅兔",  scenic,     "7天酒店"],
  [city3,    menu3,  "冷吃兔",  scenic,    "汉庭酒店"],
  [city3,    menu3,  "各种兔",  scenic,          nil],
  [city3,    menu3,"富顺豆花",  scenic,          nil]
]

使用 drawing 方法去合并单元格

simple_combine_xls = SimpleCombineXls.new(datas)
simple_combine_xls.drawing

# 合并之后 simple_combine_xls.xls 其实就是一个 spreadsheet
simple_combine_xls.xls.write './asd.xls'

# 如果你想对表格进行一个样式操作请查看 https://github.com/zdavatz/spreadsheet

以上代码将会生成这样的单元格

注意

simple_combine_xls 将会吧所有的对象都转化成字符串去操作
simple_combine_xls 默认的占位符是 " " (一个空格)
在 ruby 中空字符串的 object_id 是一致的，所以在你需要考虑到 nil.to_s 可能会合并一些单元格

@str = "test"
arr1 = [@str, @str, @str]
arr2 = ["test", "test", "test"]
# 对于 simple_combine_xls 来说 arr1 和 arr2 是完全不同的
# 因为 arr1.map(&:object_id) != arr2.map(&:object_id)

Logisticed - 轻松记录操作人员和操作时间

SuMingXuan — Wed, 27 Jan 2021 18:52:14 +0800

很多系统的数据变更状态都可能会记录变更的操作人以及操作时间。写这个的原因是没有找到相关功能的 gem，于是自己写了这个 gem。也希望对部分有需求的开发者们有帮助

补充更新： audited 更侧重于对历史数据的收集， logisticed 更侧重于对精准数据的变更记录，侧重点不一样。

介绍

Logisticed 可以让你在 Controller 中无感知的记录 操作人 和 操作时间 （其实也是模仿 audited 去实现的）

Installation

Add this line to your application's Gemfile:

gem 'logisticed'

Then, from your Rails app directory, create the logistics table:

$ rake logisticed_migration:install:migrations
$ rails db:migrate

Usage

你只需要告诉 logisticed 需要监听什么字段，并且被修改为什么值的时候就行了。

class Page < ActiveRecord::Base
  logisticed :status, values: [:active, :archived]
end

# 他将会为你提供 `active_at`、 `active_by`、 `archived_at`、 `archived_by` 这几个方法，为你提供某个状态最近的操作历史

如果在 model 中定义了枚举类型的字段，也可以在定义枚举的下面直接添加 logisticed，他会自动为你监听枚举的所有值，同时 logisticed 支持 only 和 except 这两个参数

class Page < ActiveRecord::Base
  enum status: [:draft, :active, :archived]
  logisticed :status, only: [:active, :archived]
end

现在就已经可以监听所有的操作人和操作时间等信息了

class PagesController < ApplicationController
  def create
    current_user # => #<User name: 'sss'>
    @page = Page.first # => #<Page status: 'draft'>
    @page.active!
    @page.active_at # => 2021-01-22 17:15:13 +0800
    @page.active_by # => #<User name: 'sss'>
  end
end

当然你也可以使用 @page.logistics 得到 @page 这条记录的所有变更流程，也可以使用 @page.active_logistics 得到状态变为 active 的所有变更流程

除此之外你也可以使用 as_user 制定某个用户成为操作人员

class PagesController < ApplicationController
  def create
    current_user # => #<User name: 'sss'>
    user = User.last # => #<User name: 'smx'>
    Logisticed::Logistic.as_user(user) do
      @page = Page.first # => #<Page status: 'draft'>
      @page.active!
      @page.active_at # => 2021-01-22 17:15:13 +0800
      @page.active_by # => #<User name: 'smx'>
    end
  end
end

setting

# config/initializers/logisticed.rb

Logisticed.config do |config|
  config.current_user_method                = :authenticated_user
  # if your table primary_key type is uuid
  config.logisticed_source_id_column_type   = :uuid
  config.logisticed_operator_id_column_type = :uuid
end

项目地址

https://github.com/SuMingXuan/logisticed

hash_map_attributes 将 JSON 类型的字段映射为具体的方法，方便 CRUD

SuMingXuan — Wed, 04 Nov 2020 18:29:20 +0800

项目地址：

https://github.com/SuMingXuan/hash_map_attributes/

写这个插件是因为目前在我做写业务的时候，需要预留一个 json 字段方便以后数据的扩展，并且方便 CRUD。比如我有一个 pages 表包含了一个 jsonb 类型的字段（extra_data），extra_data 里面可能存很多额外的属性或者是目前我们没有考虑到的属性。让我痛苦的是，对这种类型的字段操作 CRUD 会让代码变得非常难看。

Usage

class Page < ApplicationRecord
    # == Schema Information
    #
    # Table name: special_channels
    #
    #  id          :bigint           not null, primary key
    #  description :string
    #  title       :string
    #  extra_data  :jsonb
    #  created_at  :datetime         not null
    #  updated_at  :datetime         not null
  include HashMapAttributes
  hash_map_attributes :image_url, to: :extra_data
  hash_map_attributes :background_url, prefix: :content, to: :extra_data

end

page = Page.new(image_url: 'http://www.image.com/example1.png', content_background_url: 'http://www.image.com/example2.png')
page.save
page.image_url #=> http://www.image.com/example1.png
page.content_background_url #=> http://www.image.com/example2.png
page.update(image_url: ' http://www.image.com/example3.png')
page.image_url #=> http://www.image.com/example3.png

查询

如果是 jsonb 的话，那么则支持查询

Page.where_hash(image_url: 'http://www.baidu.com', content_background_url: 'http://www.baklib.com')

控制台会打印如下查询语句

SELECT "pages".* FROM "pages" WHERE (pages.extra_data->>'image_url' = 'http://www.baidu.com' and pages.extra_data->>'background_url' = 'http://www.baklib.com')

补充：现在支持嵌套 json 的查询和修改了，但是取消了指定前缀的参数。

erb 模板中的注释能否使用 proc 包装，达到快速注释的目的

SuMingXuan — Mon, 02 Sep 2019 14:28:33 +0800

假设有以下前端代码需要注释掉

...
<% if @post %>
  <h1><%= @post.title %></h1>
<% else %>
  <h1>Hello Word<h1>
<% end %>
...

能否使用 proc 将其包装（如下所示），而不去在每个<% 后面添加#，这样对代码有没有影响

...
<!-- 注释代码 -->
<% proc do %>
<% if @post %>
  <h1><%= @post.title %></h1>
<% else %>
  <h1>Hello Word<h1>
<% end %>
<% end %>
...