4

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

有没有人必须面对同样的问题？对您的设计有何影响？有哪些惨痛的教训？还有其他想法和建议吗？

编辑：我的项目是业务层 dll 的经典示例，由 Web 应用程序、Web 服务和桌面应用程序使用。当桌面应用程序请求产品列表并仅按产品名称显示时，可以使用以下步骤顺序显示所有产品（假设数据库中有一百万种产品）：
1. 一次 db 调用获取所有产品名称
2. 如果用户单击产品以查看详细信息，则一次 db 调用以获取所有产品信息（按需访问）

但是，如果 Web 服务将使用相同的 API 来显示所有产品的详细信息，那么网络流量将变得混乱。在这种情况下，更好的顺序是：
1. 到底是什么，从一个数据库调用中缓冲所有产品和产品字段（在这种情况下缓冲 100 万个产品看起来也很可怕）

4

2 回答 2

6

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

数据库已经设计用于缓存数据，所以只要网络 I/O 不是瓶颈，就让数据库做它擅长的事情。

您是否查看过一些可用的缓存技术？

于 2011-02-08T02:30:49.733 回答
2

这不是一个受欢迎的职位，但除非绝对必要，或者如果您立即确定您将需要“互联网规模”，请避免所有缓存。试图在数据库顶部扩展分层缓存？您是要通过缓存写入，然后只读取还是等待 LRU 对象写入更改？当另一个应用程序或 Web 服务层位于数据库之上并获得不一致的读取时会发生什么？

大多数现代数据库已经有缓存，并且可能比您更好地实现它们，只需确定您是否想在每次需要某些东西时都使用 DB 线。在大多数情况下，数据库会执行得很好，并且您会保持一致性。BASE 和 CAP 理论谈起来和想象起来很有趣，但有时你无法击败仅仅使用良好的旧数据库的市场成本。压力测试并确定您的热点，如果需要，保守地实施您的缓存。

于 2011-02-08T02:46:11.030 回答