当你的交易变得更加的比受益的负担?

问题描述 投票:2回答:5

事务编程,在这个时代,在现代发展的主食。并发性和容错是一个应用程序长寿,这是正确的,事务逻辑变得容易实现的关键。随着应用的发展,虽然,它似乎事务代码往往变得越来越繁重的应用程序的可扩展性,而当你进入桥分布式事务和镜像数据集的问题开始变得非常复杂。我很好奇,似乎是一点,在数据大小或应用程序的复杂性,即交易频繁启动成为问题(导致超时,死锁,在关键任务的代码的性能问题等),这是更麻烦的修复源,排查或解决方法比设计一个数据模型,更容错本身,或使用其他手段来保证数据的完整性。此外,什么设计模式,可以最大限度地减少这些影响或使标准的事务逻辑过时或一个非问题?

--

编辑:我们已经有了一个合理的质量了一些答案,到目前为止,但我想我会后回答自己带来了一些我听说过,试图激发一些额外的创造性的东西;大多数我得到的答复是问题的悲观看法。

另外要注意的是,并不是所有的死锁是编码不佳程序的结果;有时也有依赖​​于类似的资源以不同的顺序关键任务操作或复杂的在对方的那一步不同的连接的查询;这是一个问题,有时似乎是不可避免的,但我一直返工工作流程,以方便这是不太可能导致一个的执行顺序的一部分。

sql performance design-patterns transactions
5个回答
2
投票

我想,没有设计模式本身就可以解决这个问题。良好的数据库设计,良好的存储过程的编程,特别是学习如何保持你的交易短期将缓解大部分的问题。有没有问题,但没有100%的保证方法。

在基本上每个情况下,我已经看到了我的职业生涯,虽然,死锁和怠工被固定的存储过程来解决:

  • 确保所有访问表为了防止死锁
  • 固定索引和统计信息使一切更快(因此减少死锁的机会)
  • 有时有交易的没有真正的需要,它只是“看起来”像它
  • 有时交易可以通过在单个语句的人多语句存储过程中被淘汰。

2
投票

共享资源的使用是错误的,从长远来看。由于通过重用现有的环境中,你正在创造越来越多的机会。只是审查忙海狸:)二郎不言而喻的方式是产生容错和容易核查系统的正确途径。

但是,事务内存是广泛使用的许多应用是必不可少的。如果您咨询银行与其数百万用户,例如,你不能只是复制数据,以提高效率的目的。

我认为单子是一个很酷的概念,以处理不断变化的状态的难以理解的概念。


0
投票

一种方法我听说的是让一个版本的插入只有在没有更新过发生模型。在选择版本仅用于选择最新行。一个缺点我用这种方法知道的是,数据库可以得到相当大的速度非常快。

我也知道一些解决方案,如FogBugz的,不强制使用外键,我相信也将有助于缓解这些问题,因为SQL查询计划可以选择或更新,即使没有数据改变过程中锁定链接表他们,如果它是被锁定它可以增加死锁或超时的可能性高争表。

我不知道很多关于这些方法虽然,因为我从来没有使用过,所以我想有优点和缺点,每一个我不知道的,还有我从来没有听说过其他的一些技术。

我也一直在寻找到一些从卡罗Pescio的recent post,我已经没有足够的时间来不幸的是这样做正义的材料,但材料似乎很有趣。


0
投票

如果你在谈论“云计算”在这里,答案将是每个事务本地化它发生在云的地方。

没有必要对整个云计算是一致的,因为这将杀死性能(如你注意到)。简单地说,跟踪哪些改变,并且在那里和处理多个小额交易为改变通过系统传播。

其中,在云的另一端用户A的更新记录R和用户B没有看到它(还)的情况是一样的,当一个用户A没有做改变但在当前严格的事务性环境。这可能导致在更新重系统中的差异,因此系统应architectured的更新尽可能少的工作 - 搬东西到数据的聚集和拉出聚集一次确切的数字是至关重要的(即一致性移动要求从写时间关键的读出时间)。

好了,只是我的POV。这是很难想象一个系统,是应用在这种情况下不可知。


0
投票

尽量使在可能的指令数最少的数据库级别的变化。

总的原则是锁定资源的可能,以免时间。使用T-SQL,PLSQL,Java的Oracle产品或任何类似的方法可以减少每个事务锁住共享资源的时间。在数据库中,我实际上交易与行级锁,多版本,以及其他各种智能技术进行了优化。如果你可以在数据库中进行交易,你救了网络延迟。除了像ODBC / JDBC / OLEBD其他层。

有时程序员尝试获取数据库的好东西(这是事务性的,并行的,分布式的),但保持数据的缓存。然后,他们需要手动添加一些数据库功能。

© www.soinside.com 2019 - 2024. All rights reserved.