使用 AppFabric 缓存进行分页、列出和分组查询

Question

我阅读了很多有关 AppFabric 缓存的文档，但其中大多数都涵盖了简单的场景。 例如将城市列表数据或购物卡数据添加到缓存中。 但我需要将产品目录数据添加到缓存中。

我有 4 个表：

Product（100 万行）、ProductProperty（2500 万行）、Property（100 行）、PropertyOption（300 行）

• 我使用 Product 和 ProductProperty 表的一些过滤器显示分页搜索结果查询。
• 我正在根据搜索结果集创建条件集。例如（4 项新产品、34 项电话、26 项书籍等）
• 我查询产品表的分组，其中包含 IsNew、CategoryId、PriceType 等列。
  还有另一个查询，用于对包含 PropertyId 和 PropertyOptionId 列的 ProductProperty 表进行分组，以获取哪个属性有多少个项目。

因此，为了显示搜索结果，我对搜索结果进行了 1 个查询，对创建条件列表（带有计数）进行了 2 个查询，

搜索结果查询取了 0， 7 秒和 2 次分组查询总共花费了 1.5 秒。 当我运行负载测试时，我达到每秒 7 个请求，%10 被 IIS 丢弃，因为数据库无法给出响应。

这就是为什么我想缓存产品和属性记录。

如果我遵循以下项目（在 AppFabric 中）；

• 创建命名缓存
• 为产品目录数据创建区域（具有 100 万行的表和具有 2500 万行的属性表）
• 用于查询数据和分组的标记项。

我可以使用某些标签进行查询并获取第一页或第二页结果吗？ 我可以查询一些标签并获取一些分组结果的计数吗？ （显示带有计数的过滤器选项） 我必须需要 3 台服务器吗？我可以提供一种只有一台 appfabric 服务器的解决方案吗（当然我知道风险。） 您知道有任何文章或文件解释了这些场景吗？

谢谢。

注意：

一些额外的测试： 我向缓存添加了大约 30,000 个项目，其大小为 900 MB。 当我运行 getObjectsInRegion 方法时，大约需要 2 分钟。 “IList> dataList = this.DataCache.GetObjectsInRegion(region).ToList();” 问题在于转换为 IList。如果我使用 IEnumerable 它的工作速度非常快。但是如何获得分页或分组结果而不将其转换为我的类型？

另一个测试：

我尝试获取 30.000 个产品项的分组计数，并花费 4 秒获得分组结果。例如 GetObjectByTag("IsNew").Count() 等近 50 个类似的查询。

Answer 1

遗憾的是，V1 中没有 AppFabric 的分页 API。任何批量 API（例如 GetObjectsByTag）都将在服务器上执行查询，并将所有匹配的缓存条目流回客户端。从那里您显然可以在 IEnumerable 上使用任何您想要的 LINQ 运算符（例如 Skip/Take/Count），但请注意您总是 从服务器拉回完整的结果集。

我个人希望 AppFabric V2 将通过 IQueryable 而不是 IEnumerable 提供支持，这将能够将完整请求远程发送到服务器，以便它可以在返回客户端之前对结果进行分页，就像 LINQ2SQL 一样或 ADO.NET EF。

目前，一种可能的解决方案是，根据应用程序的功能，您可以在将项目注入缓存时实际计算某种分页。您可以构建代表每个页面的实体键的有序列表，并将它们作为单个条目存储在缓存中，您可以在一个请求中提取这些条目，然后单独（并行）或批量从缓存中获取列表中的项目并将它们连接在一起使用内存中 LINQ 查询。如果您想用 CPU 换取内存，只需缓存完整实体的实际列表而不是 ID，并且必须对实体进行连接。

显然，您必须想出某种键控机制来根据传入的搜索条件快速从缓存中提取这些对象列表。像这样的某种键控可能会起作用：

private static string BuildPageListCacheKey(string entityTypeName, int pageSize, int pageNumber, string sortByPropertyName, string sortDirection)
{
   return string.Format("PageList<{0}>[pageSize={1};pageNumber={2};sortedBy={3};sortDirection={4}]", entityTypeName, pageSize, pageNumber, sortByPropertyName, sortDirection);
}

您可能需要考虑使用单独的进程或工作线程来执行此类操作，以保持缓存最新，而不是按需执行并在缓存条目不存在时强制用户等待尚未填充。

这种方法最终是否适合您取决于您​​的应用程序和数据的几个因素。如果它不完全适合您的场景，也许它至少会帮助您转变思维，以不同的方式思考解决问题。