Die maximale Hash-Standardgröße von UltraLite von 4 Byte wurde so gewählt, dass sie für die meisten Deployments geeignet ist. Sie können die Größe erhöhen, um mehr Daten zusammen mit der Zeilen-ID einzubeziehen. Diese Änderung kann jedoch die Größe des Indexes erhöhen und ihn zwischen mehreren Seiten fragmentieren. Diese Änderung könnte auch die Größe der Datenbank erhöhen. Die Auswirkung einer erhöhten Hash-Größe hängt von der Anzahl der Zeilen in der Tabelle ab. Wenn Sie z.B. nur ein paar Zeilen haben, passt ein großer Index-Hash-Schlüssel immer noch auf die Indexseite. In diesem Fall kommt es nicht zu einer Indexfragmentierung.
Um eine optimale Hash-Größe auszuwählen, sollten Sie den Datentyp, die Zeilendaten und die Datenbankgröße berücksichtigen (v.a. wenn eine Tabelle viele Zeilen enthält).
Die einzige Möglichkeit zu überprüfen, ob Sie eine optimale Hash-Größe gewählt haben, besteht darin, auf dem Zielgerät Benchmark-Tests mit der UltraLite-Clientanwendung auszuführen. Hier können Sie beobachten, wie verschiedene Hash-Größen die Anwendung und die Abfrageperformance sowie die Datenbankgröße beeinflussen.
Wenn Sie die Hash-Methode auf den gesamten Wert in einer Spalte anwenden wollen, müssen Sie die von den verschiedenen Datentypen erforderte Hash-Größe berücksichtigen, die in der folgenden Tabelle aufgelistet ist. UltraLite verwendet die maximale Hash-Größe nur dann, wenn dies wirklich erforderlich ist und die festgelegte maximale Hash-Größe nie überschritten wird. UltraLite verwendet immer eine kleinere Hash-Größe, wenn der Spaltentyp nicht den vollständigen oberen Byte-Grenzwert verwendet.
| Datentyp | Verwendete Byte, um die Hash-Methode auf den gesamten Wert anzuwenden |
|---|---|
| FLOAT, DOUBLE und REAL | Kein Hash-Wert |
| BIT und TINYINT | 1 |
| SMALL INT und SHORT | 2 |
| INTEGER, LONG und DATE | 4 |
| DATETIME, TIME, TIMESTAMP und BIG | 8 |
| CHAR und VARCHAR |
Um die Hash-Methode auf die gesamte Zeichenfolge anzuwenden, muss die maximale Hash-Größe in Byte mit der deklarierten Größe der Spalte übereinstimmen. Multiplizieren Sie in einer UTF-8-kodierten Datenbank immer die deklarierte Größe mit dem Faktor 2, jedoch nur bis zur maximal erlaubten Größe von 32 Byte. Wenn Sie z.B. eine Spalte in einer nicht UTF-8-kodierten Datenbank als VARCHAR(10) deklarieren, ist die erforderliche Größe 10 Byte. Wenn Sie dieselbe Spalte jedoch in einer UTF-8-kodierten Datenbank deklarieren, beträgt die Hash-Größe für die gesamte Zeichenfolge 20 Byte. |
| BINARY |
Die maximale Hash-Größe in Byte muss mit der deklarierten Größe der Spalte übereinstimmen. Wenn Sie z.B. eine Spalte als BINARY(30) deklarieren, ist die erforderliche Größe 30 Byte. |
| UUID | 16 |
Wenn Sie z.B. als maximale Hash-Größe 6 Byte für einen zweispaltigen zusammengesetzten Index festlegen, den Sie als INTEGER bzw. BINARY(20) deklariert haben, geschieht basierend auf den Größenanforderungen des Datentyps Folgendes:
Der gesamte Wert der Zeile in der INTEGER-Spalte erhält einen Hash-Wert und wird im Index gespeichert, da für INTEGER-Datentypen nur 4 Byte erforderlich sind.
Nur die ersten 2 Byte der BINARY-Spalte erhalten einen Hash-Wert und werden im Index gespeichert, da die ersten 4 Byte von der INTEGER-Spalte verwendet werden. Wenn die verbleibenden 2 Byte keinen ausreichenden Teil der BINARY-Spalte im Hash-Index speichern, erhöhen Sie die maximale Hash-Größe.
Die Zeilenwerte der Daten, die in der Datenbank gespeichert werden, beeinflussen ebenfalls die Effizienz eines Hash-Indexes.
Wenn Sie z.B. ein gemeinsames Präfix für Einträge einer bestimmten Spalte haben, kann der Hash ineffizient sein, wenn eine Größe gewählt wird, die nur die Präfixe einbezieht. In diesem Fall müssen Sie eine Größe wählen, die sicherstellt, dass mehr als das gemeinsame Präfix im Hash-Index gespeichert wird. Wenn das gemeinsame Präfix lang ist, empfiehlt es sich möglicherweise, überhaupt keinen Hash-Index für die Werte zu verwenden.
Wenn ein nicht eindeutiger Hash-Index viele doppelte Werte speichert und UltraLite nicht den gesamten Wert im Hash-Index halten kann, verbessert der Hash die Performance wahrscheinlich nicht.
Jede Indexseite hat einen gewissen festen Overhead, doch der Großteil des Platzes einer Seite wird von den tatsächlichen Indexeinträgen verwendet. Eine höhere Hash-Größe bedeutet, dass die einzelnen Indexeinträge größer sind, weshalb weniger Einträge auf eine Seite passen. Bei großen Tabellen verwenden Indizes mit großen Hash-Werten mehr Seiten als Indizes mit kleinen oder gar keinen Hash-Werten. Je mehr Seiten erforderlich sind, desto größer wird die Datenbank und desto geringer wird die Performance. Letzteres geschieht üblicherweise, weil der Cache nur eine bestimmte Anzahl von Seiten enthalten kann, sodass UltraLite Seiten ein- und ausgelagert.
Die folgende Tabelle enthält Annäherungswerte dafür, wie die Hash-Größe beeinflussen kann, wie viele Seiten zum Speichern von Daten in einem Index erforderlich sind:
| Tabelle | Seitengröße | Hash-Größe | Anzahl von Einträgen | Erforderliche Seiten |
|---|---|---|---|---|
| Tabelle A | 4 KByte | 0 | 1200 | 3 Seiten |
| Tabelle B | 4 KByte | 32 Byte | 116 | 3 Seiten |
| Tabelle C | 4 KByte | 32 Byte | 1200 Einträge | 11 Seiten |
| Kommentieren Sie diese Seite in DocCommentXchange. Senden Sie uns Feedback über diese Seite via E-Mail. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |