使用数据库序列的策略?

时间:2010-04-14 15:03:10

标签: parallel-processing database

我有一个高端架构,每秒都会收到很多请求(实际上,它每毫秒可以收到很多请求)。该体系结构的设计使得某些控件依赖于分配给每个请求的特定唯一ID。

要创建这样的UID,我们使用DB2 Sequence。现在我已经明白这种方法是有缺陷的,因为使用数据库代价很高,但这样做是有道理的,因为这个值也将用于记录数据库上的信息。

我的团队刚刚发现每笔交易的经过时间增加了近1000%,我们假设因为序列而发生了。现在我想知道,使用序列会序列化对我的应用程序的访问吗?因为他们必须保证增量按照他们应该的方式工作,他们必须,对吗?

那么,使用序列时有更好的策略吗?请假设我没有其他方法可以获得除依赖数据库之外的唯一ID。

2 个答案:

答案 0 :(得分:1)

使用序列必然会序列化您的应用程序。但是,这些东西经过优化可以产生最小的影响。当然,我们总是可以通过以无益的方式宣布事物来解决问题。那么,这个序列是如何定义的?它有一个大的CACHE吗?你有没有指定订单?

说了哪个......

从你的问题中跳出的东西不是粗体的短语,而是它之前的句子:

  

“我的团队刚刚发现了增长   几乎1000%的经过时间   每笔交易,我们都是   假设发生了因为   序列“。

我们都知道ASSUME做了什么(在这种情况下不是,因为我什么也没做)。最近是否有影响此序列的变化?如果没有,为什么你们都认为它导致突然1000%的性能下滑?也许最好收集一些证据,而不是假设(即猜测)。那个时间到了某个地方,你需要发现在哪里。如果您的代码中某处存在竞争条件,或者您正在等待锁等待CPU,或者您的连接速度较慢,这会减慢写入SAN的速度等等,那么调整序列是没有意义的。

您是否已打开任何日志记录或跟踪,或者您可以打开?您是否可以在其他环境中重现这种减速,例如开发或系统测试?这可能是责任的顺序。至少那时你可以对你正在解决真正问题的知识充满信心地重新设计任务。

答案 1 :(得分:0)

获取可能相关的ID的一种可能方法是使用UUID / GUID。虽然我不知道产生这些值有多么苛刻,但它绝对不会受到您担心的序列化问题的困扰。