我们一直在构建的应用程序开始凝固，因为大部分功能现已到位。这给了我们一些喘息的空间，我们开始评估我们的持久性模型及其管理。我想你可以说房间里的大象是RavenDB。虽然我们在功能上还没有遇到任何问题，但我们对管理它并不满意。执行查询，截断集合等简单任务对我们来说是具有挑战性的，因为我们通常是基于平台和基于文档的NoSql解决方案的新手。当然我们有能力学习它，但我认为这取决于信心，时间和利用我们现有的Sql Server技能集。例如，我们在几周内通过系统抽取了数百万个事件，成功处理消息被路由到MSMQ中的审计队列。我们还安装了ServiceInsight，它处理了审核队列中的消息，这会占用服务器上的所有磁盘空间。我们不知道如何解决这个问题，并且必须删除我们为RavenDB找到的数据文件。我要说的是，这样做会带来各种令人头疼的问题。
因此，考虑到这一点，我一直负责评估可能利用Sql Server为我们的服务端点的传输和/或持久性提供的可行性和好处。此外，我还可以使用一些指导来配置ServiceControl和ServiceInsight以利用Sql Server。您可能提供的有关配置这些信息以及识别我们应该考虑的任何缺点或架构问题的任何信息将不胜感激。
谢谢Jeffrey
答案 0 :(得分：3)
使用SQL持久性需要非常少的配置（实现细节），但是，当您更改为代理样式体系结构时，使用SQL传输更多地是架构决策，然后是基础架构，这在下降之前需要考虑那条路。
ServiceControl和ServiceInsight持久性：
虽然ServiceControl将MSMQ监视为默认传输，但您可以使用ServiceControl来支持其他传输，例如RabbitMQ，SqlServer，Here you can find the details of how to do that
目前，ServiceControl依赖于RavenDb的持久性，因为ServiceControl依赖于Raven功能，所以无法将其更改为SQL。（AFIK） ServiceControl数据中的数据到期存在未解决的问题，请参阅this issue in github
HTH
答案 1 :(得分：1)
关于RavenDB的ServiceControl使用（这是向ServiceInsight UI提供数据的底层服务）：
正如肖恩·法玛尔（上文）所述，在测试后的版本中，我们将包括消息过期和按需审计消息删除命令，以便您可以完全控制SC的容量利用率。
您还可以更改ServiceControl数据库位置的驱动器/路径，以允许它使用更大的驱动器。
请注意，ServiceControl（以及使用它的ServiceInsight / ServicePulse）用于分析，调试和操作监视。它旨在存储有限数量的审计数据（根据您的吞吐量和容量需求，当计算为消息数量时，这可能会有很大差异，但数据库存储容量可能高达16TB）。
如果您需要长期存储审计数据，您可以挂钩ServiceControl HTTP API并将消息数据传输到各种长期/无限大小/低成本存储解决方案（例如http://aws.amazon.com/glacier）
如果这符合您的需求以及是否还有其他问题，请告知我们
丹尼。