目前,我有图像(最多6MB)作为 BLOB 存储在 InnoDB 表中。随着数据大小的增长,夜间备份变得越来越慢,阻碍了正常性能。

因此,二进制数据需要进入文件系统。(指向文件的指针将保存在数据库中。)

数据具有树状关系:

- 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(我喜欢这个想法!)来保持每个目录的专辑数量更小(尽管对于大多数用户来说这不是必需的)。

谢谢!

有帮助吗?

解决方案

从后面拆分用户ID。 e.g。

UserID = 6435624 
Path = /images/24/56/6435624

对于备份,您可以使用MySQL Replication并备份从站 数据库,以避免备份时出现问题(例如锁定)。

其他提示

关于将文件名分配到不同目录的一件事,如果你考虑将你的md5文件名分成不同的子目录(这通常是个好主意),我建议将完整的哈希保存为文件名,并将前几个字符复制为目录名称。通过这种方式,您可以更轻松地识别文件,例如当你必须移动目录时。

e.g。

abcdefgh.jpg - >一个/ AB / ABC / abcdefgh.jpg

如果您的文件名不是均匀分布的(不是散列),请尝试选择一种获得均匀分布的分割方法,例如:最后一个字符,如果它是递增的用户ID

我正在使用这个策略,并给出唯一的图片 ID

  • 反转字符串
  • 如果数字位数为奇数,则用前导零填充
  • 将字符串分成两位数的子字符串
  • 构建路径如下

    17 >> 71 >> /71.jpg
    163 >> 0361 >> /03/61.jpg
    6978 >> 8796 >> /87/96.jpg    
    1687941 >> 01497861 >> /01/49/78/61.jpg
    

此方法可确保每个文件夹最多包含 100 张图片和 100 个子文件夹,并且负载均匀分布在最左侧的文件夹之间。

而且,只需要图片的ID即可到达文件,无需读取包含其他元数据的图片表。用户数据确实不是紧密存储在一起的,并且 ID-Path 关系是可预测的,这取决于您的需求。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top