MySQL - Wo finde ich Metriken zur Leistung von Blob im Vergleich zum Dateisystem?

Ich weiß und verstehe, dass es Leistungseinbußen beim Speichern von Blob-Daten in der Datenbank gibt, aber der Blob-Teil der Daten wird selten abgerufen / angezeigt, sondern für kleinere Daten (die überwiegende Mehrheit unter 256 KB mit maximal 10 MB). wird es von den meisten Kunden nicht verwendet, und die Gesamtzahl der Zeilen wird voraussichtlich relativ niedrig sein, sehr wahrscheinlich unter einer halben Million, wenn nicht weniger. Außerdem sind einige Daten dynamisch und können sich für einige Benutzer ändern, da es sich nicht um statische Bilder handelt. Mit anderen Worten, wir sind am Rande der Frage, ob es sich lohnt oder nicht.

Ich lese immer wieder, dass es besser ist, im Dateisystem zu speichern, aber ich kann keine tatsächlichen Metriken finden, die den Leistungsunterschied anzeigen, sondern nur Leute, die sich ohne konkrete Beweise oder Metriken wiederholen. Für uns ist es möglicherweise die Leistungskosten wert, wenn Sie vollständig ACID sind und sicherstellen, dass alle unsere Backups vollständig synchronisiert sind.

Davon abgesehen kennt oder hat jemand Metriken aus der realen Welt, um den Leistungsunterschied zwischen dem Speichern von Elementen als Blobs und im Dateisystem anzuzeigen. Ich versuche zu verstehen, ob sich die Leistungsstrafe lohnt oder nicht, anstatt blind der allgemeinen Faustregel zu folgen und nachdem ich mindestens 2-3 Stunden verbracht habe und ich noch nicht in der Lage bin, jemanden zu sehen, der tatsächliche Zahlen zeigt. Es sind alles nur Worte mit nichts Konkretem.

Dies ist übrigens eine MySQL InnoDB-Tabelle. Die eigentliche Datentabelle verfügt über einen Link zur Blob-Datentabelle, sodass der Blob nicht in der Hauptdatei enthalten ist und nur bei Bedarf abgerufen wird, um E / A-Probleme zu vermeiden. Mit anderen Worten, anstelle des Pfads zu den Daten im Dateisystem handelt es sich um eine ID für eine andere Tabelle mit nur Blobs. Wie ist das in Bezug auf die Leistung zu vergleichen? Ist es 25% schlimmer? Ist es 100%? Ist es 200-500%? Ist es 1000%?

Wenn die Kosten nur 100% -200% betragen, lohnt es sich wahrscheinlich für uns, da die Daten wiederum selten abgerufen werden. Selbst wenn wir 10.000 gleichzeitige Benutzer sagen würden, würden vielleicht nur 50 Benutzer ihre Blob-Daten bestenfalls gleichzeitig abrufen. Ja, die Daten sind für jeden Benutzer spezifisch, es sind keine Bilder.

Die Hauptkosten für die Verarbeitung der Daten sind die E / A. Sie führen ungefähr die gleiche Menge an E / A aus, unabhängig davon, ob es sich um 4-KB-Blöcke im Betriebssystem (plus Verzeichnisüberquerung) oder um 16-KB-Blöcke in InnoDB (plus indirekte Blocksuche) handelt.

Das Dateisystem und InnoDB werden auf radikal unterschiedliche Weise zwischengespeichert. Dies kann zu einem Unterschied führen - je nachdem, wie zwischenspeicherbar die Blogs sind.

Sie sagen "selten abgerufen". Warum ist Geschwindigkeit wichtig?

Ich bezweifle also, dass es einen Unterschied von mehr als 25% geben wird. Und ich kann nicht vorhersagen, was schneller sein wird.

Auch beim Weltraum gibt es einige Unterschiede, so dass es schwer vorherzusagen ist, welche enger sind. In jedem Fall darf der Unterschied für die von Ihnen erwähnten Größen-Blobs nicht mehr als etwa 2% betragen.

Wie komprimierbar sind die Blobs? (Die meisten Bildformate sind bereits komprimiert; Text ist normalerweise 3: 1 komprimierbar.) Wenn komprimierbar, tun Sie dies im Client . (Die integrierte optionale Komprimierung von InnoDB ist einfacher, aber nicht so gut.)

Und ja, es ist oft besser, es in einer "parallelen Tabelle" zu haben (wie Sie erwähnt haben).

Ein weiterer Punkt - Wenn der Blob ein Bild ist, das für eine Webseite bestimmt ist, ist es effizienter, es einfach in einer Datei zu haben und zu sagen <img srg=file-path>. Wenn es sich in einer Tabelle befindet BLOB, müssen Sie zusätzliche Arbeit leisten, um es an die Webseite weiterzugeben. Da E / A der Hauptunterschied ist, kann ich erwarten, dass das img-Tag 2x schneller ist.

Das größte Problem, was passiert, wenn BLOB in db gespeichert wird - Es fragt wie folgt ab:

SELECT * FROM blob_table WHERE range

Selbst wenn es nach WHERE nur wenige Zeilen zurückgibt, arbeitet der Server jedoch mit einer riesigen Datengröße.

Lösung - geteilte Tabelle für:

• PK und am häufigsten durchsuchbare Spalten
• Tabelle mit BLOB- und FK-Spalten

oder einfach alle Anfragen richtig behandeln:

In die Spaltenliste nur die wirklich notwendige Spalte aufnehmen, BLOB-Daten nach einer zweiten Anforderung mit Zugriff durch PK anfordern

übrigens zweitgrößtes Problem hinzufügen, wenn BLOB in db gespeichert -

• Dump vergrößern
• und (wirklich der gleiche Grund) - Erhöhen Sie die Betriebszeit wie Tabelle optimieren

Dies ist übrigens eine MySQL InnoDB-Tabelle. Die eigentliche Datentabelle verfügt über einen Link zur Blob-Datentabelle, sodass der Blob nicht in der Hauptdatei enthalten ist und nur bei Bedarf abgerufen wird, um E / A-Probleme zu vermeiden. Mit anderen Worten, anstelle des Pfads zu den Daten im Dateisystem handelt es sich um eine ID für eine andere Tabelle mit nur Blobs. Wie ist das in Bezug auf die Leistung zu vergleichen? Ist es 25% schlimmer? Ist es 100%? Ist es 200-500%? Ist es 1000%?

• Aus Sicht des Programmierers kann es 100.000.000 Prozent schlimmer sein. Oder sogar eine Milliarde Mal so schlimm. Blobs geben keine Dateihandles zurück. Dies ist eine bevorstehende Funktion der BLOB Locator-API . Das heißt, Sie haben keine Fähigkeit dazu seek. PostgreSQL bietet bytea (das Äquivalent von blob ) und large_objects : Der large_objectTyp befindet sich in der Nähe der Locator-API. Das Fehlen des tatsächlichen Abrufs eines Dateihandles macht das Arbeiten mit einer serverseitigen API oder das Erstellen eines Frontends zu einer Menge Spaß! Stellen Sie sich HTTP vor, bei dem für jede teilweise Download-Anforderung vom Client ein vollständiger BLOB-Abruf vom Server erforderlich war - jetzt können Sie dies tun!

• Sie können nicht nur nicht suchen, sondern Sie können die ungepufferten Blobs nicht über die Clientbibliothek in C aus den Dokumenten empfangen

  Der Kommunikationspuffer muss groß genug sein, um eine einzelne SQL-Anweisung (für Client-zu-Server-Verkehr) und eine Zeile zurückgegebener Daten (für Server-zu-Client-Verkehr) zu enthalten. Der Kommunikationspuffer jeder Sitzung wird dynamisch vergrößert, um alle Abfragen oder Zeilen bis zur maximalen Grenze zu verarbeiten. Zum Beispiel, wenn Sie BLOB - Werte haben, die 16 MB Daten enthalten, müssen Sie eine Kommunikationspuffergrenze von mindestens 16 MB haben (in beiden Server und Client). Das in die Clientbibliothek integrierte Standardmaximum beträgt 1 GB, das Standardmaximum auf dem Server jedoch 1 MB. Sie können dies erhöhen, indem Sie den Wert des Parameters max_allowed_packet beim Serverstart ändern. Siehe auch Abschnitt 5.1.1, „Konfigurieren des Servers“.

  Auch aus den Dokumenten,

  max_allowed_packetSie müssen diesen Wert erhöhen, wenn Sie große BLOB-Spalten oder lange Zeichenfolgen verwenden. Es sollte so groß sein wie das größte BLOB, das Sie verwenden möchten. Das Protokolllimit für max_allowed_packet beträgt 1 GB. Der Wert sollte ein Vielfaches von 1024 sein. Nichtmultiplikatoren werden auf das nächste Vielfache abgerundet.

• Außerdem kann der Server allgemeine Speicherrichtlinien auf den Blob unter der Haube anwenden, einschließlich Komprimierungsaufwand.

• Sie sagen auch, dass die Daten dynamisch sind. Sie bestätigen, dass es ACID-konform ist. Verstehst du, wenn sich dieser Blob ändert, wirst du die gesamte Zeile neu schreiben? Der Prozess der Zeilengenerierung und des Schreibens der Nicht-Blob-Komponenten auf den Heap ist nicht kostenlos und sollte als Overhead angesehen werden, wenn Sie nur den Blob aktualisieren müssen.

Also ja, es gibt viele Gemeinkosten und Nachteile. Als allgemeine Praxis schlage ich dies niemals vor.