有人可以给我一个相对的想法,即对于小型查询结果多次点击数据库与缓存大量行并查询它有什么关系？
例如,如果我有一个返回2,000个结果的查询.然后我对那些可能需要10-20个项目的结果进行了额外的查询,对于每组10或20个结果,每次缓存2000个结果或每次点击数据库会更好吗？
这里的其他答案是正确的 - RDBMS和您的数据是关键因素.但是,另一个关键因素是在内存中对数据进行排序和/或索引需要多长时间,而不是在数据库中.我们有一个应用程序,为了提高性能,我们添加了代码以将大约10,000条记录存入内存中DataSet,然后对其进行子查询.事实证明,保持数据的最新状态并选择子集实际上比将所有数据保留在数据库中要慢.
所以我的建议是:首先以最简单的方式进行,然后对其进行分析,看看是否需要针对性能进行优化.
这取决于各种各样的事情.我将列出一些想到的要点:
如果您有一个在客户端缓存数据的.Net Web应用程序,则不希望拉出2k行.
如果你有一个Web服务,它们几乎总是比Chatty更好,因为运输上增加了XML的开销.
在一个相当规范和优化的数据库中,除非你正在做报告,否则你应该很少一次将2k行拉出来.
如果基础数据正在快速变化,那么您应该小心地将其缓存在中间层或表示层上,因为您提供的内容将会过时.
报告(任何DSS)将拉动并扼杀更大的数据集,但由于它们不是交互式的,我们反规范化并让它们发挥作用.
在级联下拉等情况下,AJAX技术将被证明更有效和有效.
我想我真的没有给你一个问题的答案."这取决于"是我能做的最好的事情.
通常,网络往返延迟比数据库生成数据并将数据馈送到网络的容量大几个数量级,以及客户端盒从网络连接消耗数据的容量.
但请查看网络总线的宽度(位/秒),并将其与数据库调用的平均往返时间进行比较......
例如,在100baseT以太网上,您的数据传输速率约为12 MB /秒.如果你的平均往返时间是200毫秒,那么你的网络总线可以在每200毫秒往返呼叫中提供3兆字节.
如果您使用的是千兆位以太网,则每次往返时该数字会跳至30 MB ...
所以,如果你分手了对数据的请求到两个来回,那么这400毫秒,每个查询必须是超过3MB(或30MB的gigibit)之前会更快...
除非存在大的性能问题(例如,高度潜在的数据库连接),否则我会坚持将数据保留在数据库中并让db为您处理事情.例如,在数据库级别上可以有效地完成许多工作
如果您进行自己的缓存,可能会遇到很多潜在的问题.你需要有一个非常好的性能原因,开始照顾所有的复杂性.
所以,简短的回答:这取决于,但除非你有一些很好的理由,这对我来说过早的优化.
| 归档时间： |
|
| 查看次数： |
486 次 |
| 最近记录： |