Für die Speicherung von Datensätzen mit Unicode-Zeichen verwendet die 5.6 ein modifiziertes Datensatzformat. Als zusätzliches Feature reduziert das neue Format den Speicherverbrauch durch das Eliminieren von leeren Feldern in gepackten Sätzen.
Mit Hilfe einer kleinen Bit-Tabelle pro Teildatensatz können leere Felder beim Packen des Satzes einfach weggelassen werden. Der Mehrverbrauch von einem Bit pro Feld wird durch die Einsparung von Leerwerten weit mehr als aufgewogen. Bei einem leeren Gleitkomma- oder Integer64-Feld werden 8 Bytes gespart, leere Integer32-, Datums- oder Zeitfelder sparen 4 Bytes ein. Logische Felder brauchen in Zukunft nur noch ein Bit (das direkt in der Bit-Tabelle steht) anstelle von einem Byte.
Angesichts von Terabyte-Festplatten stellt sich natürlich die Frage, wozu eine solche Sparmaßnahme eigentlich gut sein soll. Die Antwort heißt Performance. Ein limitierender Faktor der Verarbeitungsgeschwindigkeit ist die I/O-Leistung, beim typischen Betrieb einer oder mehrerer Datenbank auf einem Server kann dieser nur eine bestimmte Maximalzahl von I/O-Operationen pro Sekunde erreichen.
Die I/O-Operationen verwenden eine feste Blockgröße, wodurch sich eine bestimmte Menge von Datensätzen pro I/O ergibt. Schrumpft die durchschnittliche Datensatzgröße jetzt beispielsweise um 20%, steigt die Anzahl von Datensätzen pro I/O um 25%, der Server kann also mehr Datensätze pro Sekunde verarbeiten.
Die folgende Beispielprozedur speichert alle Datensätze einer Datenbank im neuen Format:
main
LOCAL
{
tLoop : int32;
tFlags : int32;
}
{
for tLoop # 1
loop inc(tLoop)
while (tLoop < 1000)
{
if (FileInfo(tLoop,_FileExists) > 0 and
RecInfo(tLoop,_RecCount) > 0)
{
tFlags # _RecLock | _RecFirst;
while (RecRead(tLoop,1,tFlags) < _rNoRec)
{
tFlags # _RecLock | _RecNext;
RecReplace(tLoop,_RecUnlock);
}
}
}
}
4 Antworten
@Ralf
Die einfache Optimierung reicht aus, wenn größere Datenmengen gelöscht wurden. Ansonsten kann die Größe nur mit der erweiterten Optimierung verringert werden.
Siehe auch:
http://www.vectorsoft.de/Blog/2011/07/Optimierung-der-Datenbank
Erst bei einer erweiteten Optimierung Schrumpft die Hauptanteil der Datenbank. Bei einem Test einer Live Datenbank von 21 GB ca. um 7 GB, Schrumpft diese auf 14 GB. Ohne Optimierung betrug diese erst ca. 650 MB
@Andreas
Das ist richtig, eine Konvertierung der Datensätze ist nicht notwendig, die Version 5.6 kann das bisherige Format auch entpacken.
Wenn ich das richtig verstehe, findet keine automatische Konvertierung der Datensätze statt. Soll für bestehende Datensätze das neue Format verwendet werden, müssen diese gelesen und zurückgeschrieben werden.