Unterschiede zwischen Direct Discovery und im Speicher befindlichen Daten

In-Memory-Modell

Im QlikView In-Memory-Modell werden alle eindeutigen Werte in den aus einer Tabelle im Ladeskript ausgewählten Feldern in Feldstrukturen und die zugeordneten Daten gleichzeitig in die Tabelle geladen. Die Felddaten und die zugeordneten Daten bleiben alle im Speicher.

One table with three fields.

Eine zweite, betreffende Tabelle, die in den Speicher geladen wurde, würde ein gemeinsames Feld teilen und diese Tabelle könnte zum gemeinsamen Feld neue eindeutige Werte hinzufügen oder bestehende Werte teilen.

Two tables with a common field.

Direct Discovery

Wenn Tabellenfelder durch einen Direct DiscoveryLOAD-Befehl (Direct Query) geladen werden, wird eine ähnliche Tabelle nur mit den DIMENSION-Feldern erstellt. Wie bei den im Speicher befindlichen Feldern werden die eindeutigen Werte für die DIMENSION-Felder in den Speicher geladen. Aber die Verknüpfungen zwischen den Feldern werden in der Datenbank belassen.

One table with two dimension fields.

MEASURE-Feldwerte werden auch in der Datenbank belassen.

One table with measure field values left in the database.

Nachdem die Struktur von Direct Discovery festgelegt wurde, können Direct Discovery-Felder mit bestimmten Diagrammobjekten verwendet werden, auch für Verknüpfungen mit im Speicher befindlichen Feldern. Wenn ein Direct Discovery-Feld verwendet wird, erstellt QlikView automatisch die geeignete SQL-Abfrage für die externe Datenquelle. Bei Auswahlen werden die verknüpften Datenwerte der Direct Discovery-Felder in den WHERE-Bedingungen der Datenbankabfragen verwendet.

Für jede Auswahl werden die Diagramme mit Direct Discovery-Feldern neu berechnet, wobei die Berechnungen in der Tabelle der Quelldatenbank durch Ausführen der von QlikView erstellten SQL-Abfrage ablaufen. Sie können mit der Bedingung für die Berechnung angeben, wann Diagramme neu berechnet werden sollen. Solange die Bedingung nicht erfüllt wird, sendet QlikView keine Abfragen zur Neuberechnung der Diagramme.

Leistungsunterschiede zwischen im Speicher befindlichen und Direct Discovery-Feldern

Die Verarbeitung im Speicher ist stets schneller als in Quelldatenbanken. Die Leistung von Direct Discovery spiegelt die Leistung des Datenbanksystems wider, das die Direct Discovery-Abfragen verarbeitet.

Es ist möglich, eine Standarddatenbank und beste Praktiken zur Abfragenanpassung für Direct Discovery zu verwenden. Alle Leistungsanpassungen sollten in der Quelldatenbank erfolgen. Direct Discovery bietet aus dem QlikView-Dokument für die Leistungsanpassung bei Abfragen keine Unterstützung. Mithilfe der Verbindungspooling-Funktion ist es jedoch möglich, asynchrone, parallele Abrufe aus der Datenbank durchzuführen. Die Syntax des Ladeskripts zur Einrichtung der Pooling-Funktion ist:

SET DirectConnectionMax=10;

QlikView-Caching verbessert auch das gesamte Nutzererlebnis. Siehe Abbildung unten (Caching und Direct Discovery)

Die Leistung von Direct Discovery mit DIMENSION-Feldern kann ebenso durch Trennen der Verknüpfung einiger Felder verbessert werden. Dies wird mit dem Schlüsselwort DETACH in DIRECT QUERY vorgenommen. Während getrennte Felder nicht nach Verknüpfungen abgefragt werden, sind sie immer noch Bestandteil der Filter, wodurch sich Auswahlzeiten verkürzen.

Während im Speicher befindliche QlikView-Felder und Direct DiscoveryDIMENSION-Felder beide alle ihre Daten im Speicher halten, wirkt sich die Weise, wie sie geladen werden, auf die Ladegeschwindigkeit in den Speicher aus. Im Speicher befindliche QlikView-Felder speichern nur eine Kopie eines Feldwerts, wenn es mehrere Instanzen des gleichen Werts gibt. Jedoch werden alle Felddaten geladen und die duplizierten Daten dann aussortiert.

DIMENSION­Felder speichern auch nur eine Kopie eines Feldwerts, aber die duplizierten Werte werden in der Datenbank aussortiert, bevor sie in den Speicher geladen werden. Wenn Sie mit großen Datenmengen zu tun haben, wie gewöhnlich bei der Verwendung von Direct Discovery, werden die Daten durch eine DIRECT QUERY viel schneller geladen als durch das für im Speicher befindliche Felder SQL SELECT.

Unterschiede zwischen Daten im Speicher und Datenbankdaten

DIRECT QUERY berücksichtigt Groß- und Kleinschreibung, wenn Verknüpfungen mit im Speicher befindlichen Daten vorgenommen werden. Direct Discovery wählt Daten aus Quelldatenbanken in Übereinstimmung mit der Groß-/Kleinschreibung der abgefragten Datenbankfelder aus. Wenn bei den Datenbankfeldern die Groß-/Kleinschreibung nicht berücksichtigt wird, gibt eine Direct Discovery-Abfrage möglicherweise Daten zurück, die eine Abfrage im Speicher nicht ergeben würde. Zum Beispiel, wenn sich die folgenden Daten in einer Datenbank befinden, die nicht Case-sensitiv ist, ergäbe eine Direct Discovery-Abfrage des Werts "Red" alle vier Reihen.

ColumnA ColumnB
red one
Red two
rED three
RED four

Eine Auswahl von "Red," im Speicher ergäbe hingegen nur:

Red two

QlikView normalisiert Daten in einem Ausmaß, das Treffer zu ausgewählten Daten erzeugt, die Datenbanken nicht zuordnen würden. Als Folge kann eine Abfrage im Speicher mehr passende Werte ergeben als eine Direct Discovery-Abfrage. Zum Beispiel unterscheiden sich in der folgenden Tabelle die Werte für die Zahl "1" nach der Position der Leerzeichen um sie:

ColumnA ColumnB
' 1' space_before
'1' no_space
'1 ' space_after
'2' two

Wenn Sie "1" in einer Listbox für ColumnA auswählen, wo sich die Daten im standardmäßigen QlikView-Speicher befinden, werden die ersten drei Reihen zugeordnet:

' 1' space_before
'1' no_space
'1 ' space_after

Wenn die Listbox Direct Discovery-Daten enthält, verknüpft die Auswahl von "1" möglicherweise nur "no_space". Die sich für Direct Discovery-Daten ergebende Treffer hängen von der Datenbank ab. Manche geben nur "no_space" zurück, andere, wie SQL Server, geben "no_space" und "space_after" zurück.

Caching und Direct Discovery

QlikView-Caching speichert Auswahlstatus von Abfragen und zugeordnete Abfrageergebnisse im Speicher. Bei gleichen Arten von Auswahlen, verwendet QlikView die Abfrage aus dem Cache, anstatt die Quelldaten abzufragen. Wenn eine andere Auswahl getroffen wird, erfolgt eine SQL-Abfrage in der Datenquelle. Die gecachten Ergebnisse werden unter Benutzern geteilt.

Example:  

  1. Der Benutzer wendet die ursprüngliche Auswahl an.

    SQL wird an die zugrunde liegende Datenquelle weitergegeben.

  2. Der Benutzer löscht die Auswahl und wendet die gleiche Auswahl wie die ursprüngliche an.

    Das Cache-Ergebnis wird ausgegeben, SQL wird nicht an die zugrunde liegende Datenquelle weitergegeben.

  3. Der Benutzer wendet eine andere Auswahl an.

    SQL wird an die zugrunde liegende Datenquelle weitergegeben.

Beim Caching mit der DirectCacheSeconds-Systemvariable kann ein Zeitlimit festgesetzt werden. Sobald das Zeitlimit erreicht wird, löscht QlikView die Direct Discovery-Abfrageergebnisse aus dem Cache, die für frühere Auswahlen erzeugt wurden.QlikView fragt dann die Quelldaten nach den ausgewählten Optionen ab und erstellt den Cache für das festgelegte Zeitlimit neu.

Die Standard-Cachezeit für Direct Discovery-Abfrageergebnisse ist 30 Minuten, sofern die DirectCacheSeconds-Systemvariable verwendet wird.