Comment faire des insertions en masse (multi-row) avec JpaRepository?

Question

Lors de l'appel de la méthode saveAll de mon JpaRepository avec une longue List depuis la couche de service, le suivi de journalisation de Hibernate montre des déclarations SQL uniques émises par entité.

Puis-je le forcer à effectuer une insertion groupée (c'est-à-dire multi-lignes) sans avoir besoin de manipuler manuellement l' EntityManager, les transactions, etc. ou même des chaînes de requêtes SQL brutes?

Avec l'insertion multi-lignes, je veux dire passer de:

démarrer la transaction
INSERT INTO table VALUES (1, 2)
fin de la transaction
démarrer la transaction
INSERT INTO table VALUES (3, 4)
fin de la transaction
démarrer la transaction
INSERT INTO table VALUES (5, 6)
fin de la transaction

à:

démarrer la transaction
INSERT INTO table VALUES (1, 2)
INSERT INTO table VALUES (3, 4)
INSERT INTO table VALUES (5, 6)
fin de la transaction

mais plutôt à:

démarrer la transaction
INSERT INTO table VALUES (1, 2), (3, 4), (5, 6)
fin de la transaction

En PROD j'utilise CockroachDB, et la différence de performance est significative.

Voici un exemple minimal qui reproduit le problème (H2 pour la simplicité).

....

Answer 1

Pour réaliser une insertion en masse avec Spring Boot et Spring Data JPA, vous avez seulement besoin de deux choses :

1. définir l'option spring.jpa.properties.hibernate.jdbc.batch_size à la valeur appropriée dont vous avez besoin (par exemple : 20).

2. utiliser la méthode saveAll() de votre repo avec la liste d'entités préparée pour l'insertion.

L'exemple de travail se trouve ici.

En ce qui concerne la transformation de l'instruction d'insertion en quelque chose comme ceci :

INSERT INTO table VALUES (1, 2), (3, 4), (5, 6)

la telle est disponible dans PostgreSQL : vous pouvez définir l'option reWriteBatchedInserts sur true dans la chaîne de connexion jdbc :

jdbc:postgresql://localhost:5432/db?reWriteBatchedInserts=true

alors le pilote jdbc fera cette transformation.

Des informations supplémentaires sur le lotissement, vous pouvez les trouver ici.

À JOUR

Projet de démonstration en Kotlin : sb-kotlin-batch-insert-demo

À JOUR

Hibernate désactive le lotissement des inserts au niveau JDBC de manière transparente si vous utilisez un générateur d'identifiant IDENTITY.

Answer 2

Le problème sous-jacent est le code suivant dans SimpleJpaRepository :

@Transactional
public  S save(S entity) {
    if (entityInformation.isNew(entity)) {
        em.persist(entity);
        return entity;
    } else {
        return em.merge(entity);
    }
}

~~

En plus des paramètres de propriété de taille de lot, vous devez vous assurer que la classe SimpleJpaRepository appelle persist et non merge. Il existe quelques approches pour résoudre ce problème : utiliser un générateur @Id qui ne consulte pas le séquence, comme

@Id
@GeneratedValue(generator = "uuid2")
@GenericGenerator(name = "uuid2", strategy = "uuid2")
var id: Long

Ou forcer la persistance à traiter les enregistrements comme neufs en faisant implémenter à votre entité Persistable et en remplaçant l'appel à isNew()

@Entity
class Thing implements Pesistable {
    var value: Int,
    @Id
    @GeneratedValue
    var id: Long = -1
    @Transient
    private boolean isNew = true;
    @PostPersist
    @PostLoad
    void markNotNew() {
        this.isNew = false;
    }
    @Override
    boolean isNew() {
        return isNew;
    }
}

Ou remplacer la méthode save(List) et utiliser l'entity manager pour appeler persist()

@Repository
public class ThingRepository extends SimpleJpaRepository {
    private EntityManager entityManager;
    public ThingRepository(EntityManager entityManager) {
        super(Thing.class, entityManager);
        this.entityManager=entityManager;
    }

    @Transactional
    public List save(List things) {
        things.forEach(thing -> entityManager.persist(thing));
        return things;
    }
}

Le code ci-dessus est basé sur les liens suivants :

• http://www.hameister.org/SpringBootUsingIdsForBulkImports.html
• http://www.hameister.org/SpringBootBulkImportWithCrudRepository.html
• https://vladmihalcea.com/the-best-way-to-do-batch-processing-with-jpa-and-hibernate/

~~

Answer 3

Vous pouvez configurer Hibernate pour effectuer du DML en vrac. Jetez un œil à Spring Data JPA - inserts/updates en vrac concurrents. Je pense que la section 2 de la réponse pourrait résoudre votre problème :

Activer le regroupement des instructions DML

L'activation du support du regroupement permettrait de réduire le nombre de trajets vers la base de données pour insérer/mettre à jour le même nombre d'enregistrements.

En citant des instructions de regroupement INSERT et UPDATE :

hibernate.jdbc.batch_size = 50

hibernate.order_inserts = true

hibernate.order_updates = true

hibernate.jdbc.batch_versioned_data = true

MISE À JOUR : Vous devez définir les propriétés Hibernate différemment dans votre fichier application.properties. Ils sont sous l'espace de noms : spring.jpa.properties.*. Un exemple pourrait ressembler à ce qui suit :

spring.jpa.properties.hibernate.jdbc.batch_size = 50
spring.jpa.properties.hibernate.order_inserts = true
....

Answer 4

Toutes les méthodes mentionnées fonctionnent mais seront lentes, surtout si la source des données insérées se trouve dans une autre table. Tout d'abord, même avec batch_size>1, l'opération d'insertion sera exécutée en plusieurs requêtes SQL. Deuxièmement, si les données sources se trouvent dans une autre table, vous devez les récupérer avec d'autres requêtes (et dans le pire des cas charger toutes les données en mémoire) et les convertir en insertions massives statiques. Troisièmement, avec un appel persist() séparé pour chaque entité (même si le lot est activé), vous allez saturer le cache de premier niveau de l'EntityManager avec toutes ces instances d'entités.

Mais il y a une autre option pour Hibernate. Si vous utilisez Hibernate en tant que fournisseur JPA, vous pouvez revenir à l'HQL qui prend en charge nativement les insertions massives avec un sous-sélecteur d'une autre table. L'exemple :

Session session = entityManager.unwrap(Session::class.java)
session.createQuery("insert into Entity (field1, field2) select [...] from [...]")
  .executeUpdate();

Si cela fonctionne dépendra de votre stratégie de génération d'identifiant. Si l'ID de Entity est généré par la base de données (par exemple auto-incrémentation MySQL), cela réussira. Si l'ID de Entity est généré par votre code (surtout vrai pour les générateurs UUID), cela échouera avec une exception "méthode de génération d'ID non prise en charge".

Cependant, dans ce dernier scénario, ce problème peut être surmonté par une fonction SQL personnalisée. Par exemple, dans PostgreSQL, j'utilise l'extension uuid-ossp qui fournit la fonction uuid_generate_v4(), que je registre enfin dans mon dialogue personnalisé :

import org.hibernate.dialect.PostgreSQL10Dialect;
import org.hibernate.dialect.function.StandardSQLFunction;
import org.hibernate.type.PostgresUUIDType;

public class MyPostgresDialect extends PostgreSQL10Dialect {

    public MyPostgresDialect() {
        registerFunction( "uuid_generate_v4", 
            new StandardSQLFunction("uuid_generate_v4", PostgresUUIDType.INSTANCE));
    }
}

Ensuite, je registre cette classe en tant que dialogue hibernate :

hibernate.dialect=MyPostgresDialect

Enfin, je peux utiliser cette fonction dans la requête d'insertion en masse :

SessionImpl session = entityManager.unwrap(Session::class.java);
session.createQuery("insert into Entity (id, field1, field2) "+
  "select uuid_generate_v4(), [...] from [...]")
  .executeUpdate();

Le plus important est le SQL sous-jacent généré par Hibernate pour accomplir cette opération et il s'agit d'une seule requête :

insert into entity ( id, [...] ) select uuid_generate_v4(), [...] from [...]

Answer 5

J'ai eu le même problème mais je ne pouvais pas voir mes requêtes Hibernate en batch, j'ai réalisé que la requête ne se traduisait pas réellement en ce qui était réellement interrogé. Mais pour être sûr que c'est en vrac, vous pouvez activer la génération de statistiques spring.jpa.properties.hibernate.generate_statistics=true puis vous verrez :

lorsque vous ajoutez spring.jpa.properties.hibernate.jdbc.batch_size=100, vous commencerez à voir des différences, comme moins de déclarations jdbc et plus de lots jdbc :