我有一个基于某些文件进行大量处理的软件。我必须在此过程中查询 SQL Server 中的一些表，这会扼杀数据库和应用程序性能。（其他应用程序使用相同的表）。
优化查询和代码后，得到更好的结果但还不够。经过研究，我找到了解决方案：缓存一些查询结果。我的想法是缓存正在处理的文件需要的一个特定表（标识为开销）行。
我想在使用 AppCache Fabric 时（我在 MS 堆栈上），做了一些测试，它对小对象有很大的内存使用（appcache 服务在没有对象的情况下使用了大约 350MB 的内存）。但我需要在这些结果表中进行一些查询（比如搜索lastname、ssn、birthdate等）
我的第二个选择是 MongoDb 作为缓存存储。我对此进行了研究，我读过的大多数人都建议使用 memcached 或 Redis，但我使用的是 Windows 服务器，并且它们不受官方支持。
在这种情况下使用 mongo 作为缓存存储是一个好方法吗？还是 AppFabric 缓存 + 标签搜索更好？
很难说什么更好，因为我们对您的瓶颈了解不够。很大程度上取决于您正在讨论的数据的质量。如果数据是非常静态的并且不是经常调用但编译数据集很耗时，那么好的解决方案可能是使用物化视图。如果经常调用此数据，则最好将其缓存在某些服务器（例如应用程序结构）上。有许多技术和可能性。但是您确实需要考虑网络流量、需求、大小等。如果不了解所有细节，很难在这里回答这个问题。看起来您走在正确的道路上，但您可能只需要一个参数化查询。很难说。但我会将物化视图添加到您刚刚发布的名册中。
我的问题是，您对申请的长期目标或估计是什么？如果这是您将要经历的最高负载，那么调整数据库或使用 MVL 将是一个答案。但解决这个问题的长期解决方案是分布式缓存，您已经在沿着这些思路进行思考。您的数据需求就是我们所说的“参考数据”或“查找数据”，一旦您使用有限的数据库资源执行多次查找，就会出现性能问题，您的数据库将成为性能瓶颈。
因此，您已经在考虑的解决方案是将这些“参考”数据缓存在缓存中，而无需转到数据库，同时保持缓存与数据库同步。
Appfabric 我不太确定，因为它会遇到您提到的相同支持问题。你的预算是多少？你能考虑花在像NCache 这样的缓存解决方案上吗？