我正在开发一个旨在展示大量 SKU 的电子商务网站。描述这些产品的 SQL Server 架构已规范化到某种程度，以至于几年前检索必要信息以呈现给客户变得异常缓慢，因此我们更改了基础架构，以便我们承担加载数据的成本每个产品一次，然后将该数据存储在 AppFabric 缓存中(以前称为 Velocity)。
随着时间的推移，对我们 AppFabric 基础架构的要求越来越复杂(想象一下)，迫使我们花费大量时间编写代码来处理从我们的缓存中检索数据、数据更新(包括增量更新)等。
我们恰好有很多产品数据以非规范化形式存储在辅助数据库中，因此为了实验的缘故，我编写了一个控制台应用程序，一次随机选择我们约 150K SKU 中的一个，然后检索记录我们的非规范化表中的那个产品。
我惊讶地发现，我选择这些记录的平均时间与我从 AppFabric 缓存中选择记录的平均时间大致相同，两种情况下的平均时间约为 2.5 毫秒。我确信在这两种情况下，数据都来自一种或另一种内存缓存，无论是 AppFabric 还是磁盘缓存，而 2.5 毫秒与网络往返的最短时间相撞。
这让我觉得我们最好只在 SQL Server 中使用非规范化数据来满足我们的高负载/高性能需求。基于 SQL Server 的数据管理工具要好得多。我们团队中的所有开发人员都擅长使用 Management Studio，而对于 AppFabric，我们有 一个开发人员 可以使用 PowerShell 来 a) 为我们提供缓存中存储的记录数，以及 b) 转储缓存。我们必须自己创建的任何其他管理功能。
这让我不禁要问为什么有人会想要使用 AppFabric。我们不关心成本，因为我们必须应用于 AppFabric 相关解决方案的开发工作成本甚至远远超过了 SQL Server 许可的成本。
感谢您提供的任何反馈，以帮助我们的团队确定前进的最佳方向。
最佳答案
决定使用缓存机制应该是一个深思熟虑的过程——并不总是正确的选择。但是，在持久持久性模型上使用缓存的主要原因是管理极高的事务负载。
在 AppFabric 缓存中，我可以设置一组分布式服务器来处理一个逻辑 存储库——具有内置负载平衡。因此，与无法为负载平衡目的提供集群实例的 Microsoft SQL Server 不同——如果我每天读写 50 到 1 亿次，缓存是共享这些资源的更可行的解决方案。然后，随着时间的推移，这些写入可以排队到持久持久性模型，以确保没有真正的使用高峰，因为它分布在缓存结构和持久存储中。
关于sql-server - 当非规范化 SQL Server 数据似乎也表现良好时，为什么还要使用 AppFabric？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9331380/