这是一个创建于 146 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前我在做一个 [ SaaS 软件分销平台] ，里面大概会有不超过 1W 条数据吧，假设一年后有 10W 条数据，现在我需要找一个非常轻量级别的搜索组件。
这是一个单机版的系统，未来访问量也不会很大，我希望够对搜索效果进行提升，请问有什么好的技术可以使用？
我不太想使用 es ，主要是 es 很重，我们的数据量很少，而且没有分布式需求，未来数据量稍微多一些，我准备单独拆出来一台机器做 search 服务即可。
目前使用的是 mysql 的 like ，没有权重等等，所以效果还是很差的。
前端使用的是 next.js 后端现在使用的是 java 。
访问这个地址可以预览这个功能：
https://www.cpcat.cn/s/wework
这是一个单机版的系统，未来访问量也不会很大，我希望够对搜索效果进行提升，请问有什么好的技术可以使用？
我不太想使用 es ，主要是 es 很重，我们的数据量很少，而且没有分布式需求，未来数据量稍微多一些，我准备单独拆出来一台机器做 search 服务即可。
目前使用的是 mysql 的 like ，没有权重等等，所以效果还是很差的。
前端使用的是 next.js 后端现在使用的是 java 。
访问这个地址可以预览这个功能：
https://www.cpcat.cn/s/wework
第 1 条附言 · 145 天前
感谢各位小伙伴的建议，目前已经尝试了 meilisearch 和 redisearch ，占用资源都超低，速度都非常快，meilisearch 目前好像 java sdk 兼容性有问题，已经提交 github ，redissearch 使用下来没有什么问题，应该会在这两个里面选择一个使用，相对来说能够解决以下几个问题：
1 、支持 name 、tagline 、company_name 、categorys 设置不同的权重。
2 、支持 搜索结果 高亮。
3 、支持 content 自动截取字段。。
4 、支持 score 和 自定义字段排序。
1 、支持 name 、tagline 、company_name 、categorys 设置不同的权重。
2 、支持 搜索结果 高亮。
3 、支持 content 自动截取字段。。
4 、支持 score 和 自定义字段排序。
48 条回复 • 2024-08-05 14:27:25 +08:00
 |
1
dilu 146 天前
meilisearch
|
 |
3
dyllen 146 天前
sphinx 老牌的了。
|
 |
4
concernedz 146 天前
对文章，博客类来说，meilisearch 够用了
|
 |
5
potatowish 146 天前 via iPhone
试试 redis search
|
 |
6
2bad4u 146 天前
@concernedz meilisearch 支持拼音搜索吗？
|
 |
7
flyingfz 146 天前
|
 |
8
webeasymail OP @potatowish 我在考虑 redis search ，我不太清楚使用 redis search 分词、高亮、权重是否能够解决？
|
|
9
webeasymail OP @dilu Meilisearch 看起来也很轻量级，看资料和 redis search 一样，内置中文分词。
|
|
10
webeasymail OP @dyllen 我数据用的是阿里云的，sphinx 可以结合云数据库一起用吗？
|
 |
11
DefoliationM 146 天前
bleve 嵌入式的，直接存本地。
|
|
12
webeasymail OP Meilisearch 看起来好像很强大 ：
eiliSearch 是一个功能强大、快速、开源、易于使用和部署的搜索引擎，并且 MeiliSearch 的搜索和索引都是高度可定制的，提供开箱即用的功能属性，如错字容忍、过滤器和同义词。而最重要的一点是，它 [支持中文搜索] ，而不需要添加额外的配置。 二、支持的功能 开源 用户量(开源搜索引擎第二名) 中文分词 同义词 纠错 高亮 全文返回 高级搜索 停用词、停用字段 加权、降权 逻辑搜索 唯一字段聚合 分页 重新索引 |
 |
13
changdy 146 天前
你这个从产品思路上就错了..
首先要做的是软件分类 ,而不是文章内容查询. 看了下你做的软件分类太过于粗糙了. 其次可以再给文章打标签 ,对标签进行搜索 最后搜索只查标题就好了..谁也不会闲着没事记软件的内容的. |
 |
14
sampeng 146 天前 via iPhone
实在要搜索引擎：sonic ，效率奇高。
10w 就要上搜索引擎了？这是什么赛博世界…100w 数据库你就是一个字段一个字段 like 都够你用了。如果是 pg ，pg 自带的向量 token 存储，我试过亿级数据都是 100ms 就能回来，只要自己随便找个分词引擎。 |
|
15
sampeng 146 天前 via iPhone
连分类都不做，全靠搜索不是自己折腾自己么
|
|
16
webeasymail OP @changdy 有分类的，现在又 300 多个分类了，分类可以在这个界面看 ： https://www.cpcat.cn/categories
|
|
17
webeasymail OP 有分类的 https://www.cpcat.cn/categories
我是想通过关键词能够跟准确一下，例如 title 的权重高一些，description 的权重低一些，现在 like 搜索没有权重数据，会导致搜索出来 产品名称 ，可能会 description 的排在前面。 |
|
18
webeasymail OP @changdy 请教一下，产品标签是自动打标签，还是发布的时候手动选择标签？
|
|
19
webeasymail OP @sampeng 实际上主要是解决权重的问题，希望搜索的东西更符合用户需要，例如搜索 “微盟”，title 和 company_name 权重最高，其次就是 description 权重低一些。
|
 |
20
Makabaka01 146 天前
这么一点量级，QPS 也很低，数据库 like 都够了，根本不需要纠结
|
|
21
webeasymail OP @willx12123 like 高亮，分词什么的都需要处理，复杂度也高，做出来效果应该也不太好
|
 |
22
dayeye2006199 146 天前
新点版本的 mysql 自带 full text search 支持。分词索引什么的都支持
|
 |
23
Actrace 146 天前
可以试试 sphinx
|
 |
24
shuimugan 146 天前
meilisearch ，丢了一千多万数据(40 个字段，其中 2 个大文本)进去，1c1g 跑得很舒畅，闲置时候只有二十多 MB 内存占用
|
 |
25
fuis 146 天前
meilisearch 主要的问题是升级，每次升级都需要重新导入导出。。
|
|
26
sampeng 146 天前 via iPhone
@webeasymail 产品没想清楚.这是伪需求。
|
|
27
webeasymail OP @shuimugan 这性能也太强了吧，比 es 的内存占用少太多了
|
|
28
webeasymail OP @fuis 目前没有什么升级需求，大不了重建数据。
|
 |
29
yufeng0681 146 天前
@webeasymail #19 把数据库里的所有 title 和 Company 的数据 变成索引，搜索时候就能联想出来。能联想到的就优先查（详细描述不用 like ，因为肯定命中了。 其他条目的详情里面如果有同样的 key ，也不建议显示出来，这个其实是相关竞品数据）
如果没有联想到，那就 三个字段都 like ，慢一点就慢一点，说明用户本身也没记住名字，大概率是记错了产品名字。 新场景：用户关注某个领域的产品，希望按类索骥走马观花，所以：层级分类确实要做好 |
 |
30
mark2025 146 天前
- pg 原生 FTS： https://pigsty.cc/zh/blog/dev/fuzzymatch/
- pg 扩展 paradedb： https://pigsty.cc/zh/blog/pg/paradedb/ |
 |
31
kran 146 天前 via Android
JAVA 里竟然没人说 lucene
|
|
32
webeasymail OP @yufeng0681 感谢指点，是应该在搜索里面加入分类筛选，通过搜索工具是希望更够更好提升体验。
|
 |
33
wxf666 145 天前
最轻量简单的，应该是 1MB 的 SQLite 了吧。。
案例就是手机端上的微信，全文搜索了吧。。 [《微信全文搜索耗时降 94%？我们用了这种方案》]( https://cloud.tencent.com/developer/article/2220615 ) 里说： > 一个包含 100w 条中文内容、每条长度 100 汉字的 FTS5 的表查询三个词，optimize 状态下耗时 2.9ms > 100w 条内容每次写入 100 条的情况下，按照 WCDB 的方案执行 merge ，耗时在 10s 内。 |
|
34
webeasymail OP @kran lucene 好像维护起来很麻烦，太久没用了，我记得以前手动维护好像挺麻烦的
|
|
35
webeasymail OP @wxf666 这个有技术挑战，需要投入太多精力。
|
|
36
webeasymail OP @2bad4u 这个更高级，我还真没有考虑过
|
|
37
wxf666 145 天前
@webeasymail 下载个开源 simple 中文分词插件，再写几行 SQL ，也会投入很多精力吗？
|
 |
38
FrankAdler 145 天前
@shuimugan 1000w 占用内存多少呢，我测试 2000 条就 340M 了，万级别有点担忧啊
|
|
39
shuimugan 145 天前
@FrankAdler 搜索得频繁的时候好像是五百多 MB 。创建索引的时候占用是高的，看你给的上限，有个参数 MEILI_MAX_INDEXING_MEMORY 可以设置。冷数据给高点配置，等索引创建完之后就可以降配了。
|
|
40
webeasymail OP @wxf666 我看这个文章写了一大堆，做了好多特殊优化，看起来不是很容易使用的样子
|
 |
41
qweruiop 145 天前
今年开发的系统都用 meilisearch 了吧。。。速度奇快。。。
|
|
42
FrankAdler 145 天前 via Android
@FrankAdler 试了下内存能接受，那 2000w 的磁盘空间呢
|
|
43
webeasymail OP @qweruiop 文档看起来也非常简单易用，比 redis search 使用更清晰，我现在使用版本好像有点冲突，默写方法使用会出现错误，提交个 github 看看能不能解决。
|
|
44
yufeng0681 145 天前
|
|
45
webeasymail OP @yufeng0681 IT 桔子 还是比较复杂的，我这个是做 SaaS 软件分销 ，差别有点大，而且 IT 桔子涉及面很广，我这个更窄了，做太大了，搞不起来。
|
 |
46
pieerepeng 144 天前
我也调研过这个需求，记录下。
我们希望在边缘节点上搭建一个搜索引擎，需要占用的内存开销比较小，同时当数据比较大的时候，可以有效使用硬盘。 我们一开始选择了 zincsearch ，选择它的原因是对 es 接口的兼容，不过这个团队弃坑了，以及它的权限做的比较糙 https://github.com/zincsearch/zincsearch Github star 比较多的是： https://github.com/meilisearch/meilisearch https://github.com/valeriansaliou/sonic https://github.com/typesense/typesense 我觉得： https://github.com/manticoresoftware/manticoresearch 可能是遗珠 支持少量付费的话，Algolia 也是一个选择 其实： https://www.meilisearch.com/docs/learn/what_is_meilisearch/comparison_to_alternatives 这篇文档做了对比，可以看看。 最后： 1. 我们文档站用了：Algolia 2. 主项目用了 pg 加一堆插件的方案，整体资源的占用最小。因为我们用了 citus ，未来做云原生支持的时候希望也能容易些 op 1 万多条的规模感觉 meilisearch ，typesense 挑一个就好了 |
 |
47
ryalu 144 天前
试试 openobserve ，zincsearch 团队搞得
|
 |
48
imtflin 144 天前
meilisearch 现在的中文分词有很大的问题，某些情况根本不可用，将文字 pinyin 化，导致一系列的问题，官网目前暂时也没精力解决。
|
Select Language