表的最后修改时间UPDATE_TIME的设计

最新推荐文章于 2024-07-03 19:20:56 发布

转载最新推荐文章于 2024-07-03 19:20:56 发布 · 1.3k 阅读

文章标签：

本文探讨了UPDATE_TIME字段在不同场景下的设计和使用，包括数据复制环境中的REP_TIME、客户修改时间与后台运营的CHECK_TIME、批量修改的BATCH_TIME、业务相关的DATA_UPDATE_TIME、数据删除的DELETE_TIME以及数据同步的SYNC_TIME。每种时间戳都有其特定的业务意义和优化考虑。

每个表的update_time，一般代表的是这条数据本身的修改时间。但是update_time其实在很多场景下有特殊的用法，在这里结合多年的业务和经验，介绍几种常见的关于UPDATE_TIME的设计。

（1）数据在复制环境中的时间：REP_TIME

在现在的互联网产品中，往往不止一个数据库。某个数据库会在多个机房有备份，或者同一个机房有多个备份。实现这种主从复制的技术有很多，有些技术往往需要解决复制环境中数据冲突的问题。此时数据变动的时间就是解决冲突的常见手法。这个数据变动的时间，和业务无关，只要数据实际情况发生了一次UPDATE修改，那么这个时间就需要变动。无论这个修改是有实际意义的，还是说某个开发就是做了一次无效的UPDATE操作。

在ORACLE数据库中，这个字段一般使用TIMESTAMP类型，保证这个修改时间是通过触发器来实现的，也就是只要发生UPDATE修改，这个时间会通过触发器修改，无需程序管理。

所以，在复制环境中，参与复制所有的表都需要有这个REP_TIME的字段，以及维护这个字段的触发器。虽然这个字段可以代表数据的修改时间，但是通常这个字段和业务的紧密度不相关，仅仅表现的数据修改本身的时间。

（2）网站客户的修改时间 UPDATE_TIME 和后台运营的修改时间 CHECK_TIME

这是一个比较常见的设计。对于网站会员来说（尤其是收费会员），当他可以看到自己数据的修改时间的时候，他自然会想到在这个时间他是否修改过数据。如果他发现在这个时间没有修改过这个数据，自然就会产生疑惑。

其实一条数据，除了客户本身修改，网站对数据的操作，也会导致数据的修改，这个时间是否对客户开放，决定了网站运营修改数据和网站客户修改数据是否公用一个修改时间UPDATE_TIME。

在很多网站中，一般的处理方法是：后台运营修改数据的时间和客户本身修改的时间是分开的，运营人员的修改时间可以放入CHECK_TIME字段中，客户修改时间放入UPDATE_TIME字段中，两边的数据并不共享。

（3）批量修改时间的场景 : batch_update_time

在某些情况下，为了满足特殊需求，网站可能会提供一种批量修改功能，要求用户每天可以刷新他们的数据。举例来说，某个网站就提供过一个商户的重发的功能, 让客户每天批量刷新商品。这个功能除了最后更新时间，其他字段都不修改。这种修改量非常巨大，按照我曾经遇到的实际情况看，大几百万的数据，每天通过resubmit修改的数据可能达到一般，但是实际修改的数据只有10w左右。

如果把这个批量修改的时间放在UPDATE_TIME上，其实影响还是比较大的。试想一下，如果想找出1小时更新的数据做索引更新，可能实际数据只有1w条数据，但是如果考虑批量时间，就可能有大几十万，这种成本是非常高的，无论是在数据库还是业务方，都是一种非常大的浪费。

数据的BATCH_TIME的产生就是为了满足这种业务场景，根据实际业务考虑设计，如果存在大量的批量修改，那么为了应用和数据库考虑，这个时间都是应该单独存放的。

（4）数据业务的修改时间：DATA_UPDATE_TIME

从（2）中，我们往往会发现一个问题，如果我们希望得到某一个时间段的修改数据，往往不能通过一个字段获取。我们需要对UPDATE_TIME和CHECK_TIME两个时间段的合并集合并，获取到某个时间内修改的数据。在某些情况下，会引入一个 DATA_UPDATE_TIME，无论是修改UPDATE_TIME或者是修改CHECK_TIME，都会更新DATA_UPDATE_TIME。这样通过一个字段就可以知道某段时间发生变化的数据。这就是数据业务相关的修改时间。

（5）数据的删除时间：DELETE_TIME

在存在软删除的表中，很多业务往往要记录数据的删除时间和删除标记。这时我们就往往会有DELETE_TIME的字段设计。需要说明的是，一般记录DELETE_TIME字段，并不会修改DATA_UPDATE_TIME和UPDAT_TIME的时间，也就是说DELETE_TIME的时间是单独存放的。

（6）数据的同步时间：SYNC_TIME

在大型互联网的核心数据中，核心数据可能是多个业务需要使用的，这就牵涉到数据的同步时间问题。以下我们会列举几个场景来说明这个问题

A 数据的缓存同步

为了提高访问速度和性能，核心数据往往会缓存。更新缓存的方法非常多，有一种简单的方法就是根据数据的UPDATE_TIME来更新缓存。但是一定要注意UPDATE_TIME中不要包含大量的批量修改时间【也就是应该有BATCH_TIME的设计】，否则缓存的更新是一个隐患。

B 数据的搜索同步

大型互联网都是有单独的搜索索引的。搜索服务也通常会根据修改时间来获取几分钟内的数据更新索引。这是也会和A的场景一样，获取数据。同样要屏蔽批量的修改数据，否则搜索服务也会面临压力

C 级联修改时间场景

在商户的A和B的场景中，我们都会注意到只要屏蔽了批量修改的时间，通常数据的UPDATE_TIME时间是可以满足我们的要求的，不需要特别的同步时间SYNC_TIME这个设计。但是对于级联修改的场景，就会存在SYNC_TIME的问题。

一般的商品可能存在父商品和子商品的场景【子商品可能会说明不同的颜色，尺码，而父商品是公共属性】。当父商品修改后，父商品本身的时间是需要修改的，但是子商品实际没有发生变化，子商品的的信息是不需要修改的，只要子商品不修改，那么UPDATE_TIME也是不修改的。

如何能够知道哪些父商品发生变化的子商品呢？如何更新这些子商品的缓存和索引呢？有时业务可能会要求只要父商品发生修改，那么子商品的时间也应该修改，排序也应该修改。此时的SYNC_TIME就可能被设计出来，处理级联问题。当然，如果字段 DATA_UPDATE_TIME 设计的好，这个字段也是可以替代SYNC_TIME的。