是否有快速且可扩展的解决方案来保存数据？答案

【问题标题】：Is there a fast and scalable solution to save data?是否有快速且可扩展的解决方案来保存数据？
【发布时间】：2010-11-17 02:36:59
【问题描述】：

我正在开发一项需要在 Windows 平台上进行扩展的服务。

最初它将每秒接收大约 50 个连接（每个连接将发送大约 5kb 数据），但它需要可扩展以接收超过 500 个未来。

将接收到的数据保存到 Microsoft SQL Server 等通用数据库是不切实际的（我猜）。

还有另一种保存数据的解决方案吗？考虑到它每天将收到超过 600 万条“记录”。

有5个步骤：

通过http处理程序（c#）接收数据；
保存接收到的数据；
请求处理保存的数据；
处理请求的数据；
保存处理后的数据。

我的预解决方案是：

通过http处理程序（c#）接收数据；
将接收到的数据保存到Message Queue；
MSQ 请求使用 Windows 服务处理保存的数据；
处理请求的数据；
将处理后的数据保存到 Microsoft SQL Server（这是瓶颈）；

【问题讨论】：

为什么你认为这是不切实际的？您是否尝试过模拟它并检查在给定硬件配置中可能达到的限制？
能否指定您使用的 Sql Server 版本。如果它是 Express 版本之一，那么您将永远无法处理这种流量......另外，您应该查看您的表索引以查看是否导致减速。我基本上是在说：不要这么快就逃离数据库服务器解决方案。它应该真的能够处理你所描述的那种音量。（当然是在足够强大的硬件上运行。）
600 万条记录不一定那么多。记录有多大？我想我会默认使用 SQL DB，然后当且仅当它确实是瓶颈时，请查看 Amazon 的 SimpleDB 之类的东西。只需使用一种数据存储库模式，以后可以轻松将其换出...

标签： c# asp.net scalability

【解决方案1】：

为什么不这样做：

1.) 接收数据
2.) 过程数据
3.) 一次性保存原始数据和处理后的数据

如果您已经拥有它，这将省去您再次请求它的麻烦。我会更担心您的表结构和数据库机器，而不是实际流程。我一定要确保您的插入物尽可能便宜。如果这是不可能的，那么排队工作是有道理的。我自己不会使用消息队列。假设您有一台体面的 SQL Server 机器，假设您没有在每条记录中写入大量数据，那么每天 600 万条记录应该没问题。

【讨论】：

【解决方案2】：

我认为您过早地进行了优化。如果你需要把所有东西都发送到数据库中，那么在假设数据库是瓶颈之前，看看数据库是否可以处理它。

如果数据库无法处理它，那么可能会转向 Jon Skeet 所描述的基于磁盘的队列。

【讨论】：

【解决方案3】：

每天 600 万条记录听起来并不是特别庞大。特别是，不是每天 24 小时每秒 500 次 - 您是否认为流量会“突发”？

我不会个人使用消息队列 - 我之前一直被不稳定和一般困难所困扰。我可能只是直接写入磁盘。在内存中，使用具有单个线程写入磁盘的生产者/消费者队列。生产者只会转储要写入队列的记录。

有一个单独的批处理任务，它将一次将一堆记录插入数据库。

一次对最佳（或至少“好”数量的记录进行批量上传）进行基准测试。您可能希望有一个线程从磁盘读取，一个单独的线程写入数据库（如果数据库线程有大量积压，则文件线程阻塞），这样您就不必同时等待文件访问和数据库同一时间。

我建议您尽早做好一些测试，看看数据库可以处理什么（并让您测试各种不同的配置）。找出瓶颈在哪里，以及它们会对您造成多大的伤害。

【讨论】：