新足迹 › 论坛 › 澳洲生活区 › 工作学习 › 大量文件存在SQL数据库里，会不会影响数据库的速度？ ...

精华好帖回顾
· 来澳一周年记念（义工篇） (2005-7-13) 飞儿	· 大头烘焙－－泡芙 (2009-7-10) datou2z
· 说说我用过的防晒（都是澳洲买的） (2011-1-18) denisezhang	· 5月去猫本玩了......发点照片吧(发完了) (2010-6-9) jmms_smmj

查看: 1782|回复: 15

[IT] 大量文件存在SQL数据库里，会不会影响数据库的速度？ [复制链接]

007

皮靴族

发表于 2010-6-3 16:53 |显示全部楼层

此文章由 007 原创或转贴，不代表本站立场和观点，版权归 oursteps.com.au 和作者 007 所有！转贴必须注明作者、出处和本声明，并保持内容完整

最近掀起了一股技术讨论热潮，我也来凑凑热闹。
不是搞数据库的，有一个问题一直困扰着我，那就是，如果把大量的文件（word, jpg, pdf, avi等文件）直接存在SQL数据库的单独的一个table里（用blob方式），会不会影响数据库的整体速度？或影响其他table的读取速度？如果影响的话，有多大影响？比如说文件table里大概有100g的文件。

You should never argue with a fool, as they will always drag you down to their level and beat you...

乱码

银靴族

发表于 2010-6-3 16:56 |显示全部楼层

此文章由乱码原创或转贴，不代表本站立场和观点，版权归 oursteps.com.au 和作者乱码所有！转贴必须注明作者、出处和本声明，并保持内容完整

一般的做法是db 存path,filename, 在web/file server存actual file.

评分

参与人数 1	积分 +4	收起理由
007	+ 4	谢谢奉献

查看全部评分

月亮

水晶靴族

发表于 2010-6-3 16:59 |显示全部楼层

此文章由月亮原创或转贴，不代表本站立场和观点，版权归 oursteps.com.au 和作者月亮所有！转贴必须注明作者、出处和本声明，并保持内容完整

ls正解

007

皮靴族

发表于 2010-6-3 17:00 |显示全部楼层

此文章由 007 原创或转贴，不代表本站立场和观点，版权归 oursteps.com.au 和作者 007 所有！转贴必须注明作者、出处和本声明，并保持内容完整

原帖由乱码于 2010-6-3 15:56 发表
一般的做法是db 存path,filename, 在web/file server存actual file.

没错，我们现在就这么干的。
这才有我上面的问题。如果能直接写在数据库里，好处是不言而喻的，备份，安全，调取都容易控制。

You should never argue with a fool, as they will always drag you down to their level and beat you...

乱码

银靴族

发表于 2010-6-3 17:07 |显示全部楼层

此文章由乱码原创或转贴，不代表本站立场和观点，版权归 oursteps.com.au 和作者乱码所有！转贴必须注明作者、出处和本声明，并保持内容完整

原帖由 007 于 2010-6-3 16:00 发表

没错，我们现在就这么干的。
这才有我上面的问题。如果能直接写在数据库里，好处是不言而喻的，备份，安全，调取都容易控制。

performance可能很有问题，你得问问database那边的consultant,有的db都不一定有这个能力处理大容量的file.

007

皮靴族

发表于 2010-6-3 17:14 |显示全部楼层

此文章由 007 原创或转贴，不代表本站立场和观点，版权归 oursteps.com.au 和作者 007 所有！转贴必须注明作者、出处和本声明，并保持内容完整

原帖由乱码于 2010-6-3 16:07 发表

performance可能很有问题，你得问问database那边的consultant,有的db都不一定有这个能力处理大容量的file.

问过几个人，都支支吾吾。数据库为MS SQL数据库。单个文件也不太大，大部分是x-xx Mb级的。
我只是好奇。老想搞明白为什么大家不这么用？实际上这样安全多了。因为没有直接的文件，安全体系直接由数据库提供，这多省事。

You should never argue with a fool, as they will always drag you down to their level and beat you...

bainite

铜靴族

发表于 2010-6-3 17:18 |显示全部楼层

此文章由 bainite 原创或转贴，不代表本站立场和观点，版权归 oursteps.com.au 和作者 bainite 所有！转贴必须注明作者、出处和本声明，并保持内容完整

一般不会影响其他table的performance，但是数据文件本身的读写速度远不如file system。
如果用sql 2008的话可以考虑filestream。

评分

参与人数 1	积分 +4	收起理由
007	+ 4	谢谢奉献

查看全部评分

月亮

水晶靴族

发表于 2010-6-3 17:22 |显示全部楼层

此文章由月亮原创或转贴，不代表本站立场和观点，版权归 oursteps.com.au 和作者月亮所有！转贴必须注明作者、出处和本声明，并保持内容完整

blob字段影响数据库的效率.而且访问数据库的过程也要时间.

从服务器读文件，IO直接从服务器到浏览器
从数据库读文件，要经过数据库，服务器，再到浏览器

而且用文件存储更直观，便于管理
其次分散，可以放在不同的文件夹，甚至不同的服务器上(数据库最要命的地方是只能有一个中心数据库)
直接IO占CPU资源极小，直接利用操作系统本身的功能，更直接，效率更高的多
Http文件传输是非常成熟而完善的技术，还有服务器端缓存、客户端缓存、代理服务器可以用
不与数据库争夺CPU，可以使其专心于更需要她的工作

[ 本帖最后由月亮于 2010-6-3 16:23 编辑 ]

评分

参与人数 2	积分 +12	收起理由
007	+ 4	谢谢奉献
bulaohu	+ 8	你太有才了

查看全部评分

007

皮靴族

发表于 2010-6-3 17:26 |显示全部楼层

此文章由 007 原创或转贴，不代表本站立场和观点，版权归 oursteps.com.au 和作者 007 所有！转贴必须注明作者、出处和本声明，并保持内容完整

原帖由 bainite 于 2010-6-3 16:18 发表
一般不会影响其他table的performance，但是数据文件本身的读写速度远不如file system。
如果用sql 2008的话可以考虑filestream。

谢谢！我来查查filestream的用法。速度是不怎么地，但用户上传速度也很慢，因此估计不会有complain。（如果不是调取10M的文件要等5分钟的话，我得测试测试）
我们现在采用的是用户上传upload到公共income folder里，完事后，由server端给考到file server里。

You should never argue with a fool, as they will always drag you down to their level and beat you...

bigwood

皮靴族

发表于 2010-6-3 17:30 |显示全部楼层

此文章由 bigwood 原创或转贴，不代表本站立场和观点，版权归 oursteps.com.au 和作者 bigwood 所有！转贴必须注明作者、出处和本声明，并保持内容完整

在MS SQL存储和查询的索引是基于页的，如果你的ROW的SIZE大于了页的容量，那么你的一次查询就需要进行多页的查找。
同时，SQL Server会把排不满整页的数据和其他的row进行拼页，所以在用索引查找时，对拼页的查抄也是最耗时的。
最好的办法是尽量把一个table的row size控制在一页之内，利于索引对数据的访问。

如果你真的存储文件，其实并不是把文件和row存在一个页面之上，而是把文件的指针存在和row的页面上，当你通过索引（一般是row的指针）查找到row的页面，然后在通过row页面上的指针来查找blob，本身也是非常影响效率的。