spring batch数据库表数据结构

spring batch数据库表数据结构

前言碎语

博客因为域名未被实名被暂停解析，申请实名加审批到域名重新可用，上下折腾导致博客四五天不能访问，这期间也成功了使用spring batch Integration 完成了spring batch分区远程的工程搭建，期间有使用ActiveMQ（JMS）的实现也有基于RabbitMQ（AMQP）的实现，最终选择了基于RabbitMQ的远程主从模式搭建项目，最终项目模型支持一主多从，多主多从，主从混用的使用，极大的提高了批处理的效率，解决了单机批处理的性能瓶颈。为了强化对spring batch关键概念的理解，故有了如下的对spring batch元数据结构的记录描述

概观

Spring Batch 的数据表结构与在Java中的Domain对象非常匹配。例如，JobInstance，JobExecution，JobParameters，和StepExecution 映射到BATCH_JOB_INSTANCE，BATCH_JOB_EXECUTION，BATCH_JOB_EXECUTION_PARAMS，和 BATCH_STEP_EXECUTION，分别。ExecutionContext映射到两者BATCH_JOB_EXECUTION_CONTEXT和BATCH_STEP_EXECUTION_CONTEXT。该JobRepository负责将每个Java对象保存并存储到其正确的表中。本附录详细介绍了元数据表以及创建时的许多设计决策。在查看下面的各种表创建语句时，意识到所使用的数据类型尽可能通用是很重要的。由于各个数据库供应商处理数据类型的方式不同，Spring Batch提供了许多架构作为示例，所有这些架构都有不同的数据类型。下图显示了所有6个表格的ERD模型及其相互间的关系：

图1. Spring批处理元数据ERD

A.1.1。示例DDL脚本

Spring Batch Core JAR文件包含用于为多个数据库平台创建关系表的示例脚本（这些脚本又由作业存储库工厂bean或名称空间等效项自动检测到）。这些脚本可以按原样使用，也可以根据需要使用其他索引和约束进行修改。文件名的格式为schema-*.sql“*”，表示目标数据库平台的简称。脚本在包中org.springframework.batch.core。

A2。 BATCH_JOB_INSTANCE

该BATCH_JOB_INSTANCE表包含与a相关的所有信息JobInstance，并作为整个层次结构的顶层。以下通用DDL语句用于创建它：

以下列表描述了表中的每一列：

• JOB_INSTANCE_ID：标识实例的唯一标识。这也是主要关键。这个列的值应该可以通过调用getId方法 来获得JobInstance。
• VERSION：见版本。
• JOB_NAME：从Job对象获取的作业的名称。由于需要标识实例，因此它不能为空。
• JOB_KEY：它的序列化JobParameters唯一地识别相同作业的不同实例。（JobInstances具有相同的作业名称必须具有JobParameters不同的JOB_KEY值，因此具有不同的值）。

A.3。 BATCH_JOB_EXECUTION_PARAMS

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

以下列表描述了每列：

• JOB_EXECUTION_ID：BATCH_JOB_EXECUTION表中的外键，指示参数条目所属的作业执行。请注意，每次执行都可能存在多行（即键/值对）。
• TYPE_CD：存储值类型的字符串表示形式，可以是字符串，日期，长整数或双精度。由于该类型必须是已知的，因此它不能为空。
• KEY_NAME：参数键。
• STRING_VAL：参数值，如果类型是字符串。
• DATE_VAL：参数值，如果类型是日期。
• LONG_VAL：参数值，如果类型很长。
• DOUBLE_VAL：参数值，如果类型是双倍的。
• IDENTIFYING：指示参数是否有助于相关身份的标志JobInstance。

请注意，此表没有主键。这是因为框架没有用于一个，因此不需要它。如果需要，您可以添加一个主键，并添加一个数据库生成的密钥，而不会给框架本身带来任何问题。

A.4。 BATCH_JOB_EXECUTION

该BATCH_JOB_EXECUTION表包含与该JobExecution 对象有关的所有信息。每次Job运行a时JobExecution，此表中总是有一个新的和新的一行。以下清单显示了该BATCH_JOB_EXECUTION 表的定义：

以下列表描述了每列：

• JOB_EXECUTION_ID：唯一标识此执行的主键。该列的值可通过调用对象的getId方法获得JobExecution。
• VERSION：见版本。
• JOB_INSTANCE_ID：BATCH_JOB_INSTANCE表中的外键。它表示此执行所属的实例。每个实例可能有多个执行。
• CREATE_TIME：代表创建执行时间的时间戳。
• START_TIME：代表执行开始时间的时间戳。
• END_TIME：表示执行完成时的时间戳，无论成功或失败。当作业当前未运行时，此列中的空值表示存在某种类型的错误，并且框架无法在失败之前执行上次保存。
• STATUS：表示执行状态的字符串。这可能是 COMPLETED，STARTED等等。该列的对象表示是 BatchStatus枚举。
• EXIT_CODE：表示执行退出代码的字符串。对于命令行作业，可能会将其转换为数字。
• EXIT_MESSAGE：表示作业如何退出的更详细描述的字符串。在失败的情况下，这可能包括尽可能多的堆栈跟踪。
• LAST_UPDATED：代表上次执行持续时间的时间戳。

A.5。 BATCH_STEP_EXECUTION

BATCH_STEP_EXECUTION表包含与该StepExecution 对象相关的所有信息。该表格在很多方面与BATCH_JOB_EXECUTION表格类似，Step每个JobExecution创建的表格总是至少有一个条目。以下清单显示了该BATCH_STEP_EXECUTION表的定义：

以下列表描述了每列：

• STEP_EXECUTION_ID：唯一标识此执行的主键。该列的值应该可以通过调用 对象的getId方法来获得StepExecution。
• VERSION：见版本。
• STEP_NAME：此执行程序所属步骤的名称。
• JOB_EXECUTION_ID：BATCH_JOB_EXECUTION表中的外键。它表明 JobExecution这StepExecution属于哪个。StepExecution给JobExecution定Step名称可能只有一个 给定的名称。
• START_TIME：代表执行开始时间的时间戳。
• END_TIME：表示执行完成时的时间戳，无论成功或失败。即使作业当前未运行，此列中的空值也表示存在某种类型的错误，并且框架无法在失败之前执行上次保存。
• STATUS：表示执行状态的字符串。这可能是 COMPLETED，STARTED等等。该列的对象表示是 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：代表上次执行持续时间的时间戳。

A.6。BATCH_JOB_EXECUTION_CONTEXT

该BATCH_JOB_EXECUTION_CONTEXT表包含ExecutionContext与a 有关的所有信息 Job。Job ExecutionContext每个 只有一个JobExecution，它包含特定作业执行所需的所有作业级别数据。这些数据通常代表故障发生后必须检索的状态，以便JobInstance罐头能够“从停止的位置开始”。以下清单显示了该BATCH_JOB_EXECUTION_CONTEXT表的定义：

以下列表描述了每列：

• JOB_EXECUTION_ID：表示JobExecution上下文所属的外键。可能有多于一行与给定的执行相关联。
• SHORT_CONTEXT：一个字符串版本的SERIALIZED_CONTEXT。
• SERIALIZED_CONTEXT：整个上下文序列化。

A.7。 BATCH_STEP_EXECUTION_CONTEXT

该BATCH_STEP_EXECUTION_CONTEXT表包含ExecutionContext与a 有关的所有信息 Step。ExecutionContext每个StepExecution数据只有一个，它包含了需要为特定步骤执行而保留的所有数据。这些数据通常代表故障发生后必须检索的状态，以便JobInstance可以从停止的位置开始。以下清单显示了该BATCH_STEP_EXECUTION_CONTEXT表的定义 ：

以下列表描述了每列：

• STEP_EXECUTION_ID：表示StepExecution上下文所属的外键。可能有多个行与给定的执行关联。
• SHORT_CONTEXT：一个字符串版本的SERIALIZED_CONTEXT。
• SERIALIZED_CONTEXT：整个上下文序列化。

A.8。存档

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

• 该框架使用元数据表来确定JobInstance 以前是否已经运行了某个特定的表。如果它已经运行并且作业不可重启，则会引发异常。
• 如果JobInstance未成功完成删除条目，则框架认为该作业是新的，而不是重新启动。
• 如果作业重新启动，框架将使用任何已持久保存的数据 ExecutionContext来恢复Job’s状态。因此，对于尚未成功完成的作业，从该表中删除任何条目可防止它们在再次运行时从正确的位置开始。

A.9。国际和多字节字符

如果您在业务处理中使用多字节字符集（例如中文或西里尔语），那么这些字符可能需要在Spring Batch模式中保留。许多用户发现，只需将模式更改为VARCHAR 列长的两倍就足够了。其他人则倾向于配置 JobRepository与max-varchar-length该值的一半VARCHAR列长度。有些用户还报告说，他们利用 NVARCHAR代替VARCHAR他们的模式定义。最好的结果取决于数据库平台以及数据库服务器本地配置的方式。

A.10。索引元数据表的建议

Spring Batch为几个常见数据库平台的核心jar文件中的元数据表提供了DDL示例。索引声明不包含在该DDL中，因为用户需要索引的方式有很多不同，具体取决于他们的精确平台，本地约定以及作业如何运行的业务要求。下面提供了一些WHERE关于Spring批处理提供的DAO实现将使用哪些列以及它们可能被使用的频率的一些指示，以便单个项目可以对索引编制自己的想法：

表1. SQL语句中的where子句（不包括主键）及其近似使用频率。