<< | IBExpert Glossar | >>

Blob - Binary Large OBject

Ein Blob ist ein Datentyp, der große, binäre Informationen (Binary Large OBject) enthält.

Blobs können binäre oder ASCII Informationen enthalten, beispielsweise, umfangreiche Textdateien, Dokumente zur Datenverarbeitung, CAD Programmdateien, Grafiken und Bilder, Videos, Musikdateien, etc.

Blobs werden als Tabellenspalten definiert. Ihre Speichergröße ist nahezu unbegrenzt, da sie über mehrere Seiten gespeichert werden können. Dies setzt allerdings voraus, das eine ausreichende Datenbankseitengröße festgelegt wurde. Beispielsweise kann bei einer 1K Seite der Blob nicht 0,5 GB überschreiten, bei einer 4K Seitengröße liegt die Obergrenze bei 8 GB.

Die Fähigkeit solche binären Daten in einer Datenbank zu speichern, bietet ein hohes Level an Datensicherheit, Daten-Backup, Versionsmanagement, Kategorisierung und Zugriffskontrolle.

Der Vorteil von Blobtextfeldern gegenüber VARCHAR-Feldern (e.g. VARCHAR (32000)) ist, dass ein Netzwerkprotokoll alle 32.000 VARCHAR-Zeichen bei einer ISDN-Verbindung überträgt (analoge Zeilen komprimieren die Daten bis zu einem gewissen Ausmaß). Mit einem Blobfeld wird nur die aktuelle Dateigröße übertragen. Obwohl - seit Borland InterBase^® Version 6.5/7 dieser Nachteil mit der Übertragung von VARCHAR-Datentypen gelöst wurde, d.h. in diesen neueren InterBase^® Versionen wird die volle Länge der VARCHAR-Felder nicht mehr jedesmal über das Netzwerk übertragen. Jedoch sind selbst hier Blobs immer noch effektiver, wenn mit großen Datenmengen gearbeitet wird.

Seit Firebird 2.1 können Text-Blobs als lange VARCHARs ausgegeben werden. Auf verschiedenen Levels der Evaluierung, behandelt die Firebird Maschine jetzt Text-Blobs, die innerhalb der 32,765-Byte-Größe sind, als wären sie VARCHARs. String-Funktionen, wie CAST, LOWER, UPPER, TRIM und SUBSTRING funktionieren in diesen Blobs genauso, wie Verknüpfung und Zuordnung von String-Typen. Sie können sogar mit CONTAINING und LIKE auf Blob-Inhalte zugreifen. ORDER BY sollte jedoch nicht in Blobs verwendet werden, da Blobfelder in der Reíhenfolge, wie sie erzeugt wurden angezeigt werden und nicht anhand des Inhalts sortiert werden. Weitere Information finden Sie in den Firebird 2.1 Release Notes.

Firebird/InterBase^® unterstützt schnelle und effiziente Algorithmen zum Lesen, Schreiben und Aktualisieren von Blobs. Der Benutzer kann die Blobverarbeitung mit Blobroutinen manipulieren - sogenannten Blobfiltern. Diese Filter sind ideale Werkzeuge für die Komprimierung und Übersetzung von Blobs, abhängig von den Anforderungen der Anwendung.

Blobs können im IBExpert DB Explorer oder im IBExpert SQL Editor definiert werden.

Blob-Definitionen umfassen den Subtype, die Segmentgröße und den Zeichensatz.

Wenn die Datenansicht (d.h. die Seiten Daten) im Tabelleneditor ausgewählt ist und die gezeigte Tabelle eine Blobspalte enthält, kann IBExpert den Blobinhalt eines ausgewählten Datensatzes als Text (auch als RTF), Hex, Bild und Webseite mit Hilfe des IBExpert Menüpunktes Nützliches / Blob Anzeige/Editor anzeigen.

Wenn Blobs in einer Datenbank verwendet werden, ist es wichtig die Datenbankseitengröße genau zu bedenken. Blobs werden als Teil einer Datenzeile erzeugt, aber da Blobs von unbgrenzter Länge sein könnten, wird tatsächlich nur die BlobID mit der Datenzeile gespeichert. Die Daten des Blobs werden separat auf speziellen Blobseiten anderswo in der Datenbank gespeichert.

Die BlobID ist ein 8 Byte-Wert der es Firebird/InterBase^® ermöglicht, einen Blob eindeutig zu identifizieren und zu lokalisieren. Die BlobIDs können entweder vorübergehend oder dauerhaft sein; ein temporärer Blob wurde erzeugt aber noch nicht als Teil einer Tabelle gespeichert, permanente Blobs wurden in einer Tabelle gespeichert. Die ersten 4 Bytes repräsentieren die Relations-ID des Blobs (wie Datenzeilen sind auch Blobs an eine Tabelle gebunden), die zweiten vier Bytes repräsentieren die ID des Blobs innerhalb der Tabelle. Für temporäre Blobs ist der Relations-Id-Teil auf 0 gesetzt.

Eine Blobseite speichert Daten für einen Blob. Für umfangreiche Blobs, kann die Blobseite eine Blob-Zeigerseite sein, d.h. als Speicher für Zeiger für andere Blobseiten verwendet werden. Für jeden erzeugten Blob wird ein Blobdatensatz definiert, der Blobdatensatz beinhaltet den Speicherort der Blobdaten und einige Informationen über den Blobinhalt, die für die Maschine nützlich sein können, wenn diese versucht den Blob abzurufen. Die Blobdaten könnten auf drei leicht unterschiedlichen Wegen gespeichert werden. Der Speichermechanismus wird durch die Größe des Blobs bestimmt und wird über seine Levelnummer (0,1,2) identifiziert. Alle Blobs werden zunächst als Level 0 erzeugt, werden aber auf Level 1 oder 2 übertragen, sobald sie größer werden.

Ein Level-0-Blob ist eine Blob, der auf dieselbe Seite passt, wie der Blobkopf-Datensatz für eine Seite von 4096 Bytes. Dies wäre ein Blob von ca. 4052 Bytes (page overhead - slot - blob record header).

Obwohl die Dokumentation besagt, dass die Segmentlänge keinen Einfluss auf die Leistung von Firebird/InterBase^® hat, kann die tatsächliche, physische Größe eines Blobs oder seiner Segmentlänge entscheidend sein, wenn man verucht die I/O Leistung eins Blobs zu erhöhen, besonders wenn Sie das Segmant (typischerweise) oder ein Blob auf eine Seite anpassen können.

Dies ist besonders dann wahr, wenn Sie planen, den Blob mit bestimmten Firebird/InterBase^® Blobaufrufen auf niedrigem Level zu manipulieren. Wenn ein Blob zu groß ist, um auf eine einzige Seite (Level 1) zu passen und die Daten auf ein oder mehreren Blobseiten gespeichert werden, dann wird die Anfangsseite des Blobdatensatzes als Vector für die Blobseitennummern genommen.

Ein Level-2-Blob entsteht, wenn die Anfangsseite des Blobdatensatzes nicht groß genug ist, um die Vectoren aller Blobdatenseitennummern zu beinalten. Dann wird Firebird/InterBase^® Blobzeigerseiten erzeugen, d.h. es kann vom ersten Blobkopf-Datensatz, der jetzt zu Blobdatenseiten zeigt, auf mehrere Vectorseiten zugegriffen werden.

Die maximale Größe in einem Level-2-Blob ist ein Produkt der maximalen Anzahl von Zeigerseiten, der Anzahl der Datenseiten pro Zeigerseite und dem verfügbaren Platz auf jeder Datenseite.

Max. Blobgröße:

• 1Kb Seitengröße => 64 Mb
• 2Kb Seitengröße => 512 Mb
• 4Kb Seitengröße => 4 Gb
• 8Kb Seitengröße => 32 Gb
• 16kb Seitengröße => Groß genug :-).

Wir möchten Paul Beach von IBPhoenix für die Erlaubnis danken, Auszüge aus seiner Session Using and Understanding Blobs, gehalten auf der European Firebird Conference 2003, zu veröffentlichen.

Segmentgröße

Segmentgrößen werden für Blobfelder festgelegt. Dies kann im Domäneneditor oder im Tabelleneditor (wird aus dem IBExpert DB Explorer gestartet) gemacht werden.

Eine Blobsegmentgröße kann definiert werden, um die Leistung bei der Ein- und Ausgabe von Blobdaten zu erhöhen. Dies sollte grob der Datentygröße entsprechen. Mit einem Memofeld, beispielsweise für kurze Beschreibungen, die jedoch in Einzelfällen erheblich länger sein können, könnte die Segmentlänge auf 100 Bytes definiert werden, wobei der Blobdatentyp in 100 Byte Blöcken verarbeitet wird.

Wenn Videos oder große Grafiken in Datenbanken verarbeitet werden, sollte eine große Segmentlänge gewählt werden. Die maximale Länge beträgt 65536 Bytes, da alle Blobinhalte in Blöcken gespeichert werden und über diese Blöcke geholt werden. Eine typische Segmentgröße aus der Vergangenheit ist 80 (da 80 Zeichen in eine Bildschirmzeile passen).

Wenn ein Blob extrahiert wird, liest der Firebird/InterBase^® Server die Anzahl der Segmente, die der Client angefragt hat. Da der Server immer komplette Blöcke aus der Datenbank wählt, kann dieser Wert eigentlich in modernen, leistungsfähigen Computern ignoreirt werden. 2048 wird als Standard seit der InterBase^® Version 6 empfohlen.

Subtype

Subtypes werden für Blobs definiert. Sie werden verwendet, um den Datentyp beim Definieren von Blobs zu kategorisieren. Ein Subtype ist ein positiver oder negativer numerischer Wert, der en Datentyp der Blobdaten anzeigt. Die folgenden Subtypes sind in Firebird/InterBase^® vordefiniert:

Blobfelder können im Domäneneditor oder im Tabelleneditor (wird aus dem IBExpert DB Explorer gestartet) definiert werden.

Die Sizeiikation eines benutzerdefinierten Blob-Subtypes hat keinen Einfluss auf Firebird/InterBase^®, da der Firebird/InterBase^® Server alle Blobfelder gleich behandelt, d.h. er speichert einfach die Daten und liefert sie auf Anfrage dem Clientprogramm.

Die Definitionen werden jedoch vom Clientprogramm benötigt, um den Blobinhalt korrekt anzeigen zu können. Zum Beispiel könnte SUB_TYPE -200 definiert werden als Subtype für GIF-Bilder und SUB_TYPE -201 als Subtype für JPG-Bilder.

Die Subtypedefinition ist optional; wenn hier nichts festgelegt ist geht Firebird/InterBase^® von 0 = binäre Daten aus.

Wie zuvor erwähnt, kann unter dem Menüpunkt Nützliches der IBExpert Blob Anzeige/Editor der Blobinhalt als Text, Hex, Bilder, RTF, Unicode und Webseite angeteigt werden.

Siehe auch:
deutschsprachig:
Blob-Filter
Blob Viewer/Editor
SQL Editor
englischsprachig:
BLOB data type
Descriptive identifiers for BLOB subtypes
InterBase^®, Firebird and Blobs - a technical overview
Blob filter sample code
Stream blobs
Selecting the right data type to improve database performance
Firebird 2.1 Language Reference Update
Firebird 2.0 Language Reference Update
SQL Language Reference
Firebird 2.1 Release Notes: Sorting on BLOB and ARRAY columns is restored

zurück zum Seitenanfang
<< | IBExpert Glossar | >>