Una categoria di query con limit è più veloce e consuma meno traffico dati, poiché il numero di righe richieste viene passato alla piattaforma anziché essere applicato in seguito (filtraggio lato server). Le query non necessitano di modifiche; i miglioramenti vengono attivati immediatamente.
Mancanza di pochi dati; prestazioni più elevate
Il volume dei dati viene notevolmente migliorato recuperando meno righe e, spesso, la durata è significativamente migliore rispetto alla versione 26.0. Il numero di righe è incluso nella richiesta inviata alla piattaforma.
Un database relazionale riceve il filtro come parte dell’istruzione (a seconda della piattaforma come limit, fetch first o top (n)). Un’API lo riceve come parte della richiesta, ad esempio come $top. Le righe che vengono omesse in questo modo non vengono elaborate dalla piattaforma, né trasmesse né lette.
Su GLAccounts di Exact Online, limit 3 per ciascuna amministrazione recupera 4.670 byte in 297 ms, rispetto ai 92.940 byte e 1.356 ms senza tale limitazione, e non vi è nessuna seconda pagina rispetto a 4 chiamate API precedenti:
select *
from ExactOnlineREST..GLAccounts@eol
limit 3
Su una tabella PostgreSQL con 1,7 milioni di righe, il volume scende proporzionalmente, e anche la durata dell’esecuzione scende da 87 secondi a 125 millisecondi:
select *
from tabel@postgresql
limit 3
Prima impressione della tabella *Incremental di Exact Online
Richiedere un’anteprima di una tabella incrementale (*Incremental) ottenendo le prime centinaia o migliaia di righe diventa migliaia di volte più veloce. Si tratta di uno scenario molto comune al primo utilizzo, ad esempio con Navigator in Power Query e Power BI.
Determinare la prima riga di una tabella incrementale come TransactionLinesIncremental è costoso: è necessario recuperare e aggiornare l’intero dataset. Con un limit di massimo 2.500 righe, le righe vengono ora recuperate direttamente dal punto di sincronizzazione. Ciò richiede una chiamata per amministrazione ogni 1.000 righe richieste e richiede alcuni secondi, anziché recuperare l’intera amministrazione in primo luogo.
Su una tabella TransactionLinesIncremental con 650 mila righe, distribuite tra 5 entità, il tempo di esecuzione scende da 867 a 2 secondi se le cache non sono ancora caricate:
select *
from TransactionLinesIncremental@eol
limit 1000
Quando il filtro rimane all’interno di Invantive UniversalSQL
Se le righe sono necessarie prima che la limitazione possa essere applicata, Invantive UniversalSQL applica la limitazione dopo che le righe sono state ricevute. Ciò accade, ad esempio, quando si ordina su una colonna su cui la piattaforma non può ordinare, quando c’è una condizione che la piattaforma non può calcolare da sola, o quando una raccolta di dati viene combinata ulteriormente nella query.
Disponibilità
La nuova funzionalità è disponibile a partire dalla versione 27.0.