APPFabric缓存或SQL Server-特定方案 [英] APPFabric Caching or SQL server - Specific scenario

问题描述

我很难确定是否应根据我们的需要使用APPFabric缓存或SQL Server（考虑到我们目前大多数情况下都使用SQL Server的事实）。

I am having difficulties figuring out if APPFabric caching or SQL Server should be used in the context of our needs (considering the fact that we are currently using SQL server for most things).

我们只需要（暂时）缓存小块数据（〜16KB），每个小块数据对应于与从一个应用服务器之一发送的特定请求（传出请求）相关的信息。

We only need (for now) to cache small chunks of data (~16KB) each of them corresponding to the information associated to a particular request that was sent from one of the applicative server (outgoing request).

任何应用服务器都可以接收与初始外发请求相关联的外来请求，并且出于我们的需要，我们需要查找与该外发请求相关联的原始信息。这就是为什么我们不能在每个应用服务器中的内存缓存中保留本地的原因，因为我们无法确定传入请求将到达发送出请求的应用服务器上。

Any of the applicative server can receive incoming request associated to the initial outgoing request, and for our needs we need to find back the original information associated with this outgoing request ... that's why we can't keep a local in memory cache in each applicative server, because we can't be sure the incoming request will arrive on the applicative server from which the outgoing request was sent.

但是，我们基本上只需要保存一次〜16kb的信息一次（非常罕见的更新可能性），并且能够从任何应用服务器上访问它，但是只能访问一次在绝大多数情况下。
因此，基本上在大多数情况下，它将是一次从应用服务器进行写入（缓存），然后是从同一服务器或另一台应用服务器进行读取。

HOWEVER we just basically need to persist the ~16kb piece of information only once (very rare possibilities of updates), and to be able to access it back from any applicative server, but to access it only one time in the vast majority of cases. So basically most of the time it will be one write from an applicative server (caching) and later on, one read from same or another applicative server.

在这种特定情况下，通过AppFabric缓存群集而不是直接访问数据库是否会有任何收益（考虑到这将是一个简单的insert / select语句）？

In this specific context, will there be any gain of going through an AppFabric cache cluster instead of directly going to the database (considering it will be a simple insert/select statement) ?

请牢记可伸缩性，这意味着我们目前对put_data / get_data操作的吞吐量不高（〜160ops / sec），但可能会达到1K / s ..每秒10k甚至更多。

Keeping in mind scalability, meaning that we currently do not have a high throughput of put_data / get_data operations (~160ops/sec) but we may reach 1K/s .. 10k/s and maybe more in the near future.

预先感谢您的回答。

推荐答案

AppFabric缓存与SQL的比较DB将是访问时间。由于AppFabric将所有内容存储在内存（RAM）中，而SQL需要从磁盘查询其数据，因此您将具有更快的访问时间。

The gain of AppFabric Cache versus SQL DB would be access time. You will have quicker access time for AppFabric since it stores everything in memory (RAM) whereas SQL needs to query its data from disk.

AppFabric缓存的缺点是，除非您在集群中实现了HA（高可用性），否则会丢失数据，以免系统出现故障时丢失数据。 SQL DB在这里胜出是因为它在数据库系统发生故障时支持数据可恢复性（通过备份日志-LDF ）。

The downside of the AppFabric Cache is that you can lose the data unless you've implemented HA (high-availability) in your cluster to avoid data loss when systems fails. The SQL DB wins here because it supports data recoverability (via backup logs - LDFs) should the database system fail.

如果您需要保证消息交付，您可能不应该使用AppFabric缓存集群，而应使用SQL DB来实现临时持久性，因为它具有强大的数据恢复支持。

If you need guaranteed message delivery, you probably shouldn't use the AppFabric Cache cluster, but a SQL DB for temporary persistence due to its robust data recovery support.

这篇关于APPFabric缓存或SQL Server-特定方案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！