未分類
11 1 月 2021

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

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

資深大佬 : yodhcn 1

主今天刚了解到 “全文搜索引擎” 这一概念 —— 传统的关系型数据库，比如 MySQL，一般不适合做关键词搜索，关键字搜索最好配合全文搜索引擎使用。

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

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

所以，想向大家请教 2 个问题：
1. 对于小型后端项目，有哪些适合的比较轻量的全文搜索引擎？或者其它解决关键词搜索的方案？
2. 那些博客应用、小型论坛应用都是怎么解决全文搜索的？

大佬有話說 (47)

  • 資深大佬 : cs3230524

    合适

  • 資深大佬 : codehz

    (是否选用 sqlite3 的唯一考量因素是有没有横向扩展的需求，没有的话，即使全文搜索这种需求也可以在 sqlite3 里做。。
    比如用 sqlite3 内建的 fts5(中文的话比较麻烦，但是也有能用的第三方分词，可以自己整进去）

  • 資深大佬 : GoLand

    做好 seo，然后直接用谷歌搜索，类似 v 站的搜索功能。

  • 資深大佬 : 340244120w

    Es 基于 lucene 的 所以可以考虑 lucene

  • 資深大佬 : beyondex

    合适。如果是 .NET 可以用 Lucene.NET 如果是 Java 可以用 lucene，但是用起来其实比直接用 ES 写代码要复杂一些。

  • 資深大佬 : 12101111

    Rust 有 https://github.com/valeriansaliou/sonic 和 https://github.com/tantivy-search/tantivy

  • 資深大佬 : newbieRenew

    由第三方全文搜索的工具，你搜一下

  • 資深大佬 : zhuangzhuang1988

    合适

  • 資深大佬 : xcstream

    不合适 内存占太大

  • 資深大佬 : crynocry

    尝试一下 MySQL 全文索引

  • 資深大佬 : shuangya

    不合适。小型直接 mysql 就够了。
    mysql 512M 内存就可以跑起来。
    es 没有 2G 就别跑了。

  • 資深大佬 : idblife

    数据量小的话不合适
    mysql 查呗，小数据量全表也没事

  • 資深大佬 : whitehack

    https://artem.krylysov.com/blog/2020/07/28/lets-build-a-full-text-search-engine/ 这有个自己撸的…

  • 資深大佬 : niubee1

    数据量不大的话可以试试 Redisearch

  • 資深大佬 : leafre

    直接 lucene

  • 資深大佬 : love

    杀鸡用牛刀了，之前有人推荐过一个很轻量的也比较流行的，忘了叫什么搜一搜可能搜到

  • 資深大佬 : DoctorCat

    是否合适，重点是要看成本。

  • 資深大佬 : anUglyDog

    MySQL 内置中文分词引擎 ngram

  • 資深大佬 : CODEWEA

    不谈实际，空谈技术都是扯淡，你不得先确定需求吗？

  • 資深大佬 : izgzhen

    AWS 上的 ES 成本还是比较弹性的，不知道其他☁️如何

  • 資深大佬 : yzbythesea

    博客之前用的就是一个 javascript 写的搜索，原理就是 regex 指定的文本。

  • 資深大佬 : yrj

    数据量小，建议直接 sqlite 自带的全文检索，我用过没问题的。单个人不是很推荐 sqlite 做生产数据库。

  • 資深大佬 : veike

    @yzbythesea 太弱了

  • 資深大佬 : zjsxwc

    偏个题
    mysql5.7 之后就支持中文全文搜索了 ngram

  • 資深大佬 : Jackeriss

    github 上也有不少小型搜索引擎项目

  • 資深大佬 : dick20cm

    @anUglyDog 这个不是中文分词，ngram 就叫做 ngram

  • 資深大佬 : update

    中小型的尝试下
    redissearch
    manticoresearch
    sphinx

  • 資深大佬 : xuanbg

    主是不是对“重”有着什么误解？什么叫重？
    1 、使用、管理、维护需要专门的人才，这个叫重
    2 、使用的代价高昂，应用本身或应用工作所需的硬件资源需要花费巨额资金，这个叫重
    3 、没有第三了……

    ES 重吗？完全免费！一行 docker 命令就能完成安装，几乎不需要配置，spring boot 已经集成了客户端，这个能叫重？
    至于使用它所需要的资源，cpu 取决于你的业务量，内存 /存储取决于你的内容。既然你没啥访问量，内容也不多，那基本上就是 docker 镜像占用个几百兆硬盘空间而已。你管这个叫重？

  • 資深大佬 : chinesestudio

    solr

  • 資深大佬 : icyalala

    @xuanbg 你是不是对主想问的 “重” 和 “轻量” 有什么误解？

  • 資深大佬 : mywaiting

    要是用 PostgreSQL 增加全文搜索也就是分分钟的事情，tsvector 搞定所有搜索

    当然了，这是中小型网站的选择，你要是打算到 Google 搜索这级别，就当我什么也没有说过吧

  • 資深大佬 : lemy

    @GoLand 实话说这样还不如自己上 es，也要考虑后期的拓展。依赖搜索引擎做自己的搜索功能是不现实的。

  • 資深大佬 : pc10201

    阿里云直接有搜索服务，自动同步 mysql

  • 資深大佬 : est

    > 主正在开发一个类似 emby 或 plex 的个人媒体服务器，数据量自然不会太大

    建议直接 mysql ngram

  • 資深大佬 : mtrec

    但还是要解决 “搜索元数据中的关键词” 这一问题

    需求这么简单自己写个分词倒排索引不就好了？

  • 資深大佬 : notejava

    Elasticsearch 重了点，Lucene 就可以满足

  • 資深大佬 : KevinBlandy

    也许可以试试看 redissearch

  • 資深大佬 : imn1

    我想问有什么元数据的关键词需要搜索？就是什么需求？

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

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

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

    不必太担心全文搜索了，这不是个人媒体库的难点

  • 資深大佬 : lewis89

    @xuanbg #28 轻重看场景的，人家用的 sqlite 这明显是针对 NAS 以及个人用户的

  • 資深大佬 : lewis89

    别考虑这么多，针对终端用户的东西，还动不动考虑性能… 真的是没有意思，个人用户撑死能存个几万部电影，这种场景 性能不是首先需要考虑的问题。

  • 資深大佬 : areless

    sphinx 超强的

  • 主 資深大佬 : yodhcn

    @imn1 #38 元数据直接通过爬虫爬取，包括：标题、封面图片 url 、标签、系列名、演员名、上映日期、作品介绍 (TEXT 类型) 等内容，再有就是扫描磁盘得到的影片存储路径。

    其实我最开始想问是另一个问题，https://www.v2ex.com/t/743359#reply6

    老哥你的意思是：
    1. 虽然 sqlite 也有 fts5，但如果只从 “标题、标签、系列名、演员名、上映日期” 这些 VARCHAR 类型的字段搜索关键词，是不是就没必要用 “全文搜索” 来做，直接把它们拼接成一个新字段 search，再在这个字段里搜索 “WHERE search LIKE ‘关键词”” 就够了？
    2. 虽然这么搜索没有索引，但由于数据量不大，所以不用考虑性能与效率问题？

    @imn1 #38

  • 資深大佬 : codehz

    FTS5 可以索引多个列的，没有任何问题，还能做约束从不同列搜索内容。。实现类似谷歌的那种搜索语法（当然为了用户友好性你还是得自己转换一下）

  • 資深大佬 : imn1

    @yodhcn #42
    Y，性能不是大问题，最难的地方还是怎么提供一些个性化需求（说的不是皮肤）

    sqlite 有两个好用的东西，其他数据库应该也有，没详细考究
    1. || 连接符，拼接多个字段
    2. 自定义函数，注册为 sqlite 函数，这个就好多事情可做了

    说几个我遇到的难点吧，至今还没自己满意的解决方案
    1. 举个例子
    输入：严正花、严正华、严晶华……任一，如何“智能”搜到 严正化（这个是数据库中正确的名字）
    意思是，用户输入是随意的，但数据是归一的，如何能做到两者合理匹配
    为了这个搞个 AI 不值得，模糊匹配准确度又低

    自驾网经常见到这样的帖子：这个女的叫什么？有什么番号？ —— 以图搜车
    岛国有个素人大全数据库的网站，那叫一个全啊，曾经用什么名字出现在哪个产品都能搜出来

    2. 你只考虑了公众化的内容，个人服务有个很大的需求是自己的内容，例如各种自拍、生活记忆、旅行影像等等，这些就需要很强的自定义数据字段 —— 批量输入、单独输入、个性化标签、归类、自动识别（人脸？）……等等
    举个例子：电话录音的整理

    3. 文件改名、移动，尤其是跨盘移动
    如果在管理软件内操作，如何处理大量文件 IO，有可能几百 G 移动哦(westworld 4K 一季就这个量了)，自己写的话，不但不好使，出 BUG 可能性也极高
    如果不是在管理软件内操作（例如用三方复制软件操作），如何方便又准确地，在移动操作后重新匹配数据

    还有其他复杂问题，只是我需求比较狭窄，没遇到

    反正搜索性能是小事，但优化肯定还是要做的，不能事小而不为，重点放在个性化的数据录入，以及备份恢复吧

  • 資深大佬 : airfling

    hibernate search 其实也可以

  • 資深大佬 : ffxrqyzby

    你个人媒体, 我感觉直接 grep 就够了….
    最多几百兆文本?内存一加载就行了, es 是有点太重了, 不过还是看你选择了, 玩玩 es , 了解一下也挺不错

  • 資深大佬 : encro

    mysql ngram 刚好用过，送给你：

    https://c4ys.com/archives/2098