2

我正在开发一个项目，它每 100 毫秒从硬件获取一些数据。我正在使用 Visual Studio 2010 和 C#。每轮数据大小约为 50KB。客户希望将所有数据记录在数据库中以用于统计目的。
我更喜欢使用 SQL Server 2005+，因为我对它很熟悉，而且该项目应该在大约 15 天内完成，它是一个小型项目。

  • 将这种数据大小插入数据库的速度是否合理？您是否建议任何通用方法来加速交互？（使用 sql 命令、EF、其他可能对速度产生积极影响的技术）。
  • 如果这对于 SQL Server 来说太快了，那么您建议我应该使用哪个：
    1-具有快速学习曲线。
    2-可以接受统计数据的查询。
    3-可以满足我的速度交互需求。

我正在考虑System.Data.SQLite如果在 SQL Server 上不行。但我不知道学习曲线和速度增强。

4

2 回答 2

4

每秒 500kb 不算什么。我使用每秒处理千兆字节的 Sql 数据库，这完全取决于底层的硬件和服务器配置，但是假设你要在标准的办公室桌面上运行它，你会没事的。即便如此，我会说如果你看到每秒 20Mb 或更高的速度，你就可以开始考虑新硬件了。

你问题的第二部分。由于您使用的是 c#，我建议您使用 SQL 2008，然后使用表值参数 (TVP)，然后在应用程序中、数据集或数据表中缓冲数据，直到您说 10K 行，然后调用 proc进行插入，您所做的就是将数据表作为参数传递给它。这将节省成百上千的临时插入。

希望这很清楚，如果没有，请询​​问我将尝试进一步解释。

于 2011-03-01T21:19:25.280 回答
3

每 100 毫秒 50kB 就是每秒 500kB。如今，网络以千兆位速度（每秒数兆字节）运行，而硬盘驱动器可以处理每秒数百 MB 的速度。500kB 是很小的数据量，所以如果 SQL Server 无法处理它，我会感到非常惊讶。

如果您与服务器的网络连接速度较慢或其他一些问题意味着它难以跟上，那么您可以尝试各种策略来改进事情。想法可能是：

  • 在本地（和/或服务器上）缓冲数据，并使用单独的线程/进程将其写入数据库。如果您不是一天 24 小时连续记录，那么当您完成记录时，速度较慢的服务器会赶上。即使您连续记录，这也会消除任何颠簸（例如，如果您的服务器有一段时间的“忙碌时间”，它正在做很多其他事情以至于它难以跟上来自记录器的数据）

  • 压缩要发送到服务器的数据，以便发送/存储的数据更少。如果数据包相似，您可能会发现您可以获得巨大的压缩比。

  • 如果您不需要每个数据包中的所有内容，请在上传之前从数据中删除任何“无趣”的内容。

  • 可能对数据进行批处理可能会有所帮助 - 通过收集多个数据包并一次发送它们，您可能能够最大限度地减少传输开销。

  • 只需将数据直接存储到磁盘并使用数据库来索引数据。

...因此，我建议您编写一个原型，看看您可以通过网络在您的数据库中存储多少数据，以免它陷入困境。

于 2011-03-01T20:38:35.557 回答