# 元数据模式

# 附录 A:元数据模式

# 概述

Spring 批处理元数据表与在 Java 中表示它们的域对象非常匹配。例如,JobInstanceJobExecutionJobParameters,和StepExecution分别映射到BATCH_JOB_INSTANCEBATCH_JOB_EXECUTIONBATCH_JOB_EXECUTION_PARAMSBATCH_STEP_EXECUTIONExecutionContext映射到BATCH_JOB_EXECUTION_CONTEXTBATCH_STEP_EXECUTION_CONTEXTJobRepository负责将每个 Java 对象保存并存储到其正确的表中。本附录详细描述了元数据表,以及在创建元数据表时做出的许多设计决策。在查看下面的各种表创建语句时,重要的是要认识到所使用的数据类型是尽可能通用的。 Spring Batch 提供了许多模式作为示例,所有这些模式都具有不同的数据类型,这是由于各个数据库供应商处理数据类型的方式有所不同。下图显示了所有 6 个表及其相互关系的 ERD 模型:

Spring Batch Meta-Data ERD

图 1。 Spring 批处理元数据 ERD

# 示例 DDL 脚本

Spring 批处理核心 JAR 文件包含用于为许多数据库平台创建关系表的示例脚本(反过来,这些平台由作业存储库工厂 Bean 或等效的名称空间自动检测)。这些脚本可以按原样使用,也可以根据需要修改附加的索引和约束。文件名的形式为schema-*.sql,其中“*”是目标数据库平台的简称。脚本在包org.springframework.batch.core中。

# 迁移 DDL 脚本

Spring Batch 提供了在升级版本时需要执行的迁移 DDL 脚本。这些脚本可以在org/springframework/batch/core/migration下的核心 JAR 文件中找到。迁移脚本被组织到与版本号对应的文件夹中,这些版本号被引入:

  • 2.2:如果你从2.2之前的版本迁移到2.2版本,则包含所需的脚本

  • 4.1:如果你从4.1之前的版本迁移到4.1版本,则包含所需的脚本

# 版本

本附录中讨论的许多数据库表都包含一个版本列。这一列很重要,因为 Spring 批处理在处理数据库更新时采用了乐观的锁定策略。这意味着每次“触摸”(更新)记录时,Version 列中的值都会增加一个。当存储库返回以保存该值时,如果版本号发生了更改,它将抛出一个OptimisticLockingFailureException,表示在并发访问中出现了错误。这种检查是必要的,因为即使不同的批处理作业可能在不同的机器中运行,它们都使用相同的数据库表。

# 恒等式

BATCH_JOB_INSTANCEBATCH_JOB_EXECUTIONBATCH_STEP_EXECUTION都包含以_ID结尾的列。这些字段充当各自表的主键。然而,它们不是数据库生成的密钥。相反,它们是由单独的序列生成的。这是必要的,因为在将一个域对象插入到数据库中之后,需要在实际对象上设置给定的键,以便在 Java 中对它们进行唯一标识。较新的数据库驱动程序(JDBC3.0 及以上版本)通过数据库生成的键支持此功能。然而,使用的是序列,而不是要求该功能。模式的每个变体都包含以下语句的某种形式:

CREATE SEQUENCE BATCH_STEP_EXECUTION_SEQ;
CREATE SEQUENCE BATCH_JOB_EXECUTION_SEQ;
CREATE SEQUENCE BATCH_JOB_SEQ;

许多数据库供应商不支持序列。在这些情况下,使用了变通方法,例如 MySQL 的以下语句:

CREATE TABLE BATCH_STEP_EXECUTION_SEQ (ID BIGINT NOT NULL) type=InnoDB;
INSERT INTO BATCH_STEP_EXECUTION_SEQ values(0);
CREATE TABLE BATCH_JOB_EXECUTION_SEQ (ID BIGINT NOT NULL) type=InnoDB;
INSERT INTO BATCH_JOB_EXECUTION_SEQ values(0);
CREATE TABLE BATCH_JOB_SEQ (ID BIGINT NOT NULL) type=InnoDB;
INSERT INTO BATCH_JOB_SEQ values(0);

在前一种情况下,用一个表来代替每个序列。 Spring 核心类MySQLMaxValueIncrementer然后在这个序列中增加一列,以便提供类似的功能。

# BATCH_JOB_INSTANCE

BATCH_JOB_INSTANCE表保存了与JobInstance相关的所有信息,并作为整个层次结构的顶部。下面的通用 DDL 语句用于创建它:

CREATE TABLE BATCH_JOB_INSTANCE  (
  JOB_INSTANCE_ID BIGINT  PRIMARY KEY ,
  VERSION BIGINT,
  JOB_NAME VARCHAR(100) NOT NULL ,
  JOB_KEY VARCHAR(2500)
);

下面的列表描述了表中的每个列:

  • JOB_INSTANCE_ID:标识实例的唯一 ID。这也是主要的关键。可以通过调用JobInstance上的getId方法获得此列的值。

  • VERSION:见Version

  • JOB_NAME:从Job对象获得的作业的名称。因为需要它来标识实例,所以它不能是空的。

  • JOB_KEY:JobParameters的序列化,该序列化唯一地标识同一作业的不同实例。(具有相同工作名称的JobInstances必须有不同的JobParameters,因此,不同的JOB_KEY值)。

# BATCH_JOB_EXECUTION_PARAMS

BATCH_JOB_EXECUTION_PARAMS表包含与JobParameters对象相关的所有信息。它包含传递给Job的 0 个或更多个键/值对,并用作运行作业的参数的记录。对于每个有助于生成作业标识的参数,IDENTIFYING标志被设置为 true。请注意,该表已被非规范化。不是为每个类型创建一个单独的表,而是有一个表,其中有一列指示类型,如下面的清单所示:

CREATE TABLE BATCH_JOB_EXECUTION_PARAMS  (
	JOB_EXECUTION_ID BIGINT NOT NULL ,
	TYPE_CD VARCHAR(6) NOT NULL ,
	KEY_NAME VARCHAR(100) NOT NULL ,
	STRING_VAL VARCHAR(250) ,
	DATE_VAL DATETIME DEFAULT NULL ,
	LONG_VAL BIGINT ,
	DOUBLE_VAL DOUBLE PRECISION ,
	IDENTIFYING CHAR(1) NOT NULL ,
	constraint JOB_EXEC_PARAMS_FK foreign key (JOB_EXECUTION_ID)
	references BATCH_JOB_EXECUTION(JOB_EXECUTION_ID)
);

下面的列表描述了每一列:

  • JOB_EXECUTION_ID:来自BATCH_JOB_EXECUTION表的外键,该外键指示参数项所属的作业执行。请注意,每个执行都可能存在多个行(即键/值对)。

  • type_cd:存储的值的类型的字符串表示形式,可以是字符串、日期、长值或双值。因为类型必须是已知的,所以它不能是空的。

  • key_name:参数键。

  • string_val:参数值,如果类型是 string。

  • date_val:参数值,如果类型是 date。

  • long_val:参数值,如果类型是 long。

  • double_val:参数值,如果类型是 double。

  • 标识:标志,指示参数是否有助于相关的JobInstance的标识。

请注意,此表没有主键。这是因为该框架不需要一个框架,因此不需要它。如果需要,可以添加主键,也可以添加与数据库生成的键,而不会对框架本身造成任何问题。

# BATCH_JOB_EXECUTION

BATCH_JOB_EXECUTION表包含与JobExecution对象相关的所有信息。每次运行Job时,总会有一个新的JobExecution,并在此表中有一个新的行。下面的清单显示了BATCH_JOB_EXECUTION表的定义:

CREATE TABLE BATCH_JOB_EXECUTION  (
  JOB_EXECUTION_ID BIGINT  PRIMARY KEY ,
  VERSION BIGINT,
  JOB_INSTANCE_ID BIGINT NOT NULL,
  CREATE_TIME TIMESTAMP NOT NULL,
  START_TIME TIMESTAMP DEFAULT NULL,
  END_TIME TIMESTAMP DEFAULT NULL,
  STATUS VARCHAR(10),
  EXIT_CODE VARCHAR(20),
  EXIT_MESSAGE VARCHAR(2500),
  LAST_UPDATED TIMESTAMP,
  JOB_CONFIGURATION_LOCATION VARCHAR(2500) NULL,
  constraint JOB_INSTANCE_EXECUTION_FK foreign key (JOB_INSTANCE_ID)
  references BATCH_JOB_INSTANCE(JOB_INSTANCE_ID)
) ;

下面的列表描述了每一列:

  • JOB_EXECUTION_ID:唯一标识此执行的主键。通过调用JobExecution对象的getId方法,可以获得此列的值。

  • VERSION:见Version

  • JOB_INSTANCE_ID:来自BATCH_JOB_INSTANCE表的外键。它指示此执行所属的实例。每个实例可能有多个执行。

  • CREATE_TIME:表示创建执行时间的时间戳。

  • START_TIME:表示开始执行的时间的时间戳。

  • END_TIME:时间戳表示执行完成的时间,无论成功还是失败。当作业当前未运行时,此列中的空值表示发生了某种类型的错误,框架在失败之前无法执行最后一次保存。

  • STATUS:表示执行状态的字符串。这可能是COMPLETEDSTARTED等。此列的对象表示是BatchStatus枚举。

  • EXIT_CODE:表示执行的退出代码的字符串。在命令行作业的情况下,可以将其转换为数字。

  • EXIT_MESSAGE:表示作业如何退出的更详细描述的字符串。在失败的情况下,这可能包括尽可能多的堆栈跟踪。

  • LAST_UPDATED:时间戳表示此执行最后一次被持久化的时间。

# BATCH_STEP_EXECUTION

批处理 _step_execution 表保存与StepExecution对象相关的所有信息。该表在许多方面与BATCH_JOB_EXECUTION表类似,并且对于每个创建的JobExecution,每个Step总是至少有一个条目。下面的清单显示了BATCH_STEP_EXECUTION表的定义:

CREATE TABLE BATCH_STEP_EXECUTION  (
  STEP_EXECUTION_ID BIGINT  PRIMARY KEY ,
  VERSION BIGINT NOT NULL,
  STEP_NAME VARCHAR(100) NOT NULL,
  JOB_EXECUTION_ID BIGINT NOT NULL,
  START_TIME TIMESTAMP NOT NULL ,
  END_TIME TIMESTAMP DEFAULT NULL,
  STATUS VARCHAR(10),
  COMMIT_COUNT BIGINT ,
  READ_COUNT BIGINT ,
  FILTER_COUNT BIGINT ,
  WRITE_COUNT BIGINT ,
  READ_SKIP_COUNT BIGINT ,
  WRITE_SKIP_COUNT BIGINT ,
  PROCESS_SKIP_COUNT BIGINT ,
  ROLLBACK_COUNT BIGINT ,
  EXIT_CODE VARCHAR(20) ,
  EXIT_MESSAGE VARCHAR(2500) ,
  LAST_UPDATED TIMESTAMP,
  constraint JOB_EXECUTION_STEP_FK foreign key (JOB_EXECUTION_ID)
  references BATCH_JOB_EXECUTION(JOB_EXECUTION_ID)
) ;

下面的列表描述了每个列:

  • STEP_EXECUTION_ID:唯一标识此执行的主键。可以通过调用StepExecution对象的getId方法获得此列的值。

  • VERSION:见Version

  • STEP_NAME:此执行所属的步骤的名称。

  • JOB_EXECUTION_ID:来自BATCH_JOB_EXECUTION表的外键。它指示了JobExecution这个StepExecution所属的JobExecution。对于给定的JobExecution名称,可能只有一个StepExecution

  • START_TIME:表示开始执行的时间的时间戳。

  • END_TIME:时间戳表示执行完成的时间,无论成功还是失败。此列中的空值(即使作业当前未运行)表示存在某种类型的错误,并且框架在失败之前无法执行最后一次保存。

  • STATUS:表示执行状态的字符串。这可能是COMPLETEDSTARTED等。此列的对象表示是BatchStatus枚举。

  • COMMIT_COUNT:在执行过程中,步骤提交事务的次数。

  • READ_COUNT:执行过程中读取的项数。

  • FILTER_COUNT:从该执行中筛选出的项的数量。

  • WRITE_COUNT:在执行过程中写入和提交的项的数量。

  • READ_SKIP_COUNT:在执行过程中读时跳过的项的数量。

  • WRITE_SKIP_COUNT:在执行过程中在写入时跳过的项数。

  • PROCESS_SKIP_COUNT:在此执行过程中处理过程中跳过的项的数量。

  • ROLLBACK_COUNT:执行过程中的回滚次数。请注意,此计数包括每次发生回滚时,包括用于重试的回滚和在跳过恢复过程中的回滚。

  • EXIT_CODE:表示执行的退出代码的字符串。在命令行作业的情况下,可以将其转换为数字。

  • EXIT_MESSAGE:表示作业如何退出的更详细描述的字符串。在失败的情况下,这可能包括尽可能多的堆栈跟踪。

  • LAST_UPDATED:时间戳表示此执行最后一次被持久化的时间。

# BATCH_JOB_EXECUTION_CONTEXT

BATCH_JOB_EXECUTION_CONTEXT表包含与JobExecutionContext相关的所有信息。这里正好有一个Job``ExecutionContextperJobExecution,它包含特定作业执行所需的所有作业级别数据。该数据通常表示故障后必须检索的状态,因此JobInstance可以“从它停止的地方开始”。下面的清单显示了BATCH_JOB_EXECUTION_CONTEXT表的定义:

CREATE TABLE BATCH_JOB_EXECUTION_CONTEXT  (
  JOB_EXECUTION_ID BIGINT PRIMARY KEY,
  SHORT_CONTEXT VARCHAR(2500) NOT NULL,
  SERIALIZED_CONTEXT CLOB,
  constraint JOB_EXEC_CTX_FK foreign key (JOB_EXECUTION_ID)
  references BATCH_JOB_EXECUTION(JOB_EXECUTION_ID)
) ;

下面的列表描述了每一列:

  • JOB_EXECUTION_ID:表示上下文所属的JobExecution的外键。与给定的执行相关联的行可能不止一个。

  • SHORT_CONTEXT:SERIALIZED_CONTEXT的字符串版本。

  • SERIALIZED_CONTEXT:整个上下文,序列化。

# BATCH_STEP_EXECUTION_CONTEXT

BATCH_STEP_EXECUTION_CONTEXT表包含与StepExecutionContext相关的所有信息。每StepExecution正好有一个ExecutionContext,它包含了为执行特定步骤而需要持久化的所有数据。该数据通常表示故障后必须检索的状态,这样JobInstance就可以“从它停止的地方开始”。下面的清单显示了BATCH_STEP_EXECUTION_CONTEXT表的定义:

CREATE TABLE BATCH_STEP_EXECUTION_CONTEXT  (
  STEP_EXECUTION_ID BIGINT PRIMARY KEY,
  SHORT_CONTEXT VARCHAR(2500) NOT NULL,
  SERIALIZED_CONTEXT CLOB,
  constraint STEP_EXEC_CTX_FK foreign key (STEP_EXECUTION_ID)
  references BATCH_STEP_EXECUTION(STEP_EXECUTION_ID)
) ;

下面的列表描述了每一列:

  • STEP_EXECUTION_ID:表示上下文所属的StepExecution的外键。可能有多个行与给定的执行相关联。

  • SHORT_CONTEXT:SERIALIZED_CONTEXT的字符串版本。

  • SERIALIZED_CONTEXT:整个上下文,序列化。

# 存档

由于每次运行批处理作业时,多个表中都有条目,因此通常需要为元数据表创建归档策略。这些表本身旨在显示过去发生的事情的记录,并且通常不会影响任何作业的运行,只有一些与重新启动有关的明显例外:

  • 该框架使用元数据表来确定特定的JobInstance是否已经运行过。如果作业已经运行,并且不能重新启动,那么将抛出一个异常。

  • 如果JobInstance的条目在未成功完成的情况下被删除,则框架认为该作业是新的,而不是重新启动。

  • 如果重新启动了一个作业,框架将使用已持久化到ExecutionContext的任何数据来恢复Job’s状态。因此,如果作业没有成功完成,从该表中删除任何条目,将阻止它们在再次运行时从正确的点开始。

# 国际和多字节字符

如果你在业务处理中使用多字节字符集(例如中文或西里尔),那么这些字符可能需要在 Spring 批处理模式中持久化。许多用户发现,只需将模式更改为VARCHAR列的长度的两倍就足够了。其他人更喜欢将JobRepository配置为max-varchar-length列长度的一半。一些用户还报告说,他们在模式定义中使用NVARCHAR代替VARCHAR。最佳结果取决于数据库平台和本地配置数据库服务器的方式。

# 建立元数据表索引的建议

Spring 批处理为几个常见的数据库平台的核心 JAR 文件中的元数据表提供了 DDL 示例。索引声明不包含在该 DDL 中,因为用户可能希望索引的方式有太多的变化,这取决于他们的精确平台、本地约定以及作业如何操作的业务需求。下面的内容提供了一些指示,说明 Spring Batch 提供的 DAO 实现将在WHERE子句中使用哪些列,以及它们可能被使用的频率,以便各个项目可以就索引做出自己的决定:

Default Table Name Where Clause 频率
BATCH_JOB_INSTANCE JOB_NAME = ? and JOB_KEY = ? 每次有工作要做的时候
BATCH_JOB_EXECUTION JOB_INSTANCE_ID = ? 每次重新启动作业时
BATCH_STEP_EXECUTION VERSION = ? 在提交间隔上,a.k.a.chunk(以及
步骤的开始和结束)
BATCH_STEP_EXECUTION STEP_NAME = ? and JOB_EXECUTION_ID = ? 在每一步执行之前