MySQL-Datenbank-Strategie für sehr viele Datensätze mit großem Blob-Inhalt in base64

  • Thread starter Thread starter Deleted member 11691
  • Start date Start date
D

Deleted member 11691

Guest
Hallo,

ich suche derzeit nach einer Strategie, wie ich das MySQL-Backend für eine neue Version von dontrm.org aufbauen kann. Dabei ist der Hauptfaktor die Geschwindigkeit. Alleine, wenn man in der jetzigen Version von dontrm.org einen Datensatz selektiert ist dieser manchmal sehr schnell (0.3 Sekunden) und manchmal ist er so langsam, dass ich mir denke, ich hätte doch gleich die Daten auf die Festplatte schreiben können (20 Sekunden bis 2 Minuten). Ich habe mir gedacht, ich könnte doch 62 Tabellen benutzen und diese nach den jeweiligen Anfangsbuchstaben "table_<1. buchstabe>" der Paste-ID benennen, doch dann dachte ich mir, ob MySQL für alle Tabellen nicht eine Datei nutzt oder die auf verschiedene Dateien aufgeteilt sind oder ob das überhaupt einen sooo großen Unterschied macht... Was fällt euch dazu ein? Wie könnte ich soetwas überhaupt machen... Dabei geht es mir eher nur um die Geschwindigkeit der Datenbank... Soll ich diese eventuell auf verschiedene vServer auf dem gleichen Hostsystem hosten und per Anfangsbuchstabe der Paste-ID benennen?
 
Dabei geht es mir eher nur um die Geschwindigkeit der Datenbank... Soll ich diese eventuell auf verschiedene vServer auf dem gleichen Hostsystem hosten und per Anfangsbuchstabe der Paste-ID benennen?
Und was soll da Performance bringen? Das bringt eher Schneckentemp

Alleine, wenn man in der jetzigen Version von dontrm.org einen Datensatz selektiert ist dieser manchmal sehr schnell (0.3 Sekunden) und manchmal ist er so langsam
Wie werden die Daten angefordert, also wie sieht der Query ungefähr aus.
Schau dir zB Redis für eine Key-Value Datenbank an, alternativ gibt es zB auch Graph-DB's falls das deine Nutzungsszenarien abdeckt
 
Back
Top