0

我们一直在构建的应用程序开始固化，因为现在大部分功能都已到位。这给了我们一些喘息的空间，我们开始评估我们的持久性模型及其管理。我想你可以说房间里的大象是 RavenDB。虽然我们在功能上还没有遇到任何问题，但我们对管理它并不满意。执行查询、截断集合等简单任务对我们来说是具有挑战性的，因为我们通常是基于平台和基于文档的 NoSql 解决方案的新手。我们当然有能力学习它，但我认为这归结为信心、时间和利用我们现有的 Sql Server 技能集。例如，在几周的时间里，我们通过系统泵送了数百万个事件，成功处理的消息被路由到我们在 MSMQ 中的审核队列。我们还安装了 ServiceInsight，它会处理审核队列中的消息，这会占用服务器上的所有磁盘空间。我们不知道如何解决这个问题，不得不删除我们为 RavenDB 找到的数据文件。我只想说，这样做会引起各种头痛。

因此，考虑到这一点，我负责评估潜在地将 Sql Server 用于我们的服务端点的传输和/或持久性的可行性和好处。此外，我还可以使用一些指导来配置 ServiceControl 和 ServiceInsight 以利用 Sql Server。您可能能够提供的有关配置这些和识别我们应该考虑的任何缺点或架构问题的任何信息将不胜感激。

谢谢你，杰弗里

4

2 回答 2

3

使用 SQL 持久性只需要很少的配置（实现细节），但是，使用 SQL 传输更多的是一种架构决策，而不是一种基础架构决策，因为您正在更改为代理风格的架构，这在您沿着这条路线之前需要考虑。

ServiceControl 和 ServiceInsight 持久性：

虽然 ServiceControl 将 MSMQ 监控为默认传输，但您也可以使用 ServiceControl 支持其他传输，例如 RabbitMQ、SqlServer，您可以在此处找到有关如何执行此操作的详细信息

目前 ServiceControl 依赖于 RavenDb 的持久性，并且无法将其更改为 SQL，因为 ServiceControl 依赖于 Raven 功能。（AFIK）ServiceControl 的数据中的过期数据存在一个未解决的问题，请参阅github 中的此问题

高温高压

于 2014-01-17T18:12:14.243 回答
1

关于 RavenDB 的 ServiceControl 使用（这是为 ServiceInsight UI 提供数据的底层服务）：

正如 Sean Farmar（上文）所提到的，在后 beta 版本中，我们将包括消息过期和按需审核的消息删除命令，以便您可以完全控制 SC 的容量利用率。

您还可以更改 ServiceControl 数据库位置的驱动器/路径，以允许它使用更大的驱动器。

请注意，ServiceControl（以及使用它的 ServiceInsight / ServicePulse）旨在用于分析、调试和操作监控。它旨在存储有限数量的审计数据（根据您的吞吐量和容量需求，这在计入消息数量时可能会有很大差异，但数据库存储容量最高可达 16TB）。

如果您需要长期存储审计数据，您可以连接到 ServiceControl HTTP API 并将消息数据传输到各种长期/无限大小/低成本存储解决方案（例如http://aws.amazon.com /冰川）。

请让我们知道这是否满足您的需求以及您是否还有其他问题

丹尼。

于 2014-01-18T17:59:02.630 回答