处理非常大的数据集并及时加载

Posted 2023-03-11

【中文标题】处理非常大的数据集并及时加载

【英文标题】：Dealing with very large datasets & just in time loading

【发布时间】：2011-06-15 23:25:53

【问题描述】：

我有一个用 C# (.NET 4.0) 编写的 .NET 应用程序。在这个应用程序中，我们必须从文件中读取一个大型数据集并以网格状结构显示内容。因此，为了实现这一点，我在表单上放置了一个 DataGridView。它有 3 列，所有列数据都来自文件。最初，该文件有大约 600.000 条记录，对应于 DataGridView 中的 600.000 行。

我很快发现，DataGridView 在如此大的数据集下崩溃，所以我不得不切换到虚拟模式。为此，我首先将文件完全读入 3 个不同的数组（对应于 3 列），然后触发 CellValueNeeded 事件，我从数组中提供正确的值。

但是，正如我们很快发现的那样，此文件中可能有大量（大量！）记录。当记录大小非常大时，将所有数据读入数组或 List 等似乎是不可行的。我们很快就会遇到内存分配错误。 （内存不足异常）。

我们被困在那里，但后来意识到，为什么要先将数据全部读入数组，为什么不在 CellValueNeeded 事件触发时按需读取文件？所以这就是我们现在要做的：我们打开文件，但不读取任何内容，当 CellValueNeeded 事件触发时，我们首先将 Seek() 到文件中的正确位置，然后读取相应的数据。

这是我们能想到的最好的方法，但是，首先这非常慢，这使得应用程序运行缓慢并且对用户不友好。其次，我们不禁认为必须有更好的方法来实现这一点。例如，一些二进制编辑器（如 HXD）对于任何文件大小都非常快，所以我想知道如何实现这一点。

哦，为了增加我们的问题，在 DataGridView 的虚拟模式下，当我们将 RowCount 设置为文件中可用的行数（比如 16.000.000）时，DataGridView 甚至需要一段时间才能初始化本身。对于这个“问题”的任何 cmets 也将不胜感激。

谢谢

【参考方案1】：

如果您无法将整个数据集放入内存中，那么您需要一个缓冲方案。您的应用程序不应仅读取填充DataGridView 以响应CellValueNeeded 所需的数据量，而应预测用户的操作并提前读取。因此，例如，当程序第一次启动时，它应该读取前 10,000 条记录（或者可能只有 1,000 条或可能 100,000 条——在您的情况下是合理的）。然后，CellValueNeeded 请求可以立即从内存中填充。

当用户在网格中移动时，您的程序尽可能领先用户一步。如果用户跳到你前面（比如说，想从前面跳到最后），可能会有短暂的停顿，而你必须走出磁盘才能完成请求。

这种缓冲通常最好由一个单独的线程来完成，尽管同步有时可能会成为一个问题，如果线程在预期用户的下一个动作时提前读取，然后用户做了一些完全出乎意料的事情，比如跳到开头列表。

1600 万条记录实际上并不能保留在内存中的所有记录，除非记录非常大。或者，如果您的服务器上没有太多内存。当然，1600 万远不及 List<T> 的最大大小，除非 T 是一个值类型（结构）。你这里说的是多少 GB 的数据？

【讨论】：

您好 Jim，T，是一个具有 4 个双精度浮点数的结构。所以，4*8*16M = 512MB 的数据。

我尝试使用 .NET MemoryMappedFile，但是一旦您创建视图，它显然会尝试将文件加载到内存中，因为我遇到了内存不足异常。我想也许 MemoryMappedFile 会在内部对页面的数据访问进行分段，并且只将所需的页面加载到内存中。

@SomethingBetter：如果您使用的是 32 位机器，我想 512 MB 是个问题。如果您使用内存映射文件，您需要使文件的视图小于整个文件的大小。然后在用户浏览数据时调整视图。

【参考方案2】：

嗯，这是一个看起来效果更好的解决方案：

第 0 步：将 dataGridView.RowCount 设置为较低的值，例如 25（或适合您的表单/屏幕的实际数字）

第 1 步：禁用 dataGridView 的滚动条。

第 2 步：添加您自己的滚动条。

第 3 步：在您的 CellValueNeeded 例程中，响应 e.RowIndex+scrollBar.Value

第 4 步：关于数据存储，我目前打开了一个 Stream，在 CellValueNeeded 例程中，首先执行 Seek() 和 Read() 所需的数据。

通过这些步骤，对于非常大的文件（测试高达 0.8GB），我在 dataGrid 中滚动获得了非常合理的性能。

因此，总而言之，减速的实际原因似乎不是我们一直在 Seek()ing 和 Read()ing 的事实，而是实际的 dataGridView 本身。

【讨论】：

确实如此。在 TextBox 中显示相同的数据集（借助 od StringBuilder(5000000) ;)) 大约快 4 倍。

【参考方案3】：

管理可汇总、小计、用于多列计算等的行和列提出了一系列独特的挑战；将问题与编辑遇到的问题进行比较并不公平。自 VB6 以来，第三方数据网格控件一直在解决在客户端显示和操作大型数据集的问题。使用按需加载或自包含的客户端 garguantuan 数据集来获得真正快速的性能并非易事。按需加载可能会受到服务器端延迟的影响；在客户端上操作整个数据集可能会受到内存和 CPU 限制的影响。一些支持即时加载的第三方控件同时提供客户端和服务器端逻辑，而另一些则尝试 100% 解决客户端问题。

【参考方案4】：

因为 .net 是在本机操作系统之上分层的，所以运行时加载和管理从磁盘到内存的数据需要另一种方法。 了解原因和方法：http://www.codeproject.com/Articles/38069/Memory-Management-in-NET

【参考方案5】：

为了解决这个问题，我建议不要一次加载所有数据。而是以块的形式加载数据并在需要时显示最相关的数据。我刚刚做了一个快速测试，发现设置DataGridView 的DataSource 属性是一个好方法，但是对于大量的行，它也需要时间。因此，使用 DataTable 的Merge 函数分块加载数据并向用户显示最相关的数据。 Here 我已经演示了一个可以帮助你的例子。