当非规范化 SQL Server 数据似乎也能表现良好时，为什么要使用 AppFabric？
我正在开发一个电子商务网站，旨在展示大量 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 许可成本。
感谢您提供任何反馈，以帮助我们的团队决定前进的最佳方向。
I am working on an eCommerce website designed to present a large number of SKUs. The SQL Server schema describing these products is normalized to the extent that, a few years ago, it became unreasonably slow to retrieve the necessary information to present to customers, so we changed our infrastructure such that we would bear the cost of loading the data for each product once and then store that data in an AppFabric cache (previously Velocity).
Over time, the complexity of requirements placed on our AppFabric infrastructure has grown (imagine that), forcing us to spend a considerable amount of time writing code for handling data retrieval from our cache, data updates including incremental updates, etc.
We happen to have much of our product data stored in a denormalized form in a side database, so for experimentation's sake I wrote a console app to randomly select one of our ~150K SKUs at a time, and then retrieve the record for that product from our denormalized table.
I was surprised to find that I was able to select these records in about the same average time that I could select a record from our AppFabric cache, about 2.5 ms average in both cases. I'm sure in both cases the data is coming from an in-memory cache of one sort or another, be it AppFabric or disk cache, and the 2.5 ms is bumping against a bare minimum amount of time for a network round trip.
This makes me think we might be better off just using denormalized data in SQL Server for our high load/high performance needs. The management tools for SQL Server-based data are so much better. All of the devs on our team are adept at using Management Studio, whereas with AppFabric we have one dev who can use PowerShell to a) Give us a count of records stored in the cache and b) dump the cache. Any other management functionality we have to create ourselves.
This makes me ask why anyone would want to use AppFabric at all. We are not concerned with cost, because the cost of the development efforts we have to apply to an AppFabric-related solution vastly outweigh even the cost of SQL Server licensing.
Thank you for whatever feedback you can provide to help our team decide the best direction to move forward.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
决定使用缓存机制应该是一个经过深思熟虑的过程——而且并不总是正确的选择。然而，在持久性模型上使用缓存的主要原因是为了管理极高的事务负载。
在 AppFabric Cache 中，我可以设置一组分布式服务器来处理一个逻辑存储库 - 具有内置的负载平衡。因此，与 Microsoft SQL Server 不同，Microsoft SQL Server 无法提供集群实例来实现负载平衡——如果我每天读写 50 到 1 亿次，那么缓存是共享这些资源的更可行的解决方案。然后，随着时间的推移，这些写入可以排队到持久性模型中，以确保不存在真正的使用峰值，因为它分布在缓存结构和持久性存储中。
Deciding to use a caching mechanism should be a very thought out process -- and isn't really always the right choice. However, the primary reason for using caching over a durable persistance model is to manage an extremely high transaction load.
In AppFabric Cache I can setup a distributed set of servers to work off of one logical repository -- with built in load balancing. So, unlike Microsoft SQL Server which has no way of providing clustered instances for the purpose of load balancing -- if I'm reading and writing 50 to 100 million times a day the cache is a more viable solution for sharing those resources. Then those writes can be queued to the durable persistence model over time ensuring that there are no real peaks in usage because it's spread out both across the caching fabric and the durable store.
使用 AppFabric 而不是包含非规范化架构的专用缓存数据库还可以提供对缓存键过期、逐出和调整区域策略进行细粒度控制的优势。如果您使用 SqlServer，则必须自己进行此操作。我也同意 @mperrenoud03 关于负载平衡和高事务率支持的评论。另外，如果您使用 NHibernate 等优秀的 ORM 工具，则可以将其配置为使用 Appfabric（或其他分布式缓存平台）作为二级缓存。我们正在我们的项目中利用这一点并取得了良好的成果。
Using AppFabric rather than a dedicated cache-aside database containing a denormalised schema also provides the benefit of fine grained control over cache key expiry, eviction, and tuned region policies. You would have to roll this yourself if you used SqlServer. I also agree with @mperrenoud03 comments about load balancing and high transaction rate support. Also, if you use a good ORM tool like NHibernate, it can be configured to use Appfabric (or other distributed cache platforms) as a 2nd level cache. We are leveraging this in our project and getting good results.