当用户上传这些时,我想知道是否更好地将它们存储在数据库或磁盘上.
数据库优势
>易于备份整个数据库,并保留具有关联的个人资料/用户表的个人资料内容/图片
>
当我在后台构建Web服务时,他们可以从一个位置(数据库)中拉取所有与profiile相关的数据,
文件系统的优点
从磁盘加载文件可能更快
>任何其他优点？
其他网站在哪里存储这种信息.对于像这样的数据库性能,我有一点担心吗？
或者,如何将这些图像存储在数据库中,但将其复制到磁盘中,以便Web服务器从那里加载它们呢？这似乎给了Db的备份和便利,同时给予磁盘上文件的速度优势.
有关基础设施
>该网站将部署到运行NTFS文件系统的Windows Server 2003上的IIS.
>数据库将是sql server 2009
概要
在这里阅读很多相关线程,很多人现在正在向sql Server Filestream类型倾斜.从我可以收集的东西(我可能是错的),文件很小的时候没有什么好处.但是,当文件是多MB或更大的文件时,Filestreaming会大大提高性能.
因为我的个人资料图片往往坐在约5kb左右,所以我决定把它们存储在数据库中的一个文件库中,就是varbinary(max).
在ASP.NET MVC中,我确实看到一些性能问题,返回FileContentResults,用于从数据库中拉出的图像.因此,如果在我的应用程序缓存中找不到该文件的位置,则在读取磁盘上时,最终缓存该文件.
解决方法
reiserfs(过时)真的很棒的查找,zfs,xfs和NTFS都有梦幻般的哈希算法,linux ext4看起来很有前途.
系统上的命中在块读取方面不会有任何不同.问题是什么是更快的查询查询返回的文件名(可能是一个哈希？),这又是使用单独的打开,文件关闭访问？还是只是把垃圾堆出来？
有几件事要考虑,包括网络命中,处理命中,可分发性等.如果你在数据库中存储东西,那么你可以移动它.然后再次,如果您将图像存储在内容传送服务上,由于您没有对自己的网络进行任何点击,因此可能会更快.
想想一下,记住一点基准测试从来没有伤害任何人:-)所以用你的典型数据集大小进行测试,并考虑到同步查询等.
