Performance Optimierung: Hash ID Columns

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Performance Optimierung: Hash ID Columns

    Moin zusammen!

    ich hab eine Frage an die Datenbank Experten.

    Für ein anstehendes Projekt würde ich gerne Datenbank weit generierte Hexadezimale Hashes anstelle von Auto-Increment Integern verwenden. Das Generieren ist nicht das Problem, dies wird auf Seiten von PHP geschehen.
    Meine Frage zu dem Thema zielt in Richtung Performance. Ich möchte natürlich die Hashes nicht als CHAR oder VARCHAR speichern, weil die Indizierung etc. bei Char Feldern viel zu lahm ist. Deswegen möchte ich die Daten Binär speichern.

    Nun gibt es hier zwei Möglichkeiten. Als CHAR (32) BINARY oder als BINARY (32). Welches von den beiden ist performanter? Ich würde tendenziell gerne den Binary Char verwenden, da die IDs dann noch in der Datenbank lesbar sind und ich mir bei Ein- und Ausgabe die Casts sparen kann. Letzteres wäre mir sehr lieb, da ich dafür das Eloquent ORM von Laravel anpassen müsste und ich noch nicht genau weiß wie viele Stellen das betrifft.

    Habt ihr da Erfahrung mit oder relevante Links?

    Viele Grüße
    Bodo06

  • Ich möchte natürlich die Hashes nicht als CHAR oder VARCHAR speichern, weil die Indizierung etc. bei Char Feldern viel zu lahm ist.

    Hast du dazu ne Quelle? Dass VARCHAR dafür ungeeignet und ziemlich langsam ist seh ich ein, aber warum das auf ein CHAR mit fester Größe zutreffen sollte ist mir nicht ganz klar. Hab auf die Schnelle auch nichts dazu gefunden (außer dass man varchars als primary key vermeiden soll ;) ).

    Aber letztendlich machts natürlich Sinn, Hashes oder UUIDs (was eine häufige wahl für nen primary key ist) sind binäre Daten, also warum sollte man sie nicht auch als solche speichern ;)

    Von den Datentypen her geh ich mal davon aus, dass es um ne MySQL Datenbank geht. Da solltest du wissen, dass ein CHAR(32) BINARY ein ganz normales CHAR ist, nur dass es einen Zeichensatz für binäre Daten verwendet. Wenn du also auf CHAR verzichten willst, darfst du auch kein CHAR BINARY verwenden. (siehe dev.mysql.com/doc/refman/5.6/en/binary-varbinary.html)

    Wenn du BINARY verwenden willst, musst du die Datenumwandlung nicht unbedingt im PHP skript machen, das kann MySQL auch direkt. Mit UNHEX(str) machst du aus nem Hexstring einen binärstring und mit HEX() das ganze umgekehrt. (dev.mysql.com/doc/refman/5.6/e…nctions.html#function_hex)

    Edit: Achja, wenn du nach links zu dem Thema suchst, such einfach mal nach UUID als primary key, da gibt es genau diese Problematik auch und entsprechend viele Diskussionen zu dem Thema.

  • Moin!

    Erstmal vielen Dank für deine ausführliche Antwort!

    Ja, es geht um eine MySQL DB. Sorry, das hab ich vergessen dazuzuschreiben. ;)

    Hm, okay. Ich hatte die MySQL Hilfe und einige Tutorials zu dem Thema so verstanden, dass CHAR BINARY schneller als CHAR ist, weil zwar die Anzeige und Speicherung in CHAR erfolgt, aber die Indizierung und Schlüsselverknüpfung in BINARY passiert, was ja schon ein großer Unterschied wäre.

    Auf die UNHEX und HEX Funktionen bin ich bereits gekommen, allerdings müsste ich dafür trotzdem die Laravel Driver Klassen anpassen, damit sie diese Funktionen verwenden und das versuche ich zu vermeiden. Vermutlich führt da aber langfristig kein Weg vorbei x_X


    Grüße!
    Bodo06