这是一个创建于 1967 天前的主题，其中的信息可能已经有所发展或是发生改变。
项目开发中, 前期不打算搭建文件资源对象服务器, 但是项目中存在用户上传图片及文件的功能, 目前是将图片直接保存在服务器上的某个目录路径下, 然后配置通过 nginx 访问读取图片数据, 那么问题就是, 以这样的方式保存图片(因为 web server 层的原因, 尚且没有办法做到按日期创建目录, 分类保存图片, 目前是所有图片都保存在一个目录下), 当图片数量达到什么样的数量级的时候访问图片会出现比较严重的性能问题????
如果项目运营稳步提升的话, 后续会考虑搭建一个专门的服务器来保存图片资源, 目前也正在调研几个开源项目, 但是就是希望能知道保存在单一目录下的数量瓶颈是多少, 以便后面能及时的迁移.
有那位大佬对这方面的东西比较了解,还望告知一二, 小弟跪谢.............我也会喊 66666666..................手动狗头.gif
 |
1
YIsion 2019-08-07 19:42:20 +08:00  1
最大问题不是性能问题，是带宽问题。图片的数据量级可是比字符串多了很多。
|
 |
2
lowman OP @YIsion 假设带宽, 服务器硬件资源都能满足, 单个目录下保存了大量的图片, 通过 nginx 访问获取. 在这样的前提条件下, 想知道这个数量瓶颈在哪里, 不是 ls 之类的操作.........
|
 |
3
akira 2019-08-07 20:02:15 +08:00 1
单目录下 大概 3w 个文件吧
|
 |
4
eonboy 2019-08-07 20:05:57 +08:00
大胆猜一下，会与文件系统有关系吧，所以系统相关信息多列点，有助于大佬解答...
|
 |
5
sunkwei 2019-08-07 21:15:09 +08:00 1
另外一个思路，可以把图片内容保存到数据库中，如果写少读多，sqlite3 就行，作机器学习的 datasource 时，经常使用 sqlite3，几百万张照片没问题。
|
 |
6
bkmi 2019-08-07 21:47:28 +08:00 via Android 1
你后台只有一台服务器吗？
如果只有一台那随便你怎么干了… 不是的话还是单开存储服务吧 |
 |
7
xjtufreeman 2019-08-07 21:48:51 +08:00 1
可以用 oss 啊
|
 |
8
airqj 2019-08-07 22:08:07 +08:00 1
为什么不用 oss.....
|
 |
9
abcbuzhiming 2019-08-07 22:11:18 +08:00 1
|
|
10
abcbuzhiming 2019-08-07 22:12:06 +08:00 1
|
 |
11
arrow8899 2019-08-07 22:13:32 +08:00 1
通过文件路径读取文件，基本不存在性能问题，查找文件是根据文件名 hash 查找；真正影响的应该是硬盘本身的性能。
|
|
12
arrow8899 2019-08-07 22:15:53 +08:00 1
@arrow8899 但是文件太多，对一些工具可能会有影响，比如 ls 命令，nginx 的 auto_index 功能等。
|
 |
13
Caballarii 2019-08-07 22:19:45 +08:00 1
oss 能花了几个钱啊，比人力便宜多了
|
 |
14
jugelizi 2019-08-07 23:06:21 +08:00 1
...能用钱解决的事还不好
说真的 小系统怎么玩都行 客户量大的还是上云端 花的钱远比你后期投入的划算 |
|
16
lowman OP @bkmi 多台 web server 其实也可以做到直接保存到本地目录的, 比如在 nginx 配置一下, 当然还是看需求
|
|
17
lowman OP @xjtufreeman 后续会考虑
|
|
18
lowman OP @abcbuzhiming 文件系统的差异影响的是最大数量, 这点是知道的, 疑惑的就是在不超过最大数量的前提下, 当数量达到多少, 通过 nginx 读取图片时, 会出现体验过差, 应该还是磁盘 io 性能的限制
|
|
19
lowman OP @abcbuzhiming 后续看项目发展吧, 起不来, 肯定不去考虑这些了
|
 |
21
alcarl 2019-08-07 23:56:08 +08:00 via Android
可以自己测试的啊，复制几百万文件还不简单，一般都不建议放一个目录里，一台机器一个目录，备份都不好备份，如果炸了就全完了。。。。。
|
|
22
lowman OP @alcarl 预估达不到百万级的数据量, 正在写个脚本测一下, 至于容灾方面的东西, 估计得后续看项目运营情况, 小公司, 小项目,成本有限
|
 |
23
yidinghe 2019-08-08 09:06:23 +08:00 via Android
这个只要磁盘空间够，不会有什么性能问题，如果磁盘 IO 太频繁还可以在 Nginx 上配缓存。
|
|
24
lowman OP @yidinghe 刚测试了一下, 在本机测试, 本机浏览器随机访问 nginx 进而获取某个目录的某张图片, 固态硬盘, 复制了 10 万张图片(这里应该远远不止 3w 的说法, 但与文件系统, inode 有关系, inode 用完, 就算磁盘空间再大也写不进去的), 察觉不到任何延迟, 只是进行 ls 之类的操作时有点卡顿现象(应该会随着文件数越大越明显).......如果是这样的话, 项目估计上线以后还能撑一段时间..............看来我就是一个得过且过的程序员..................
|
 |
25
crella 2019-08-08 09:54:24 +08:00 via Android
我看微信安卓版放图片是根据(hash?)的前几位字符的啊，比如 sfjbxkkb.jpg 就放到./s/f/j/b/sfjbxkkb.jpg ，这个功能拿个 py/rb 挺好实现的啊
|
 |
26
hbolive 2019-08-08 10:37:18 +08:00 1
根据文件名读取文件，几十万都没啥太大问题的。。
|
|
27
lowman OP @crella 后台在数据表就保存图片的目录限制住了(需要实现某些需求导致的问题), 后续看情况会搭建专门的服务器保存图片
|
 |
28
linbingcheng 2019-08-08 14:17:09 +08:00 1
上传文件呀，这个东西还是得考虑下安全问题的，搞个 ftp 存应该没错
|
|
29
lowman OP @linbingcheng 是上传图片, 目前还没有允许用户上传文本文件的功能 , 至于你说的安全问题, 不知道你担心的是否为恶意用户上传可执行的恶意脚本的问题? 我这里有根据图片内容去判断上传文件是否为图片(不是判断图片尾缀), 如果不是图片文件就不进行保存. 目前也只是做到这一层面的安全验证了.
|
 |
30
ungrown 2019-09-12 10:04:50 +08:00
按文件名或者文件内容算出 hash
按前两位或者前四位 hash 分级目录 abcdef...1234.jpg -> /ab/cd/ef...1234.jpg 这个方案被广泛应用，实际证明性能不错，除非你是阿里、腾讯、亚马逊、微软那种云平台厂商的数据量级别 而且其实挺灵活的，你想多加一级目录或者减少一级目录，只要改几行代码，写几行 shell 就行了 |
Select Language