我们有一个用例,我们保留一个单调递增的键来表示客户数据的当前版本。它在系统中用于找出最新版本,并解决第三方调用者在读取数据和处理数据之间存在延迟并且获得多个版本时的冲突。
CUSTOMER_RESOURCE_ID CURRENT_VERSION
132323 1234
如果此资源发生变化,我们会将版本从 1234 增加到 1235(即使我们将其增加到 1300,只要它不下降,也完全没问题)。为此,我们需要首先读取该值,然后更新它。
另一种选择是使用数据库的时间戳并使用始终增加的数据库时间戳不断更新版本。由于这只是一个系统,因此只有当我们更改数据库时才会发生时钟偏差。此外,我们并不非常关心多个线程在一小部分时间内(即时间戳的最小粒度)更新数据的情况,因为我们有另一个锁,每次只有一个线程更新资源。
我想知道我们是否可以使用数据库的系统时间戳来避免仅更新的选择和增量。
这种方法有什么问题吗?我认为这会减少数据库的开销,但我不知道我们在这里节省了多少。
最佳答案
可以讨论许多方法。我认为;
-- 您可以使用增量序列,甚至默认列值来代替数据库时间戳。也许毫秒会给你带来麻烦。
--此外,如果你的表不是很大,并且你的资源足够,你可以添加一个 is_last_version 列,该列将在每次插入时更新,以查询性能中客户的最后版本(即 select * fromcustomers where customer_id = 123 and is_last_version= 1
--以消除订购成本)。这样,您就可以知道哪一行是最后一个版本。但每次插入的时间会比较长。你应该测试一下。
示例:
CUSTOMER_RESOURCE:
CUSTOMER_RESOURCE_ID CURRENT_VERSION_ID IS_LAST_VERSION INSERT_TIME
(default seq) (default sysdate --optionally)
132323 1 1
132324 2 1
132325 3 1
132326 4 0
132327 5 0
132328 6 1
132326 7 0
132329 8 1
132326 9 1
132327 10 1
插入时:
update CUSTOMER_RESOURCE
SET IS_LAST_VERSION = 0
where CUSTOMER_RESOURCE_ID = 132326;
insert into CUSTOMER_RESOURCE(CUSTOMER_RESOURCE_ID,IS_LAST_VERSION) VALUES (132326,1);
COMMIT;
当选择客户的最新版本时:
select * from customers where customer_id = 123 and is_last_version= 1;
关于java - self 管理单调递增关键 OR 系统的时间戳,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/45598898/