Killen viele BLOB-Felder die DB-Performance?

[Gecko]

Killen viele BLOB-Felder die DB-Performance? Das ist die Frage!
Worum gehts genau? Es soll ein Mail-Client entwickelt werden, der die Datensätze in einer Firebird DB speichert.

Die Frage ist nun:
Die Anhänge auf der Platte ablegen und in der DB nur den Dateinamen indexieren, oder alle per BLOB in die DB packen?
Habe gehört das zuviele BLOBS nicht so bekömmlich sein sollen.

[mkinzler]

Es kommt auf die Datenmenge an, passen diese nicht mehr in die selbe Page, werden diese in einem anderen Bereich der DB gespeichert und in der Tabelle nur noch die Blob-ID. In diesem Fall ist kein negativer Effekt zu erwarten.

[Bernhard Geyer]

Zitat von Gecko:

Killen viele BLOB-Felder die DB-Performance? Das ist die Frage!

Kommt darauf an wie du auf die Blob-Felder zugreift. I.d.R. legt eine Datenbank Blobfelder in speziellen Bereichen/Dateien ab und nur verweise auf diese Blobs in der "Haupttabelle" so das diese den normalen Suchvorgang nicht bremsen. Auch sollten diese Blobs bei normalen Selects nicht sofort über die Leitung übertragen werden. Um ganz sicher zu sein solltest du entsprechende Selects aufbauen wo kein Blob-Felder vorhanden sind.

[Gecko]

Das sagt php.net:

MySQL kann BLOBs (binary large objects) nicht fragmentarisch bearbeiten, d.h. es ist nicht möglich, ein BLOB in kleinen Teilstücken aus der Datenbank zu holen oder den hinteren Teil eines BLOBs zu holen, ohne die Bytes davor zu lesen. Obendrein ist der Sendepuffer von MySQL für BLOBs begrenzt groß, sodass nicht beliebig große BLOBs in der Datenbank abgelegt werden können.

Viele Datenbanken werden sehr ineffizient, wenn vergleichsweise große BLOBs zusammen mit anderen, sehr kleinen Objekten in derselben Tabelle gespeichert werden oder wenn eine Tabellenzeile mehr als ein BLOB enthält.

Die Meinungen gehen also auseinander....

[Die Muhkuh]

Zitat von Gecko:

Die Meinungen gehen also auseinander....

Du redest aber von FireBird und php.net sagt etwas über MySQL aus. Wahrscheinlich wird es bei FireBird so sein, wie es die Vorredner sagen.

[mkinzler]

Zitat:

Wahrscheinlich wird es bei FireBird so sein, wie es die Vorredner sagen.

Ja den MySQL <> FireBird

[Die Muhkuh]

Zitat von mkinzler:

Zitat:

Wahrscheinlich wird es bei FireBird so sein, wie es die Vorredner sagen.

Ja den MySQL <> FireBird

Das ist logisch, mkinzler, aber ich kenne FireBird nicht, deswegen kann ich dazu nichts sagen und verwies auf die Vorredner

[mkinzler]

Ich wollte ja nur deine Aussage unterstreichen

[shmia]

Zitat von Gecko:

Killen viele BLOB-Felder die DB-Performance?

Das würde ich mit einem eindeutigen Ja beantworten.
Ich habe folgenden Test mit dem MS SQL Server 2000 durchgeführt:
Alle Daten einer Tabelle (~30 Felder) mit 50000 Records werden mit "Select * FROM Tabelle" abgerufen.
Dann habe ich zwei Blob-Felder eingefügt.
Fast alle Blob-Felder waren leer, ungefähr bei 10 Datensätzen waren kurze Inhalte eingetragen.
Zwischen den Testläufen wurde jeweils der gesamte Cache gelöscht.
Ergebnis: ca. 15% weniger Leistung.

Meine Erklärung:
ein Blob-Feld löst allein schon durch sein Vorhandensein zusätzliche Aktionen in der DB aus.
Vorallem werden Blob-Daten physikalisch auf anderen Seiten als die Tabelle gespeichert.
Daher ergeben sich zusätzliche Festplattenzugriffe.

Workaround:
Man speichert die Blobdaten nicht direkt in der Tabelle, sondern in einer eigenen Tabelle.
Dies erfordert einen zusätzlichen Primärschlüssel für die Blobtabelle und einen Fremdschlüssel (pro Blobfeld) für die Orginaltabelle. (Datentyp int32 verwenden!)
Falls man die Blob-Daten wirklich braucht, kann man gezielt nur Blobdaten für den aktuellen Datensatz abrufen.

[Elvis]

Zitat von shmia:

Meine Erklärung:
ein Blob-Feld löst allein schon durch sein Vorhandensein zusätzliche Aktionen in der DB aus.
Vorallem werden Blob-Daten physikalisch auf anderen Seiten als die Tabelle gespeichert.
Daher ergeben sich zusätzliche Festplattenzugriffe.

Betrifft den OP aber nicht, da er sich glücklicherweise nicht mit MSSQL rumärgern muss.
Wie bereits schon von anderen beschrieben, geht Firebird den Weg des gesunden Menschenverstandes und verwendet Lob locators.
Sind sogar cooler als bei Oracle implementiert (wie mkinzler auch schon schrieb ).

Zitat:

Workaround:
Man speichert die Blobdaten nicht direkt in der Tabelle, sondern in einer eigenen Tabelle.
Dies erfordert einen zusätzlichen Primärschlüssel für die Blobtabelle und einen Fremdschlüssel (pro Blobfeld) für die Orginaltabelle. (Datentyp int32 verwenden!)
Falls man die Blob-Daten wirklich braucht, kann man gezielt nur Blobdaten für den aktuellen Datensatz abrufen.

lol, und da sieht man wieder was passiert, wenn ein DBMS ein server-basiertes Access sein will. *g*
Lob locators sind nix weiter als Pointer auf den wirklichen Lob, der an einer anderen Stelle in der Datenbank liegt.
Das heißt man kann in Firebird (oder fast jedem anderen DBMS) auch in Tabellen mit Lobs wunderbar schnell suchen und sogar Daten ändern. Die Lobs kommen erst ins Spiel wenn man sie tatsächlich anfasst.
Also praktisch das was du da selbst basteln musstest.
FB geht sogar noch weiter und wird kleine Lob-werte direkt in den Record packen, wenn dieser dann immer noch in die angefangene Page passt.