用于频繁数据处理的速度文件系统与数据库

Question

我需要将数据提供给数据处理窗口服务（单向，松散耦合）。我想确保服务正在停止等不会导致“丢失”数据，重新启动Windows服务只会让它在离开的地方工作，我需要系统非常容易进行故障排除，这就是我没有使用MSMQ的原因。

所以我提出了两个解决方案之一 - 或者：

• 我将带有处理数据的文本文件放入放置目录，然后Windows服务等待文件更改通知，处理并删除文件

或

• 我在本地MS SQL数据库的特殊表中插入数据，并且windows服务轮询数据库以获取更改/新项目，然后在处理它们时将其删除

MSSQL数据库是系统上的本地，而不是通过网络，但稍后我可能想将其移动到其他服务器。

从表现（或其他观点）来看，这是更好的解决方案吗？

Answer 1

从性能角度来看，文件系统很可能是最快的 - 也许是大幅度的。

但是，还有其他因素需要考虑。

• 通常，只要它是否足够快，它的速度并不重要。存储和检索小blob是一项简单的任务，很可能这永远不会成为你的瓶颈。
• NTFS是记录的 - 但只有元数据。如果服务器在写入中间崩溃，则文件可能包含乱码。如果使用文件系统后端，则需要对文件中的任意数据进行强健。根据缓存层和文件系统重用旧空间的方式，该乱码可能包含其他消息的片段，因此即使对于重复的旧消息，您也最好是健壮的。
• 如果您想要添加涉及更丰富的消息模型的新功能，则可以更轻松地扩展数据库（例如，某种缓存层）。
• 文件系统更“开放” - 意味着使用非常简单的工具（记事本）调试可能更容易，而且您可能会遇到更棘手的问题，包括本地索引服务，病毒扫描程序，设置不当或其他任何问题碰巧住在系统上。
• 大多数API无法处理路径超过260个字符的文件，并且在面对大量文件时性能不佳。如果您的存储目录变得太大，.GetFiles()之类的东西会变慢 - 而DB可以在时间戳上编入索引，并且无论旧的混乱如何都会检索最新的消息。你可以解决这个问题，但这是一个额外的障碍。
• MS SQL不是免费的和/或未安装在每个系统上。每个新服务器需要额外的系统管理，并且在使用时需要更多补丁。特别是如果您的软件应该由第三方轻松安装，则文件系统具有优势。

我不知道您的建筑物是什么，但 不会过早优化 。这两种解决方案在性能方面非常相似，而且可能并不重要 - 因此选择最适合您的方案。如果性能确实是一个问题，直接通信（无论是通过IPC还是IP或诸如此类）的性能将提高几个数量级，因此不要浪费时间进行微观优化。

Answer 2

我对2005年及以下的经验是，数据库的速度要慢得多 特别是对于较大的文件..在进行表扫描时，这真的会弄乱SQL服务器内存
然而
新的 SQL server 2008 在引擎中具有更好的文件支持。