Migliori pratiche per l'ottimizzazione IBM Master Data Management delle prestazioni

Il IBM Master Data Management servizio elabora e analizza grandi volumi di dati registrati per creare entità di dati master. Seguendo le linee guida e le best practice descritte in questo argomento, potrai contribuire a garantire che la distribuzione del tuo IBM Master Data Management servizio funzioni in modo ottimale.

Per informazioni sulla modifica della risorsa IBM Master Data Management personalizzata (mdm-cr), vedere Modifica della CR per personalizzare IBMMaster Data Management l'installazione.

Importante: la modifica della configurazione predefinita delle risorse influisce sulle prestazioni del servizio. Modifica le opzioni di configurazione solo se sei sicuro delle modifiche apportate. Siate pronti a ripristinare le modifiche apportate, se necessario.

Scegli la configurazione di ridimensionamento corretta

Quando si esegue il deployment IBM Master Data Management, è possibile scegliere tra diverse dimensioni standard preconfigurate:

level_1 (x-small) - Solo a scopo dimostrativo e di sviluppo.
level_2 (small_mincpureq) - Simile alla level_3 dimensione, ma con dimensioni delle richieste CPU inferiori.
level_3 (small) - La dimensione predefinita, per implementazioni più piccole.
level_4 (medium) - Per implementazioni di volume medio.
level_5 (large) - Per implementazioni su larga scala.

Il livello di level_1 configurazione scalabile richiede i requisiti minimi di sistema, come documentato nei requisiti hardware.

Se la dimensione stimata della configurazione di distribuzione rientra tra due delle dimensioni standard, iniziare con la specifica di ridimensionamento inferiore. È quindi possibile regolare l'allocazione delle risorse in base alle esigenze.

Assicurati di disporre di risorse hardware sufficienti per le dimensioni selezionate. Per ulteriori dettagli e assistenza, contattare il proprio IBM® rappresentante commerciale o IBM il servizio di assistenza.

Per ulteriori informazioni sulle opzioni e considerazioni relative al dimensionamento, scaricare il documento guida sul ridimensionamento dei componenti. Per ulteriori informazioni su come scaricare il PDF, consultare Scaricare il PDF con le linee guida sul ridimensionamento dei componenti dal Registro IBM autorizzato.

Carica i dati in blocco utilizzando l'API

Per i lavori di caricamento di dati in blocco che coinvolgono grandi volumi di dati, utilizzare l'API di caricamento in blocco invece dell'interfaccia IBM Master Data Management utente per caricare i dati. Per ulteriori informazioni sui metodi API, consultare il Riferimento IBM Master Data Management API.

Inoltre, considera le seguenti indicazioni relative al caricamento di grandi volumi di dati:

Per semplificare la gestione degli errori, è preferibile dividere i file di grandi dimensioni in più parti e caricarli uno alla volta.
I processi di caricamento dei dati sono molto intensivi in termini di I/O, quindi è importante configurare il numero corretto di executor. La configurazione del numero di eseguitori dipende dalle risorse disponibili, ma normalmente dovrebbe essere inferiore a 20. È preferibile che il parallelismo Spark sia un multiplo degli executor. Ad esempio, per N esecutori, configurare il parallelismo Spark da N a 4N.

Ottimizza il servizio per i lavori di derivazione in blocco

Per i lavori di derivazione in blocco, potrebbe essere necessario regolare il parallelismo Apache Spark del sistema. Il parallelismo Spark di 128 è sufficiente per 10 milioni di record quando sono disponibili 6 GB di memoria dell'esecutore. Con l'aumentare del volume dei dati, è necessario aumentare proporzionalmente il parallelismo di Spark. Per un dato volume, il numero di parallelismi dovrebbe essere maggiore se la memoria dell'esecutore è ridotta.

Ottimizza il servizio per i lavori di corrispondenza in blocco

Analogamente ai lavori di derivazione in blocco, potrebbe essere necessario regolare il parallelismo Apache Spark del sistema per i lavori di corrispondenza in blocco. Il valore di parallelismo richiesto dipende dalla configurazione specifica dell'algoritmo di corrispondenza, dal volume totale dei record nel sistema e dalla quantità di memoria allocata agli executor Spark. Un parallelismo Spark di 256 dovrebbe essere sufficiente per set di dati con 10 milioni di record, ipotizzando 6 GB di memoria dell'esecutore.

Per un dato volume, il numero di parallelismi dovrebbe essere maggiore se la memoria dell'esecutore è ridotta.

Con l'aumentare del volume dei dati, è necessario aumentare proporzionalmente il parallelismo di Spark. In generale, il parallelismo richiesto cresce più rapidamente del volume.

Se si verificano errori di esecuzione dovuti a OutOfMemory errori, modificare la configurazione per ottenere un parallelismo Spark più elevato o un overhead di memoria più elevato. Il sovraccarico di memoria è definito dal spark.kubernetes.memoryOverheadFactor parametro nella mdm_matching sezione del CR IBM Master Data Management .

A volumi più elevati, potrebbe essere necessaria una maggiore capacità di archiviazione temporanea per gli executor e i driver Spark. Un'altra opzione è quella di mantenere illimitato lo spazio di archiviazione temporaneo non specificando alcun limite. Ad esempio, per un volume di 10 milioni di record, aggiungere 20 Gi di spazio di archiviazione temporaneo. Ad esempio:

spark_driver:
    containers:
    - resources:
        limits:
          ephemeral-storage: 20Gi
        requests:
          ephemeral-storage: 20Gi
    tolerations:
    - effect: NoSchedule
      key: cp4dmdm
      operator: Equal
      value: "true"
  spark_executor:
    containers:
    - resources:
        limits:
          ephemeral-storage: 20Gi
        requests:
          ephemeral-storage: 20Gi

Ottimizza il servizio per la sincronizzazione in blocco o i processi di esportazione

A seconda del volume dei dati sincronizzati o esportati, potrebbe essere necessario regolare il parallelismo di Spark. Un parallelismo Spark pari a 100 dovrebbe essere sufficiente per 10 milioni di record, ipotizzando una memoria di esecuzione pari a 6 GB. Con qualsiasi aumento di volume, il parallelismo Spark deve essere aumentato in modo proporzionale.

Ottimizza le API REST di runtime

Per operazioni altamente concorrenti che mirano a più di 300 transazioni al secondo (TPS), potrebbe essere necessario aggiungere ulteriori Nginx pod modificando il IBM Software Hubzenservices CR. Esegui il comando oc edit zenservices per modificare la configurazione del spec:Nginx:replicas parametro.

Ottimizza il Neo4j database

Con un database Neo4J grafico, la partizione dati (/data) contiene la maggior parte dei contenuti. Per evitare potenziali problemi, è necessario dimensionare adeguatamente la partizione dati, a seconda del volume dei dati. Come best practice, i log delle transazioni dovrebbero essere archiviati in una partizione diversa (/transactions). La dimensione di una partizione può solo essere aumentata. Non può essere ridotto.

I requisiti di memoria del database dipendono dal volume dei dati archiviati ed elaborati. Una cache di pagina di dimensioni maggiori può contribuire a ridurre le operazioni di I/O fisiche, migliorando così le prestazioni.