私はSpringの経験がありますが、SpringBatchは初めてです。これで、データ構造を1つのデータベースの単純な構造から別のデータベースのより複雑な構造に移行するタスクがあります。データ構造は、このように名前を付けるオブジェクト階層に対応しています
OldParent 1 --> n OldChild // old system
NewParent 1 --> n NewChild // new system
古いデータベースではテーブルが2つしかなく、新しいシステムでは状況がさらに複雑になり、テーブルが8つありますが、今のところそれは関係ありません。
基本的に、行マッパーがOldParentから読み取り、NewParentに変換する単純なJDBCベースのソリューションを使用したいと思います。
したがって、基本的な構成スニペットは次のようになります。
<batch:job id="migration">
<batch:step id="convertLegacyData">
<batch:tasklet>
<batch:chunk
reader="parentReader"
writer="parentWriter"
commit-interval="200" />
</batch:tasklet>
</batch:step>
</batch:job>
このシナリオでは、parentReaderはOldChildオブジェクトを取得して変換し、おそらくchildReader/childWriterオブジェクトに委任します。
問題はこれです。数十万の親がありますが、各親は0から数百万の子を持つことができるため、親に基づくコミット間隔はまったく役に立ちませんが、構成可能なコミット間隔が必要です。
したがって、別の解決策は、ワークフローを子ベースにすることです。
<batch:job id="migration">
<batch:step id="convertLegacyData">
<batch:tasklet>
<batch:chunk
reader="childReader"
writer="childWriter"
commit-interval="200" />
</batch:tasklet>
</batch:step>
</batch:job>
このシナリオでは、childReaderはOldParentオブジェクトを読み取り、NewParentsを書き込み、parentReaderオブジェクトとparentWriterオブジェクトに委任する必要があります。ここでの主な欠点は、OldChildオブジェクトが関連付けられていないすべてのOldParentを失うことです。
OldParent -> NewParent3番目に考えられるシナリオは、との2つの異なるワークフローを持つことOldChild -> NewChildです。（OldParentIDとNewParentIDの間の関係を格納するマッピングテーブルを維持する必要がありますが、commit-intervalを含む標準構成を使用できます。
他の可能性はありますか？これらのうち、ベストプラクティスとして推奨するものはどれですか。