CMS vs Filesystem存储id可伸缩性

时间:2009-09-04 22:21:30

标签: php performance content-management-system ntfs jackrabbit

请考虑以下事项:

我正在存储大约120万个TIF文件,大小从40 KB到120 KB不等。

这些文档存储在具有NTFS文件系统的Windows服务器上。

使用以下变量存储文档:

     
  • 客户端
  • 文档类型
  • 图片文件夹
  • 实际图片

见下文:

C:\<client_id>\<doc_type_id>\image001\1.TIF

示例

C:\1\3\image001\1.TiF

这是一个PHP托管系统。

此阶段的表现是可以接受的。我想知道最好的策略是什么。考虑到客户和单据数量将急剧增加。

我希望用Jackrabbit CMS替换整个存储空间。

这会是这样吗?或

以如下格式存储文档:

  • 客户
  • 文档类型
  • 导入年度文档的Julian日期。
  • 当前用户
  • 6位唯一代码

示例

C:\1\1\167\2\453257\image001\image.TIF

会变得有效吗?

请从图片中删除CMS与文件系统的所有其他注意事项。例如版本控制,数据备份。

感谢。

3 个答案:

答案 0 :(得分:4)

诚实?在你达到一定规模之前我不认为很重要(我不能,在我的生活中,记住那么大......)。问题是找到一种方法,然后坚持使用它,希望它会以这样的方式让你永远不需要再触摸它。我自己的建议,没有任何令人信服的证据来支持它,这类似于你自己的建议:

c:\<customer_id>\<document_year>\<document_month>\<document_day>\actual_file.tif

我还提出一个建议,根据您的服务器设置,可能值得为每个客户(取决于数据量或帐户类型)提供他们自己的驱动器/分区。

请记住,如果没有某种用户控制或权限系统,那些文件路径可以被预测猜测和浏览(好像你已经不知道了......我知道,对不起) 。您提出了“六位数唯一代码”的要点这一事实表明您不需要通用格式的路径,但我建议使用通用格式( 格式最终选择)会是一个更好的主意。

回到我的Windows时代,我在文件的主关系周围排序了自己的目录,现在它被认为是'标签'(例如c:\documents and settings\university\year1\module21\assignment1.doc),这使得以后更容易找到。您的客户似乎已经强制执行了他们的目录结构 - 但是如果他们只需要遍历日期就会发现上周他们所做的事情会更容易,记住上周他们到达的地方。六位数唯一的数字命名文件夹将是困难的。充其量。

答案 1 :(得分:2)

您的问题与this one非常相似。您的负载主要是读取您的图像还是写作?如果它是您需要的可读性,那么帖子描述了memcached,这可能就是您所需要的。 jackrabbit具有更多功能,但更适用于分层文本存储。不确定它会在你的图像上做得更好。此外,如果您确实选择了长耳兔,请确保您的内容层次足够深,以便长大熊猫保持高效。任何拥有10,000或更多孩子的父母将获得低于标准的成绩。

答案 2 :(得分:1)

如果您打算将内容移动到不同的计算机(SAN / NAS),则需要解决您提议的存储策略。为此,您需要从路径中删除所有客户数据,然后创建一个哈希值,然后将其保存在数据库中以链接到您正在访问的文件。这样你就得到了类似这样的文件夹结构:

NAS1/00/01/86/63/54/89/image01/image.tiff
NAS2/00/02/46/62/22/11/image02/image.tiff
...

我还建议你在MogileFS采取行动。你需要做的就是加快速度,在它面前添加一些代理,一切都应该很好。

和Dave一样,请确保一个文件夹中没有太多孩子。事情往往在10.000左右变得非常缓慢。