Quando parliamo di gandi quantità di dati in Salesforce non necessariamente è un termine riferito al numero dei dati.
Possono essere decine di migliaia o centinaia di migliaia o milioni, ma possono anche essere dei dati che occupano invece tantissimo spazio su db e come numero di record possono anche essere inferiori.
Ad ogni modo questa guida parla di Big Objects.
Quindi un Big object è una tecnologia Salesforce che ci permette di immagazinare grosse quantità di dati o dati molto pesanti.
I Big Object lavorano bene sia con milioni, sia con bilioni di dati. Il loro utilizzo permette di migliorare le performance del sistema.
La documentazione indicata permette di aiutare lo sviluppatore a spostare i dati e gli oggetti di grosse dimensioni (sia custom che standard) in oggetti Big Objects.
Per un’approfondimento si rimanda anche ai seguenti link
https://developer.salesforce.com/page/Multi_Tenant_Architecture
https://developer.salesforce.com/docs/atlas.en-us.224.0.bigobjects.meta/bigobjects/big_object.htm
Concetto di Multitenancy
Quando si parla di Multitenancy si intende che in Salesforce non esistono progetti o compagnie di serie A o di serie B per cui ad alcuni viene data un’architettura differente dalle altre. Ma Macchine, Database e risorse sono tutte condivise e identiche e motivo per cui abbiamo i Governor Limit che impediscono di sviluppare il proprio progetto a danno delle performance del cloud e di conseguenza a discapito di tutti gli utenti collegati.
Quindi il Multitenancy richiede che le applicazioni siano tutte disegnate e realizzate secondo certi canoni e regole.
Note:
Dopo che è stato creato o aggiornato un record, potrebbero volerci anche fino a 15 minuti per indicizzare e ricercare il nuovo dato.
Skinny Tables
Sono tabelle più snelle che contengono i campi più utilizzati dall’utente sia per oggetti custom che standard. Il loro utilizzo è previa richiesta a Salesforce.
Questo genere di tabelle permette migliori performance di interrogazione al database. Grazie all’uso di queste tabelle non c’è bisogno di ricorrere alle join e questo performa il tutto.
Ecco un esempio di come una skinny table può accelerare le query. Invece di utilizzare un intervallo di date come 01/01/11 a 12/31/11 che
comporta un calcolo costoso e ripetuto per creare un rapporto annuale o da inizio anno: è possibile utilizzare una skinny table per includere un anno e per filtrare su di esso.
Nella documentazione indicata troviamo informazioni su query optimizer ovvero la tecnologia Salesforce che permette di utilizzare delle tabelle indici custom per filtrare delle limitate query.
Indici personalizzati a due colonne o Two-Column Custom Indexes
E’ possibile avere due campi indice dove uno serve per selezionare i record da mostrare e l’altro per l’ordinamento
Mashups
Permette di mostrare i dati Salesforce su sito esterno con la stessa UI di Salesforce. I mashups sono usati anche con le callout per interrogare sistemi esterni in tempo reale e scambiare “piccole” quantità di dati. Il vantaggio del mashup e che non c’è bisogno di codice proprietario per interfacciare sistemi diversi e i dati non sono mai obsoleti.
Di contro c’è che sono limitati (non è possibile fare report o workflow)
Defer Sharing Calculation
Se ne parla in questa guida e si tratta della sospensione di calcolo (momentanea) la dove per esempio si deve intervenire con le modifiche delle sharing rules e i dati nel db sono davvero tanti da rendere ingestibile la modifica dei ruoli in tempi più performanti
Cancellazione dei dati
La cancellazione dei dati non è quasi mai definitiva. I dati cancellati vengono salvati nel db ancora per 15 giorni, a meno che il “cestino” non raggiunga il limite massimo o non venga vuotato. In Bulk è possibile forzare la cancellazione a permanente.