5

最近几周我一直在使用 asp.net web api 并取得了巨大的成功。它确实帮助我为移动客户端生成了一个界面，以通过 http 进行编程。

我到了需要帮助的地步。

我有一个新的端点，它可以是一个数据库并可以返回 100K 的结果。我正在使用 OData 过滤数据并返回一组分页数据。

由于这可能发生在多个请求中，因此我担心性能。每次从数据库中返回 100K 记录并不理想。所以我有一些想法。

第一个是缓存 100K 结果并让 OData 每次都在这方面发挥作用。我正在使用 AppFabric 分布式缓存作为其负载平衡环境。然而，在 AppFabric 中缓存如此多的数据可能会导致内存复杂化，所以我认为我最好避免这种情况。

下一个选项是忘记 OData 的魔力，将我使用的过滤器发送到数据库，每次只返回所需的数据。所以换句话说，每次都击中数据库。

我可以考虑使用类似本文中概述的版本的缓存处理程序来缓存在 http 缓存中 -> http://byterot.blogspot.ie/2012/06/aspnet-web-api-caching-handler.html缺点其中，如果数据通过可能的另一个系统进行更新，则缓存的数据不会过期。

关于如何处理这种情况、大量数据、使用 odata 和 web api 过滤的任何其他提示？

4

4 回答 4

2

这个问题可能会导致各种各样的答案。也就是说，让我戴上我在 MSFT 之前的帽子，给你我的两分钱。

顾问的回答是“视情况而定”，可以很好地回答很多架构问题。答案取决于您的具体情况。一些开发人员在缓存层方面存在问题，因为还有其他事情需要考虑。符合 ACID 的数据库为您购买了很多保险，即您至少具有非常有限的最终一致性。

如果是我做这个决定，我会考虑以下几点：

  • 我要定期返回多少行？
  • 它们是一遍又一遍的同一行吗？
  • 这在内存中有多大？（100k 的行数实际上并不多；您不希望这 100k 行每次都进入磁盘是对的，但是将它们全部保存在内存中可能不是问题；SQL Server 可能会为您执行此操作。）
  • 我愿意处理什么：最终一致性？我需要其他软件来处理它吗？（人们经常对缓存感到害怕的是确保失效和插入从不同的应用程序/应用程序的不同位置正确且一致地完成。）

鉴于您已经提供的信息（分层架构，愿意尝试分布式缓存），我认为您应该追求缓存层。那里有很多很好的缓存。在我在 Microsoft 工作之前，AppFabric 为我们工作得很好，但我也处理过各种其他缓存层。

于 2012-07-23T13:26:55.540 回答
1

假设您使用实体框架，最好直接返回 EF 的 IQueryable。这样，OData 的魔力将直接作用于您的数据库。$limit 和 $take 将直接映射到您的 SQL 查询。

于 2012-07-22T17:16:29.827 回答
0

我在博客http://byterot.blogspot.ie/2012/06/aspnet-web-api-caching-handler.html中指出的缓存适用于HTTP 缓存，也称为输出缓存。实际上数据本身并没有缓存在服务器上，而是在客户端或中游缓存服务器上，因此不适合您的想法。

于 2012-07-25T17:47:29.387 回答
0

最好的方法是使用您已经在使用的分布式缓存。但是您使用的缓存提供程序，即 AppFabric，有一些限制。限制是指功能限制。查看 NCache，它是一个成熟且功能丰富的第三方分布式缓存提供程序。

如果您想了解 NCache 和 Appfabric 的区别，请查看下面的 youtube 链接，仅供参考....

http://www.youtube.com/watch?v=3CPi1QlskrU

于 2012-07-23T09:10:49.960 回答