图像存储之 sqlite/文件存储？ cgo/purego? 谁更快 | go 技术论坛-380玩彩网官网入口

最近有一批图片资源需要本地存储，但是看到密密麻麻的文件夹，头都麻了。想起过去图片迁移硬盘的痛苦（文件太多）。所以在想如果我写在 sqlite 里面，那效果怎么样呢？ 于是马不停蹄的，写了一个脚本，把图片资源导入了sqlite4file.db。表结构也很简单

type entity struct {
    id        uint64    `gorm:"primarykey;column:id;autoincrement;not null;" json:"id"`          // 主键
    name      string    `gorm:"column:name;index;type:varchar(256);not null;" json:"name"`       //
    type      string    `gorm:"column:assert_type;index;type:varchar(64);not null;" json:"type"` //
    data      []byte    `gorm:"column:content;type:blob;" json:"data"`                           // 内容
    createdat time.time `gorm:"column:created_at;index;autocreatetime;" json:"createdat"`        //
    updatedat time.time `gorm:"column:updated_at;autoupdatetime;" json:"updatedat"`
}

当然写进去还是要测一测的，如果性能暴跌，或者文件变得巨大无比，就得不偿失了。

首先是体积对比

我们一共又7.4w的文件

空间上的对比，五五开吧。

我们在测一下图片查看，这里写了个api查看。

中图gin gorm sqlite(cgo)

中图gin c.file(path) 调用

中图gin gorm sqlite (purego)

这个场景下可以看到纯go版本的sqilte不但比文件快，而且比cgo版本的sqlite还要快

接下来再试一下大图

大图gin gorm sqlite(cgo)

大图gin c.file(path) 调用

大图gin gorm sqlite (purego)

这个场景下可以看到 硬盘读文件，竟然又变得远超两个sqlite。因为qps均没有超过之前的中图，所以可以认为有其他方面的性能瓶颈。从测试结果上看。很有可能是使用如此大图，在高频读写的场景下，sqlite可能出现了io瓶颈，但是直接读源文件会好一些。（猜测）当然过程中也看了cpu使用率，sqlite的场景并没有比纯文件的高。但是相差不大。所以应该还是又io方面的瓶颈。

当然因为这个场景都是后续本机操作，所以sqlite对我来说也是一个不错的选择。
网上主流大多不推荐用mysql存储图片，牵扯到多次网络传输的开销。但是我的场景以本地为主，sqlite 和主程序都在同一个宿主机。并且在小图情况下，还有一点点读取优势，所以综合来说也是一个不错的选择。

当然了，sqlite每次完整的读取出文件可能相比较其他还是有一些压力，但文件平均都不是特别大（都是最大也就几mb）。所以也是一种不错的选择，方便以后迁移的时候，直接把sqlite复制以下就。

本作品采用《cc 协议》，转载必须注明作者和本文链接