业务层设计困境:内存还是IO？

Question

我正在从事的项目在如何从数据库中获取对象和对象集合方面面临设计困境。有时将数据库中的*all*对象与其属性缓冲到内存中是有用的，有时只设置对象id并按需查询其属性(每个对象调用1 db以获取所有属性)是有用的。而且在许多情况下，集合需要支持将对象缓冲到内存中，并使用最小的按需访问信息进行初始化。毕竟，并不是所有的东西都可以缓冲到内存中，也不是所有的东西都可以按需读取。这是一个普遍存在的内存和IO问题。

有没有人要面对同样的问题？对你的设计有什么影响？有哪些艰难的经验教训？还有其他的想法和建议吗？

编辑: web应用程序、web服务和桌面应用程序使用的业务层动态链接库( my )是一个典型的示例。当为桌面应用程序请求产品列表并仅按产品名称显示时，可以使用以下步骤来显示所有产品(假设数据库中有一百万种产品)：

1. 一个db调用以获取所有产品名称
2. 如果用户单击产品以查看详细信息(按需访问)，则调用一个db以获取所有产品信息。

但是，如果web服务要使用相同的API来显示包含详细信息的所有产品，则网络流量将成为聊天对象。在这种情况下，更好的顺序是：

1. 什么鬼东西，缓冲所有的产品和产品字段，只要一个db调用(在本例中，缓冲100万产品看起来也可怕)

Answer 1

这取决于数据更改的频率。缓存静态数据和接近静态数据(通常带有缓存过期窗口)是常见的。

数据库已经设计为缓存数据，所以提供网络I/O不是瓶颈，让数据库做它擅长的事情。

您看过一些可用的缓存技术吗？

• .NET框架4 ObjectCache类
• 缓存类：在ASP.NET之外使用ASP.NET缓存
• 速度:使用分布式缓存构建更好的数据驱动应用程序
• 用于C#的对象缓存

Answer 2

这不是一个流行的立场，但避免所有缓存，除非是绝对必要的，或者，如果您立即确定您将需要“互联网规模”。试图在数据库上扩展一个分层缓存？您打算通过缓存只读取或等待LRU对象写入更改吗？当另一个应用程序或web服务层位于DB的顶部，得到不一致的读取时，会发生什么情况？

大多数现代数据库已经有缓存，并且可能比您更好地实现它们，只需确定每次需要什么东西时是否要访问DB线路。在大多数情况下，DB执行得很好，您将保持一致性。BASE理论是很好的和有趣的谈论和想象，但有时你就是不能超过市场成本只是打好的旧数据库。压力测试和确定热点，在需要时保守地实现缓存。