怎么存储才能较高效读写,每张图片也就几 k 到几十 k,之前存在一个文件夹下,inode 太大,rm -rf 都要删很久很久,就像卡死了一样.
c++的小服务,有什么存储库可用吗,或者如何分散合并到硬盘?
怎么存储才能较高效读写,每张图片也就几 k 到几十 k,之前存在一个文件夹下,inode 太大,rm -rf 都要删很久很久,就像卡死了一样.
c++的小服务,有什么存储库可用吗,或者如何分散合并到硬盘?
|
keepeyeJun 3, 2019
1
上 hdfs 之类的文件系统?小文件合并存储,当然读取的话要走接口了
|
|
also24Jun 3, 2019
2
噗嗤,之前存过几十万张,每张 0.5~1MB 左右的,即使丢进 SSD,读写的时候还是想死,关注一下大家有什么好方案
|
|
aquariummJun 3, 2019 via Android
4
最方便的就是生成然后上传到 oss
|
|
JirajineJun 3, 2019 via Android
5
用私有格式直接合并存储合并读写
|
|
andyzhshgJun 3, 2019
6
leveldb 之类的 kv 应该可以吧?
|
|
keepeyeJun 3, 2019
7
要不 直接丢到 mongodb 里?
|
|
8
早点习惯用云解决这类问题,就可以早点从这类问题背后的性能、备份、CDN 等等更细节的问题里解脱出来。
|
|
goreliuJun 3, 2019 via Android
9
这个还要看具体是怎么读写的。比如读、新增、删除文件都是什么频率的。
如果图片的大小相差不大,可以这样简单实现。把图片按大小分成几类,比如小于 10k、10k - 30k、30k、50k 等等。然后为每类图片分配一个大文件和索引文件。像 10k 文件按 10k 的块来使用,在索引文件记录文件名和对应文件偏移。 这样虽然会浪费一些空间。但写入读取(因为省去打开关闭过程,比单文件读要快)、删除(只需要写索引文件)图片都非常快。 如果不想费事,可以找个 kv 数据库,但性能会差些。 |
|
swullingJun 3, 2019 via iPhone
10
本地的话建议用 LevelDB 或者 rocksdb 这种本地 kv 存储
|
|
KlingonJun 3, 2019
11
图片量不小了。可以用阿里云腾讯云,不放心的话可以用 minio 搭建个私有存储。
|
|
dsnake1984Jun 3, 2019
12
腾讯 cos 便宜好用~ 不烦神。
|
|
mYYnSmiTEQWcCwArJun 3, 2019 via Android
13
seaweedfs
|
|
14
一定自己存的话肯定不能丢一个文件夹,文件名 hash 之后取 hash 前缀分文件夹存试试
|
|
xuddk727Jun 3, 2019
15
了解一下 mr4c, google earth engine?
|
|
aec4dJun 3, 2019
16
直接用 ext4 存了千万级缩略图的表示,没什么性能问题,跑的很欢,不需要特别做优化
原图是存在了 S3 上,本地缩略图再不济可以获得原图再生成一次缩略图 https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html |
|
opengpsJun 3, 2019 via Android
17
必须用单机环境的话,你得知道目录下最多 500 张
|
|
justouJun 3, 2019
18
HDF5 可以了解一下
https://www.hdfgroup.org/ |
|
6j1A6v70lEv5n2U2Jun 3, 2019 via iPhone
19
@opengps 为啥最多 500 张?
|
|
winglight2016Jun 3, 2019
20
百万级的文件,单机不好搞了吧,不想上专门的文件系统,也可以导入 RMDB 里面
|
|
loadingJun 3, 2019 via Android
21
minio
可以做分布式了,都说是开源的 aws s3 |
|
luozicJun 3, 2019 via iPhone
22
小图 不上 DB 那种存文件的,读取不是想死?
|
|
wbrobotJun 3, 2019
24
豆瓣是自己造轮子解决的:beansdb
|
|
25
两个亿的图片怎么比较好?频繁读,少量写
|
|
FrankHBJun 4, 2019
26
@Livid 单机呢?
然后不管多出来的网络成本,确定把问题转换为风险管控和砍价上兜得住么。 二次开发成本呢? (怕是要和抠脚皮大汉打一架:Who does that server really serve?) 我现在要在本机索引万以上的大小 1M 左右的截图,要求能任意两图之间快速预览加注标签近似比较自动去重,持久存储效率平均不低于 FLIF 的 30%;暂且先不管价钱,有什么 IaaS 方案能救吗? |
|
FrankHBJun 4, 2019
28
@tenwx 不是基于直接二进制比较或者 hash 的去重,跟内容特征相关,基本上肯定是要二次开发的。
不过这个是没支持手动标注分类的优先级高……考虑到我的输入数据中大部分特征相似分类也不太复杂,但是各种奇形怪状,不容易自动提取,短时间内弃疗了,实在不行等标记完一并手动凑数吧。 个别情况有损压缩和无损图源会在同一个地方倒是适合自动,不过数量不多也算了…… |
|
yanzixuanJun 4, 2019
30
@winglight2016 riak 吧。分布式的。
|