Eine Kategorie von Abfragen mit limit ist schneller und verbraucht weniger Datenverkehr, da die angeforderte Anzahl von Zeilen an die Plattform übergeben wird, anstatt erst im Nachhinein angewendet zu werden (serverseitige Filterung). Abfragen müssen nicht angepasst werden; die Verbesserungen werden sofort aktiv.
Kleinere Abfrage; höhere Leistung
Das Datenvolumen wird erheblich verbessert, indem weniger Zeilen abgerufen werden, und oft ist die Dauer auch signifikant besser im Vergleich zu Release 26.0. Die Anzahl der Zeilen wird in die Abfrage eingebunden, die die Plattform erhält.
Eine relationale Datenbank erhält das Filter als Bestandteil der Anweisung (je nach Plattform als limit, fetch first oder top (n)). Eine API erhält es als Bestandteil der Anfrage, beispielsweise als $top. Die Zeilen, die damit wegfallen, werden von der Plattform nicht erstellt, nicht versendet und nicht gelesen.
Bei GLAccounts von Exact Online holt limit 3 pro Bericht 4.670 Bytes in 297 ms ab, im Vergleich zu 92.940 Bytes und 1.356 ms ohne diese Einschränkung, und es gibt keine zweite Seite mehr im Vergleich zu zuvor 4 API-Aufrufen:
select *
from ExactOnlineREST..GLAccounts@eol
limit 3
Bei einer PostgreSQL-Tabelle mit 1,7 Millionen Zeilen sinkt das Volumen ebenfalls entsprechend, und auch die Ausführungsdauer sinkt von 87 Sekunden auf 125 Millisekunden:
select *
from table@postgresql
limit 3
Erster Eindruck einer *Incremental-Tabelle von Exact Online
Die Abfrage eines Eindrucks einer inkrementellen Tabelle (*Incremental), indem die ersten paar hundert oder tausend Zeilen angefordert werden, wird bis zu tausendmal schneller. Dies ist ein häufiges Szenario bei der ersten Verwendung, beispielsweise mit dem Navigator in Power Query und Power BI.
Das Ermitteln der ersten Zeile einer inkrementellen Tabelle wie TransactionLinesIncremental ist aufwendig: Der gesamte Datensatz muss dazu abgerufen und aktualisiert werden. Bei einem limit von maximal 2.500 Zeilen werden die Zeilen jetzt direkt vom Synchronisationsendpunkt abgerufen. Das kostet pro Bericht einen Aufruf pro 1.000 angeforderte Zeilen und dauert nur einige Sekunden, anstatt dass der vollständige Bericht zunächst abgerufen wird.
Bei einer TransactionLinesIncremental-Tabelle mit 650 Tausend Zeilen, verteilt auf 5 Parteien, sinkt die Ausführung, falls die Caches noch nicht geladen sind, von 867 auf 2 Sekunden:
select *
from TransactionLinesIncremental@eol
limit 1000
Wann der Filter innerhalb von Invantive UniversalSQL bleibt
Werden die Zeilen benötigt, bevor die Einschränkung angewendet werden kann, wendet Invantive UniversalSQL die Einschränkung an, nachdem die Zeilen eingegangen sind. Das geschieht unter anderem beim Sortieren nach einer Spalte, auf der die Plattform nicht sortieren kann, bei einer Bedingung, die die Plattform nicht selbst berechnen kann, und bei einer Datensammlung, die später in der Abfrage noch kombiniert wird.
Verfügbarkeit
Die neue Funktionalität ist ab Release 27.0 verfügbar.