Décider entre l'étape du lot de printemps, le Tasklet ou les morceaux

J'ai un simple exigence dans lequel, j'ai besoin de lire une liste d'éléments(DB) et la nécessité de traiter les articles et, une fois traitées, il doit être mis à jour en DB.

Je suis en train de penser à l'aide de Spring batch Morceaux avec le lecteur, le processeur et écrivain. Mon lecteur ne sera de retour qu'un seul élément à la fois à partir de la liste et l'envoie au processeur et une fois que le traitement est terminé, il retourne à l'Écrivain, où il met à jour la DB

Je suis peut-être le multithreading plus tard avec certains coût de la synchronisation de ces méthodes.

Ici, je prévois un peu de préoccupations.

  1. Nombre d'articles à traiter pourrait être plus. Peut être dans 10 000 s, voire plus.
  2. certaines logique de calcul est nécessaire dans le processeur. d'où le traitement de 1 point à la fois. pas sûr au sujet de la performance, même si elle est multithread avec 10 threads.
  3. Écrivain pouvez mettre à jour les résultats dans la base de données pour que les traités de l'élément. Pas sûr de la façon de faire les mises à jour par lot parce qu'il a toujours seulement 1 point transformés et prêts.

Cette approche est-elle correcte pour ce genre de cas d'utilisation, ou quelque chose de mieux qui peut être fait?
Est-il tout autre moyen de traitement d'un tas de produits, à un appel de lecteur, processeur & écrivain? si oui, dois-je créer un certain mechnism où j'ai extrait de dire 10 éléments de la liste et de le donner à processeur?
il semble écrivain mises à jour de chacun des dossiers comme il vient, les mises à jour par lot de sens que si le vendeur reçoit un tas d'objets traités. toute suggestion?

S'il vous plaît jeter quelques lumières sur cette conception pour une meilleure performance.

Merci,

source d'informationauteur Vimal

  1. 13

    Spring Batch est l'outil parfait pour faire ce que vous avez besoin.

    Le morceau orienté étape vous permettent de configurer la façon dont beaucoup d'éléments que vous souhaitez lire/processus/écriture avec la validation de l'intervalle de propriété.

            <batch:step id="step1" next="step2">
        <batch:tasklet transaction-manager="transactionManager" start-limit="100">
            <batch:chunk reader="myReader" processor="myProcessor" writer="MyWriter" commit-interval="800" />
            <batch:listeners>
                <batch:listener ref="myListener" />
            </batch:listeners>
        </batch:tasklet>
    </batch:step>

    Disons que votre lecteur va appeler une instruction SELECT qui retourne 10 000 dossiers. Et vous définissez un commit-intervalle=500.

    MyReader fera appel à la méthode read() de 500 fois. Disons que dans la réalité, le lecteur de la mise en œuvre pourrait, en fait, supprimer des éléments dans le jeu de résultats. Pour chaque appel à la fonction read(), il sera également appeler la méthode process() de MyProcessor.

    Mais il ne fera pas appel de la méthode write() de MyWriter jusqu'à la validation de l'intervalle est atteint.

    Si vous regardez la définition de l'interface ItemWriter:

    public interface ItemWriter<T> {

/**
 * Process the supplied data element. Will not be called with any null items
 * in normal operation.
 * 
 * @throws Exception if there are errors. The framework will catch the
 * exception and convert or rethrow it as appropriate.
 */
void write(List<? extends T> items) throws Exception;

}

    Vous voyez que l'écriture de recevoir une Liste d'éléments. Cette liste sera la taille de votre commit-intervalle (ou moins si le but est atteint)

    Et btw, 10 000 d'enregistrements n'est rien. Vous pouvez envisager de multithreading si vous avez à traiter avec des millions d'enregistrements. Mais, même là, en train de jouer avec le sweet spot de la validation de l'intervalle de valeur sera probablement suffisant.

    Espère que cela aide