所以我正在使用一个将图像存储在数据库中的应用程序.你对此有何看法？我更像是一种在文件系统中存储位置的类型,而不是直接将它存储在数据库中.
您认为利弊是什么？
这是一个之前被问过的问题(大文本和图像在sql中),但主要用于将要更改的数据.在我的情况下,数据将被存储并且永远不会改变.把所有东西放在一起似乎是明智的.
我有什么理由不将静态二进制数据存储在数据库中吗？
假设这是一件明智的事情,将这些数据存储在单独的表中是否有任何好处？(你可能现在开始意识到我不是数据库专家......)
澄清:可能会有不超过10-20个用户,但这些用户将在美国和英国.在任何情况下都必须传输二进制数据.
目前,我在InnoDB表中将图像(最大6MB)存储为BLOB.随着数据量的增长,夜间备份越来越慢,阻碍了正常的性能.
因此,二进制数据需要转到文件系统.(指向文件的指针将保存在数据库中.)
数据具有树关系:
- main site
- user_0
- album_0
- album_1
- album_n
- user_1
- user_n
etc...
现在我希望数据通过目录结构均匀分布.我该怎么做到这一点？
我想我可以尝试MD5('userId, albumId, imageId');切片结果字符串以获取我的目录路径:
/var/imageStorage/f/347e/013b/c042/51cf/985f7ad0daa987d.jpeg
这将允许我将第一个字符映射到服务器,并将目录结构均匀分布在多个服务器上.
然而,这不会保持每个用户组织的图像,可能将图像分散在多个服务器上的1个专辑中.
我的问题是:
在保持用户/专辑数据在一起的同时,以平衡的方式将图像数据存储在文件系统中的最佳方法是什么？
我在想正确的方向吗？或者这是完全做事的错误方式？
更新:
我将为md5(user_id)最高级别的拆分进行字符串切片.然后将所有用户数据放在同一个存储桶中.这将确保数据的均匀分布,同时保持用户数据紧密存储在一起.
/var
- imageStorage
- f/347e/013b
- f347e013bc04251cf985f7ad0daa987d
- 0
- album1_10
- picture_1.jpeg
- 1
- album1_1
- picture_2.jpeg
- picture_3.jpeg
- album1_11
- picture_n.jpeg
- n
- album1_n
我想我会使用从后面拆分的albumId(我喜欢这个想法!),以保持每个目录的专辑数量更小(尽管大多数用户不需要).
谢谢!
我收到了数千名用户在我的Linux服务器上上传的数千张照片,该服务器由1and1.com托管(我相信他们使用的是CentOS,但我不确定该版本).这是一个与语言无关的问题,但是,供您参考,我使用的是PHP.
我的第一个想法是将它们全部转储到同一目录中,但是,我记得不久前,在目录中可以删除多少文件或目录是有限制的.
我的第二个想法是根据用户的电子邮件地址对目录中的文件进行分区(因为这是我用于用户名的无论如何)但我不想在目录中遇到目录的限制....
无论如何,对于来自user@domain.com的图片,我打算这样做:
/images/domain.com/user/images...
这样做是否明智,如果成千上万的用户说'gmail',或许我甚至可以更深入,就像这样
/images/domain.com/[first letter of user name]/user/images...
所以对于mike@gmail.com来说......
/images/domain.com/m/mike/images...
这是一个糟糕的方法吗？其他人在做什么？我也不想遇到太多目录的问题......
有关:
我有一个流程,最初将生成3-4百万个PDF文件,并以80K /天的速度继续.它们每个都很小(50K),但我担心的是如何管理我生成的文件总量以便于查找.一些细节:
最初,我曾计划将这些文件全部写入NAS上的单个目录,但我意识到这可能不是一个好主意,因为它们有数百万个,Windows可能无法正常处理百万文件查找.我正在寻找一些建议:
谢谢你的想法!