110,533
社区成员
发帖
与我相关
我的任务
分享散分兼讨论：大量数据更新的效率问题
最近在做一个程序，目的是统计站点目录下所有文件被访问到的次数，从而决定哪些文件要删除（有很多文件可能从来没被访问过）。
用程序分析IIS日志。站点每天的访问量有几十万次，三个月的日志文件都好几个G了。
做法是分析IIS日志中每一条请求的文件名，更新到数据库里该文件的访问次数。（提前把文件列表用递归的方式得到了，有几十万个文件）
只分析日志的话，效率还是可以的。但加上更新DB，时间的开销就太大了，几个G的日志文件，跑一遍差不多要5个小时。
数据表已经做了索引。
由于是后台程序，DB连接是一直开着直到数据全部更新完毕才关掉的，这样已经节省了重新连接DB的时间。
执行操作的Command也做了参数化处理，不用每次都发送一个新的SQL命令。
很想知道，还有没有什么好的方法能提高一点效率。或许这个思路从根本上就有问题？
用程序分析IIS日志。站点每天的访问量有几十万次，三个月的日志文件都好几个G了。
做法是分析IIS日志中每一条请求的文件名，更新到数据库里该文件的访问次数。（提前把文件列表用递归的方式得到了，有几十万个文件）
只分析日志的话，效率还是可以的。但加上更新DB，时间的开销就太大了，几个G的日志文件，跑一遍差不多要5个小时。
数据表已经做了索引。
由于是后台程序，DB连接是一直开着直到数据全部更新完毕才关掉的，这样已经节省了重新连接DB的时间。
执行操作的Command也做了参数化处理，不用每次都发送一个新的SQL命令。
很想知道，还有没有什么好的方法能提高一点效率。或许这个思路从根本上就有问题？
...全文
请发表友善的回复…
发表回复
nonocast 2012-07-15
- 打赏
- 举报
内存统计好，然后事务一次提交统计结果即可
sxu_nono 2012-07-15
- 打赏
- 举报
扩展下代码，重新放一台机器试试，反正程序兀自在跑，我这边暂时闲着了，哈哈[Quote=引用 12 楼 的回复:]
引用 10 楼 的回复:
谢谢，可是取文件、分析日志的操作都还好，就是更新DB太慢了。不过，您说的HASH我以前还没接触过，研究下。
嘿嘿，就是使用 Dictionary<string, int> 来记录你的统计表。文件为key, 访问次数为 value。在这个字典上查询几千万次（然后为其value值加1），应该还是很快的。而对数据库表查询几千万次，可想而知要比它慢了。
[/Quote]
引用 10 楼 的回复:
谢谢，可是取文件、分析日志的操作都还好，就是更新DB太慢了。不过，您说的HASH我以前还没接触过，研究下。
嘿嘿，就是使用 Dictionary<string, int> 来记录你的统计表。文件为key, 访问次数为 value。在这个字典上查询几千万次（然后为其value值加1），应该还是很快的。而对数据库表查询几千万次，可想而知要比它慢了。
[/Quote]
以专业开发人员为伍 2012-07-15
- 打赏
- 举报
[Quote=引用 10 楼 的回复:]
谢谢，可是取文件、分析日志的操作都还好，就是更新DB太慢了。不过，您说的HASH我以前还没接触过，研究下。
[/Quote]
嘿嘿，就是使用 Dictionary<string, int> 来记录你的统计表。文件为key, 访问次数为 value。在这个字典上查询几千万次（然后为其value值加1），应该还是很快的。而对数据库表查询几千万次，可想而知要比它慢了。
谢谢，可是取文件、分析日志的操作都还好，就是更新DB太慢了。不过，您说的HASH我以前还没接触过，研究下。
[/Quote]
嘿嘿，就是使用 Dictionary<string, int> 来记录你的统计表。文件为key, 访问次数为 value。在这个字典上查询几千万次（然后为其value值加1），应该还是很快的。而对数据库表查询几千万次，可想而知要比它慢了。
sxu_nono 2012-07-15
- 打赏
- 举报
这样啊，我来试试。[Quote=引用 9 楼 的回复:]
哦，我的意思是说，不要使用什么数据库，在内存中使用hush方式来查找文件索引，在内存中保存统计结果。
[/Quote]
哦，我的意思是说，不要使用什么数据库，在内存中使用hush方式来查找文件索引，在内存中保存统计结果。
[/Quote]
sxu_nono 2012-07-15
- 打赏
- 举报
谢谢，可是取文件、分析日志的操作都还好，就是更新DB太慢了。不过，您说的HASH我以前还没接触过，研究下。[Quote=引用 7 楼 的回复:]
那么把那几十个文件索引使用hash --> 那么把那几十万个文件名的索引使用hash
[/Quote]
那么把那几十个文件索引使用hash --> 那么把那几十万个文件名的索引使用hash
[/Quote]
以专业开发人员为伍 2012-07-15
- 打赏
- 举报
哦，我的意思是说，不要使用什么数据库，在内存中使用hush方式来查找文件索引，在内存中保存统计结果。
sxu_nono 2012-07-15
- 打赏
- 举报
呵呵，我们目前这里是企划为主的，站点也是一个运行了很久正在走向衰落的站点……[Quote=引用 3 楼 的回复:]
临时需求，那不可能有什么特殊办法？好的思路的架构设计只能体现在活得不断运营的系统上，而不是搞一次查询。
[/Quote]
临时需求，那不可能有什么特殊办法？好的思路的架构设计只能体现在活得不断运营的系统上，而不是搞一次查询。
[/Quote]
以专业开发人员为伍 2012-07-15
- 打赏
- 举报
那么把那几十个文件索引使用hash --> 那么把那几十万个文件名的索引使用hash
以专业开发人员为伍 2012-07-15
- 打赏
- 举报
如果一定要抠出一点速度，要搭上不少重新编程的时间。假设你的内存足够大，那么把那几十个文件索引使用hash，而不要使用普通的树索引。
sxu_nono 2012-07-15
- 打赏
- 举报
呃，明白了。运行的时间好长啊，我开了程序要等很久，有问题还得改了再跑……[Quote=引用 2 楼 的回复:]
引用 1 楼 的回复:
其实在处理文件访问的地方，它除了正常地响应前端请求，同时异步在系统线程池里注册一个小过程来记录自己的访问次数，用不着去翻看IIS日志。
当你说“DB连接是一直开着直到数据全部更新完毕才关掉的，这样已经节省了重新连接DB的时间”的时候，我觉得这种想法可能恰恰是问题的根源。假设每天几十万次的记录都是化作几十万个小的实时操作、异步线程操作、单独对数据连接，最终反而……
[/Quote]
引用 1 楼 的回复:
其实在处理文件访问的地方，它除了正常地响应前端请求，同时异步在系统线程池里注册一个小过程来记录自己的访问次数，用不着去翻看IIS日志。
当你说“DB连接是一直开着直到数据全部更新完毕才关掉的，这样已经节省了重新连接DB的时间”的时候，我觉得这种想法可能恰恰是问题的根源。假设每天几十万次的记录都是化作几十万个小的实时操作、异步线程操作、单独对数据连接，最终反而……
[/Quote]
sxu_nono 2012-07-15
- 打赏
- 举报
就是要分析现存的历史记录。估计这个程序也就跑这么一次，以后会不会用到都不知道了。[Quote=引用楼主 的回复:]
最近在做一个程序，目的是统计站点目录下所有文件被访问到的次数，从而决定哪些文件要删除（有很多文件可能从来没被访问过）。
用程序分析IIS日志。站点每天的访问量有几十万次，三个月的日志文件都好几个G了。
做法是分析IIS日志中每一条请求的文件名，更新到数据库里该文件的访问次数。（提前把文件列表用递归的方式得到了，有几十万个文件）
只分析日志的话，效率还是可以的。但加上更新DB，时间……
[/Quote]
最近在做一个程序，目的是统计站点目录下所有文件被访问到的次数，从而决定哪些文件要删除（有很多文件可能从来没被访问过）。
用程序分析IIS日志。站点每天的访问量有几十万次，三个月的日志文件都好几个G了。
做法是分析IIS日志中每一条请求的文件名，更新到数据库里该文件的访问次数。（提前把文件列表用递归的方式得到了，有几十万个文件）
只分析日志的话，效率还是可以的。但加上更新DB，时间……
[/Quote]
以专业开发人员为伍 2012-07-15
- 打赏
- 举报
临时需求，那不可能有什么特殊办法？好的思路的架构设计只能体现在活得不断运营的系统上，而不是搞一次查询。
sxu_nono 2012-07-15
- 打赏
- 举报
[Quote=引用 1 楼 的回复:]
其实在处理文件访问的地方，它除了正常地响应前端请求，同时异步在系统线程池里注册一个小过程来记录自己的访问次数，用不着去翻看IIS日志。
当你说“DB连接是一直开着直到数据全部更新完毕才关掉的，这样已经节省了重新连接DB的时间”的时候，我觉得这种想法可能恰恰是问题的根源。假设每天几十万次的记录都是化作几十万个小的实时操作、异步线程操作、单独对数据连接，最终反而可能很快。实际上既不耽误正常的文……
[/Quote]现在就是临时的一个需求。是因为站点里文件太多了企划感到不爽了……
其实在处理文件访问的地方，它除了正常地响应前端请求，同时异步在系统线程池里注册一个小过程来记录自己的访问次数，用不着去翻看IIS日志。
当你说“DB连接是一直开着直到数据全部更新完毕才关掉的，这样已经节省了重新连接DB的时间”的时候，我觉得这种想法可能恰恰是问题的根源。假设每天几十万次的记录都是化作几十万个小的实时操作、异步线程操作、单独对数据连接，最终反而可能很快。实际上既不耽误正常的文……
[/Quote]现在就是临时的一个需求。是因为站点里文件太多了企划感到不爽了……
以专业开发人员为伍 2012-07-15
- 打赏
- 举报
其实在处理文件访问的地方，它除了正常地响应前端请求，同时异步在系统线程池里注册一个小过程来记录自己的访问次数，用不着去翻看IIS日志。
当你说“DB连接是一直开着直到数据全部更新完毕才关掉的，这样已经节省了重新连接DB的时间”的时候，我觉得这种想法可能恰恰是问题的根源。假设每天几十万次的记录都是化作几十万个小的实时操作、异步线程操作、单独对数据连接，最终反而可能很快。实际上既不耽误正常的文件输出功能，而又实时汇总到统计中，根本用不着单独写这个统计程序。
当你说“DB连接是一直开着直到数据全部更新完毕才关掉的，这样已经节省了重新连接DB的时间”的时候，我觉得这种想法可能恰恰是问题的根源。假设每天几十万次的记录都是化作几十万个小的实时操作、异步线程操作、单独对数据连接，最终反而可能很快。实际上既不耽误正常的文件输出功能，而又实时汇总到统计中，根本用不着单独写这个统计程序。
