数据缓存技术 / 技巧 / AppFabric答案

【问题标题】：Data caching techniques / Tips / AppFabric数据缓存技术 / 技巧 / AppFabric
【发布时间】：2010-08-10 01:03:45
【问题描述】：

我们在一个 SQL 表中有数百万条记录，我们对这些数据运行非常复杂的分析以生成报告。

随着表格的增长和更多记录的添加，计算时间越来越长，用户必须等待很长时间才能加载网页。

我们曾考虑使用 AppFabric 之类的分布式缓存在应用程序加载时将数据加载到内存中，然后根据内存中的数据运行我们的报告。这应该会稍微缩短响应时间，因为现在数据在内存中而不是在磁盘中。

在我们采取行动并实施之前，我想检查并了解其他人在做什么，以及将数据加载到内存、缓存等方面的一些最佳技术和实践是什么。当然，您不只是加载整个内存中有上亿条记录的表...??

我也在研究 OLAP / 数据仓库，这可能会给我们带来比缓存更好的性能。

【问题讨论】：

【解决方案1】：

复杂报告的解决方案是预先计算，因此如果您正在研究 OLAP，那么您就走在了正确的道路上。

【讨论】：

【解决方案2】：

您是否考虑过对数据库进行分区？我们为我们最大的数据库执行此操作。

话虽如此，正确使用应用结构缓存将大大提高大多数 IO 繁重的应用程序的性能。

【讨论】：

【解决方案3】：

我们在一个 SQL 表中有数百万条记录，

糟糕的政策。平面文件更好。

我们对这些数据进行非常复杂的分析以生成报告。

在某些情况下，您会更乐意将相关子集加载到 SQL 中。

随着表的增长和更多记录的添加，计算时间也在增加

这就是过度使用数据库的后果。少用一点。

我们正在考虑使用像 AppFabric 这样的分布式缓存...

也许吧。然而，平面文件比 RDBMS 更快且更具可扩展性。

也在研究 OLAP/数据仓库

好计划。立即购买 Kimball 的书。你不需要更多的技术。您只需要更好地利用平面文件作为主要文件，并将 SQL 作为用户临时查询（针对子集）的地方。

【讨论】：

我觉得“政策不好。平面文件更好。”有点笼统的说法。你能详细说明一下吗？在 RDBMS 表中看到 1 亿行并让它表现良好是很常见的：索引、分区、索引视图浮现在脑海中......
@Mitch Wheat。平面文件比任何 RDBMS 都更简单（因此更快）。如果数据只是简单地累积然后分析，那么这就是平面文件的最佳选择。请购买 Kimball 的书。 DW 最简单的方法是使用用于批量查询的平面文件和用于临时查询的 SQL。
@S.Lott：你能告诉我 Kimball 在哪里声明平面文件总是更快。谢谢。
@Mitch Wheat：Kimball 建议“维度总线”应该是平面文件。对于琐碎的追加和检索操作，平面文件比 RDBMS 更快，因为它们更简单。与 RDBMS 插入/选择相比，对文件系统的读写进行一些测量。 RDBMS == 文件系统 + 锁定开销。
平面文件在切片和切块时绝对不更好。例如当您的查询只需要聚合行的一个子集时。随着所需的不同切片数量的增加，平面文件的吸引力下降。此外，他们缺乏良好的工具来确保数据的一致性、可用性等。