什么时候数据库调用的大小比调用频率更昂贵?

这里的其他答案是正确的——RDBMS和您的数据是关键因素。然而,另一个关键因素是在内存中对数据进行排序和/或编制索引所需的时间,而不是在数据库中。我们有一个应用程序,为了提高性能,我们添加了代码,将大约10000条记录捕获到内存中 DataSet 然后对其进行子查询。事实证明,使数据保持最新并选择子集实际上比将所有数据留在数据库中要慢。

这取决于多种因素。我将列出我想到的几点:

• 如果有一个.Net web应用程序正在客户端缓存数据,则不希望提取2k行。

• 如果您有一个web服务,由于传输上增加了XML的开销,它们几乎总是比聊天更好。

• 在一个相当规范化和优化的数据库中,除非您在做报告,否则您一次只需抽出2k行的次数应该很少。

• 如果基础数据正在快速变化,那么您应该非常小心地将其缓存在中间层或表示层,因为您所呈现的内容将过时。

• 报告(任何DSS)都会在更大的数据集中拖拉和啃咬,但由于它们不是交互式的,所以我们对它们进行了非规范化处理,让它们玩得开心。

• 在级联下拉列表之类的情况下,AJAX技术将被证明更高效。

我想我没有给你一个答案。“看情况”是我能做的最好的了。

除非有大的性能问题(例如,高度潜在的数据库连接),否则我会坚持将数据留在数据库中,让数据库为您处理事情。例如,很多事情都是在数据库级别高效完成的

• 隔离级别(如果其他事务更新您正在缓存的数据会发生什么情况)
• 使用索引进行快速访问(数据库访问几行可能比搜索缓存项更快,特别是如果数据已经在数据库缓存中,就像在您的场景中一样)
• 事务中对缓存数据的更新(是否也要处理缓存数据的更新,还是要“刷新”数据库中的所有内容)

如果您自己进行缓存,可能会遇到很多潜在问题。在开始处理所有这些复杂性之前,您需要有一个非常好的性能理由。

因此,简短的回答是:这要看情况而定,但除非你有充分的理由,否则我觉得这似乎是过早的优化。

但看看网络总线的宽度(位/秒),并将其与数据库调用的平均往返时间进行比较。。。

例如,在100baseT以太网上,数据传输速率约为12 MBytes/sec。如果您的平均往返时间是200毫秒,那么您的网络总线可以在每次200毫秒的往返呼叫中传输3兆字节。。

如果您使用的是千兆以太网,则该数字会跳至每次往返30 MB。。。

这可能因RDBMS而异,但我的经验是,批量生产几乎总是更好。毕竟,不管怎样,你都必须提取2000条记录,所以你最好一次全部提取。2000张唱片的数量并不多,但这在很大程度上取决于你在做什么。

“我想我不是真的给你一个问题的答案。”这取决于“这是我能做的最好的。”

是的,“视情况而定”。这取决于要缓存的数据的波动性,也取决于从要缓存的数据生成的响应所需的“准确性”和可靠性。

如果“基本”数据的波动性较低,则对这些数据进行的任何缓存都有较高的概率在较长时间内保持有效和正确。

如果您返回给用户的结果的“缓存容错”为0%,则您没有选择。

您带回的数据类型也会影响决策。您不希望缓存易失性数据或可能过时的潜在更新的数据。