【问题标题】:ASP.NET OLTP App - creating new version of recordsASP.NET OLTP App - 创建新版本的记录
【发布时间】:2012-04-05 19:00:00
【问题描述】:

我的问题与this question 相同 - 但需要补充一点。我的问题是我的网络应用程序的用户被允许创建记录的新版本。记录的每个新版本都会在 50 个其他相关表中创建相应的“新版本”,以记录对该特定版本的单独更改。这种包含大约 50 个表的新版本的创建在事务中运行(以在发生错误时回滚所有更改)。很多时候,这个过程很慢,这是可以理解的,因为“冗长的事务”涉及太多的表“插入”。

我正在寻找更好的解决方案/设计来实现这样的场景。

  1. 是否有更好的方法来维护同一记录的“版本”,尤其是当它在多个表中创建太多重复项时
  2. 我不认为设计本身是好的,因为“每一行版本”插入了太多记录,但至少想解决眼前的问题,即“冗长的事务”——这有时会导致延迟。可能没有出路,但仍然想问 - 如果我不将“版本控制”放在事务中,是否有更好的方法在发生错误时回滚(因为事务似乎阻止了其他 OLTP查询 - 由于在所有主表上插入新版本)

版本控制查询现在运行大约 10 秒,但有时会变得更糟。任何想法表示赞赏

【问题讨论】:

    标签: asp.net sql-server database-design rowversion oltp


    【解决方案1】:

    是否必须实时返回“创建”或“失败”消息?以下内容对于您的解决方案也可能是矫枉过正,但它确实创建了一个可扩展的解决方案。

    网络服务器可以发布一条消息(到某种队列)请求该操作。此时,用户可以继续使用该站点来做其他事情。后台的 Windows 服务可以处理消息(与网站无关),然后通知用户(通过网站内的消息,类似于堆栈溢出通知)或通过电子邮件通知任务已运行或失败。

    如果您可以近乎实时地进行解耦处理,那么您可以修改您的 Windows 服务以进行扩展。你可以有一个线程池来管理请求——所以也许你在任何时候只有 5 个线程运行来限制负载。如果您遇到更多性能问题,您可以横向扩展并开发一个可以拥有 2 个或更多队列处理器的系统(这确实会增加它自己的问题/复杂性)。

    【讨论】:

    • 谢谢保罗。但我的问题是——一般用例行为是这样的,一旦允许用户创建记录的“新版本”,他就会去更新与该特定版本相关的信息。因此,新版本应该存在于所有这些相关表中,以供用户更新信息。它必须实时发生。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-05-17
    • 2014-09-23
    相关资源
    最近更新 更多