新手请教一下,我的数据库系统有多少改进的空间? - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
请不要在回答技术问题时复制粘贴 AI 生成的内容
heliumjt
V2EX    程序员

新手请教一下,我的数据库系统有多少改进的空间?

  •  1
     
  •   heliumjt 2023-12-08 17:53:39 +08:00 2329 次点击
    这是一个创建于 751 天前的主题,其中的信息可能已经有所发展或是发生改变。
    我自己是纯业余爱好者,没上过一点科班课程,这段时间靠 GPT 全程答疑搭了一个卡牌查询网站 https://sbwsz.com/ ,数据量大概在 10w 条左右,后端用的是 SQLAlchemy+SQLite 。目前感觉查询性能很一般,很多查询要接近 1 秒的时间才能出结果,光查询用时就是其他卡查网站整个网络请求用时的好几倍。
    我首先想到的肯定是查询语句的优化不够。但是由于卡查很多地方是文本模糊匹配,SQLite 这方面的性能好像不太行,我感觉优化的空间不太大。问了问 GPT ,它建议我改用 PostgreSQL 或者 Elasticsearch 。或者,由于数据量比较小( 10w 条数据大概 1GB 左右),是不是可以直接放内存里用 redis 之类的内存数据库管理?
    13 条回复    2023-12-11 17:39:12 +08:00
    gxy2825
        1
    gxy2825  
       2023-12-08 18:00:33 +08:00   1
    这种文本模糊搜索很适合用 Elasticsearch ,但是考虑到技术难度和数据量不一定是优选,如果数据量增长的不快可以先用 Redis 试试
    AllanAG
        2
    AllanAG  
       2023-12-08 18:10:51 +08:00   1
    文本模糊搜索的话,redis 可能不是好选择。es 可以但没必要,可以使用些轻量级的搜索引擎,比如 Meilisearch
    zzl22100048
        3
    zzl22100048  
       2023-12-08 18:11:36 +08:00   1
    可以试试 slqite 的分词器,做模糊搜索,上 redis 感觉还不如正规的搜索引擎呢 像 https://github.com/valeriansaliou/sonic 这种
    dongdong12345
        4
    dongdong12345  
       2023-12-08 23:26:57 +08:00   1
    这个网站是用什么搭建的呀,很不错啊!有现成的开源项目吗?
    10W 数据如果后续新增的数据量非常小,感觉上 Elasticsearch 太重了,增加维护成本。
    你可以在阿里云或者腾讯云平台申请免费试用 1 个月的 PostgreSQL 或 MongoDB 数据库,然后把数据写进去,试试看哪个能满足你的需求。
    rekulas
        5
    rekulas  
       2023-12-08 23:46:43 +08:00   1
    可以考虑放 sphinx,这点数据量挺轻松
    或者找一个其他开源搜索框架自己做 不过要说到效果上一般的框架可能还是比不过 es(框架很多 但权重得分计算做得好的不多)
        6
    heliumjt  
    OP
       2023-12-09 00:24:07 +08:00
    @lmq2582609 前端就是 Vue+Element ,没有别的框架了。对比了一下之后我决定先上 PostgreSQL 试一下,因为我项目里也不只是文本查询,还有很多复杂的条件查询,我自己还是得 SQL 才玩得明白。
    suuuch
        7
    suuuch  
       2023-12-09 15:05:46 +08:00
    SQLite 的话,换 SSD ,会有一点提升。

    文本检索上 ES 是标准方案,但是光是 ES 集群就够整的了。

    用 PostgreSQL 然后设计一下数据结构,和索引,应该是可以的。。(不知道数据长什么样,不做任何保证
    isSamle
        8
    isSamle  
       2023-12-09 16:01:25 +08:00
    为什么不用 mysql
    maichael
        9
    maichael  
       2023-12-09 20:12:59 +08:00
    ES 太重的话,可以用 meilisearch 替代。
    aru
        10
    aru  
       2023-12-09 22:25:45 +08:00
    ES 用 docker 来搭建一个单节点的也还好
    不过你的硬件是什么呢?单节点的 ES 配合你的网站,建议也要 4G 内存的机器
    kuanat
        11
    kuanat  
       2023-12-10 04:57:25 +08:00   1
    我大概试了一下网站,没感觉查询有什么特别慢的地方。如果要定位慢查询的问题,最好贴上语句和配置信息什么的看一下。

    在不改变技术框架的情况下,优化方案就是加索引。再具体一点,这个索引是要能通过用户输入的关键词,快速定位到特定字段包含关键词的数据集。

    这里涉及到两个主要的技术点,一个是对文本字段进行分词,提取出关键词。另一个是通过关键词反查数据集,这个要构建的索引叫倒排索引( inverted index )。剩下的事情就是更改查询逻辑,前端查询请求走索引,后端直接取索引筛选出的数据集。(这个索引可以做到后端应用程序里,也可以保存到数据库里)

    考虑到楼主非专业开发,我是建议手动做上面的事情。用其他的成熟方案,需要学习的东西其实更多,原理理解不到位的话很可能达不到效果,而且没有必要。


    如果是我来做这个事情的话,可能会采取完全不同的方案,楼主可以参考一下。

    因为这个数据库基本上是只读不写的,写场景基本只发生在数据修正或者批量更新的时候。所以优化的核心思路就是数据集(数据库)为查询优化。

    虽然楼主没有透露这个数据库的表结构,考虑到万智牌大概就几万张,而数据集大概有 10 万条,这个数据库应该是冗余很低,符合范式的设计方式。

    这一类数据库是为写操作和存储优化的,冗余很低,提取数据需要对数据表做组合查询。为读操作和查询优化的数据库正好相反,冗余很高。既然最终查询结果是卡牌集合,那就以某种数据结构来记录每张卡牌包含的所有信息,一次读取即可获得完整数据,省去了数据组合的过程。

    即便有大量的冗余,内存中以这种数据结构存储卡牌信息,可能不会超过 4GB ,即使再翻个倍也不是问题。那对于查询系统来说,有没有 sql 数据库都不重要了。

    当然 sql 对于数据录入还是很有意义的,一方面可能本身数据来源导入比较方便,另一方面修改低冗余数据远比高冗余数据方便。所以这里需要编写个脚本,在每次 sql 数据库更新之后,重新生成一份通用格式的(比如 csv 或者 json )的数据集,后端应用程序反序列化之后即可获得上述的内存数据库。

    上面这些如果用技术语言描述,就是 sql 转 kv/nosql ,没有多少技术难度,就是个经验问题。

    剩下的事情都差不多,分词、建索引。主要是一些经验层面的优化,这里就随便列举几个。

    比如请求是可以缓存的,一般用在高频查询和分页上。再比如具体到这个查询场景说,一个请求如果需要返回几百个数据,要么不合理要么没必要。(人一般不需要这么多,返回太多都是在给爬虫服务了。)
    dayeye2006199
        12
    dayeye2006199  
       2023-12-10 15:45:50 +08:00 via Android
    PG 的全文搜索。多大网站得上 es
    heliumjt
        13
    heliumjt  
    OP
       2023-12-11 17:39:12 +08:00
    @kuanat 哇,太详细了!我好好研究一下您的回答。
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     5231 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 116ms UTC 09:18 PVG 17:18 LAX 01:18 JFK 04:18
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86