关于全文搜索引擎的选择,小型后端项目用 Elasticsearch 合适吗?

2021-01-09 20:20:31 +08:00
 yodhcn
楼主今天刚了解到 "全文搜索引擎" 这一概念 —— 传统的关系型数据库,比如 MySQL,一般不适合做关键词搜索,关键字搜索最好配合全文搜索引擎使用。

在网上搜索 "全文搜索引擎" ,大家推荐的都是 Elasticsearch,一个企业级的搜索引擎。

实际上,楼主正在开发一个类似 emby 或 plex 的个人媒体服务器,数据量自然不会太大,于是就选择了 sqlite 这一文件型数据库,来存储视频 /音频的元数据。
这种级别的后端应用,自然用不到 Elasticsearch 这么重的工具,也没有数据分析的需求,但还是要解决 "搜索元数据中的关键词" 这一问题。

所以,想向大家请教 2 个问题:
1. 对于小型后端项目,有哪些适合的比较轻量的全文搜索引擎?或者其它解决关键词搜索的方案?
2. 那些博客应用、小型论坛应用都是怎么解决全文搜索的?
9170 次点击
所在节点    Elasticsearch
51 条回复
yzbythesea
2021-01-10 05:57:00 +08:00
博客之前用的就是一个 javascript 写的搜索,原理就是 regex 指定的文本。
yrj
2021-01-10 06:10:34 +08:00
数据量小,建议直接 sqlite 自带的全文检索,我用过没问题的。单个人不是很推荐 sqlite 做生产数据库。
veike
2021-01-10 07:45:05 +08:00
@yzbythesea 太弱了
zjsxwc
2021-01-10 08:44:04 +08:00
偏个题
mysql5.7 之后就支持中文全文搜索了 ngram
Jackeriss
2021-01-10 08:46:54 +08:00
github 上也有不少小型搜索引擎项目
dick20cm
2021-01-10 09:21:43 +08:00
@anUglyDog 这个不是中文分词,ngram 就叫做 ngram
update
2021-01-10 09:38:08 +08:00
中小型的尝试下
redissearch
manticoresearch
sphinx
xuanbg
2021-01-10 10:14:27 +08:00
楼主是不是对“重”有着什么误解?什么叫重?
1 、使用、管理、维护需要专门的人才,这个叫重
2 、使用的代价高昂,应用本身或应用工作所需的硬件资源需要花费巨额资金,这个叫重
3 、没有第三了……

ES 重吗?完全免费!一行 docker 命令就能完成安装,几乎不需要配置,spring boot 已经集成了客户端,这个能叫重?
至于使用它所需要的资源,cpu 取决于你的业务量,内存 /存储取决于你的内容。既然你没啥访问量,内容也不多,那基本上就是 docker 镜像占用个几百兆硬盘空间而已。你管这个叫重?
chinesestudio
2021-01-10 10:15:04 +08:00
solr
icyalala
2021-01-10 11:15:56 +08:00
@xuanbg 你是不是对楼主想问的 "重" 和 "轻量" 有什么误解?
mywaiting
2021-01-10 11:36:09 +08:00
要是用 PostgreSQL 增加全文搜索也就是分分钟的事情,tsvector 搞定所有搜索

当然了,这是中小型网站的选择,你要是打算到 Google 搜索这级别,就当我什么也没有说过吧
lemy
2021-01-10 11:56:14 +08:00
@GoLand 实话说这样还不如自己上 es,也要考虑后期的拓展。依赖搜索引擎做自己的搜索功能是不现实的。
pc10201
2021-01-10 12:02:29 +08:00
阿里云直接有搜索服务,自动同步 mysql
est
2021-01-10 12:08:05 +08:00
> 楼主正在开发一个类似 emby 或 plex 的个人媒体服务器,数据量自然不会太大

建议直接 mysql ngram
mtrec
2021-01-10 12:24:08 +08:00
但还是要解决 "搜索元数据中的关键词" 这一问题

需求这么简单自己写个分词倒排索引不就好了?
notejava
2021-01-10 13:10:16 +08:00
Elasticsearch 重了点,Lucene 就可以满足
KevinBlandy
2021-01-10 13:18:11 +08:00
也许可以试试看 redissearch
imn1
2021-01-10 13:40:16 +08:00
我想问有什么元数据的关键词需要搜索?就是什么需求?

个人服务的话,建议还是免装数据库(暂时就 sqlite 合适),其他所有需要安装的数据库,都不适合备份导出
注意用户群中懂导入导出的恐怕不足 5%,媒体越多,库越大,意味着这个用户前期输入组织的工作量越大,基本不可能在崩溃后重新再组织一次,如果做不到原样回复,那就是一次抛弃型软件

经验:
我目前一万五千个视频文件,就已经 50T 硬盘了,找到视频的路径位置是第一需求
我的意思是,大视频的话,数量少一点,但存在分盘问题,小视频的话,数量多一点,但个人较难逐个输入数据,肯定有他自己的一套提醒记忆方案,这个方案一般不会太复杂(否则不好记),但比较个性化,其他人不适用
所以做这种个人服务项目,做成泛化功能用途不大,反而需要一些个人定制的功能,反正就是不好做

个人觉得,以数据量来说,sqlite 足够了,很难想像个人的媒体,在不计算图片前提下能达到百万级,如果真达到百万级(例如包含图片),元数据一定不会太复杂,因为对那个用户来说,百万级手动输入不太可能,自动获取又难以满足他的记忆提醒需求,时间、地点、TAG,超出这些的个性化需求就不是软件制作人能想到的了

不必太担心全文搜索了,这不是个人媒体库的难点
lewis89
2021-01-10 13:51:45 +08:00
@xuanbg #28 轻重看场景的,人家用的 sqlite 这明显是针对 NAS 以及个人用户的
lewis89
2021-01-10 13:54:38 +08:00
别考虑这么多,针对终端用户的东西,还动不动考虑性能... 真的是没有意思,个人用户撑死能存个几万部电影,这种场景 性能不是首先需要考虑的问题。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/743402

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX