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