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

Question

我需要将数据提供给数据处理窗口服务(单向,松散耦合).我想,以确保服务是降等并不会导致"丢失"的数据,即重新启动Windows服务只是导致它拿起工作的地方走了,我需要的系统是很容易解决,这是为什么我没有使用MSMQ.

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

要么

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

从表现(或其他观点)来看,这是更好的解决方案吗？

Answer 1

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

但是,还有其他因素需要考虑.

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

我不知道你的建筑是什么,但不要过早地优化.两种解决方案在性能方面都非常相似,而且可能并不重要 - 所以选择最简单的方法.如果性能确实是一个问题,直接通信(无论是通过IPC还是IP或诸如此类)的性能将提高几个数量级,因此不要浪费时间进行微观优化.