MySql: tabelle komplett im RAM halten?

[nerd]

hallo,

gibt es in mysql einen tabletype oder eine option um eine tabelle immer komplett im ram zu halten oder komplett zu cachen? ich weiss das es 'MEMORY' als tabletype gibt, aber damit waere die db ja nach einem serverreboot wieder weg.
die tabelle ist teil der navigation und wird bei jedem seitenaufruf mindestens einmal abgefragt, und fast alle joins greifen darauf zurueck. auf der platte belegt der table inklusive index etwa 1MB bei ~6000 rows; wenn das projekt live geht wird die tabelle wahrscheinlich 2-3x groesser werden.

jemand ne idee?

[kostaki]

Bei den Größen sehe ich da keine Probleme auch ohne die komplette Tabelle im Speicher zu haben. So lange der Index im Speicher ist, sollte es ohne Probleme und sehr schnell funktionieren.

Ansonsten würde ich eine MEMORY Table benutzen und diese wenn sie leer ist aus der wirklichen Tabelle füllen. Dann kann man beim erweitern der Tabelle die MEMORY Tabelle und die normale Tabelle erweitern. Muss man natürlich vor jedem Query überprüfen ob die Tabelle leer ist.

Kommt auf die Anwendung an, aber es könnte Sinn machen die fertigen Ergebnisse in einem gesonderten Cache zu speichern (memcached) um den MySQL Server zu entlasten.

[Anonymous]

Muss man natürlich vor jedem Query überprüfen ob die Tabelle leer ist.

Nö... ich würde erstmal davon ausgehen das sie vorhanden und gefüllt ist, und den SELECT darauf absenden... erst wenn es hier einen DB Fehler gibt oder das Ergebnis leer ist würde ich prüfen ob die DB vorhanden und gefüllt ist und ggf. erstellen und füllen...

so dauert es beim ersten Aufruf nach Serverstart ggf. ein paar millisekunden länger, aber du sparst bei allen folgenden QUerys die vorherige Überprüfung und somit ein paar ms... und vor allem sparst du im Grunde unnötige DB Abfragen zur Prüfung ob die DB gefüllt ist...

bei einigen Projekten habe ich auch Einträge die entweder hochgezählt oder falls noch nicht vorhanden eben erstellt werden... also sende ich als erstes ein UPDATE, und erst wenn dies zurückliefert das kein Datensatz betroffen war wird ein INSERT ausgeführt... so komme ich in den meisten Fällen mit dem UPDATE aus... wenn ich jetzt jedesmal vorher prüfen würde ob ein Eintrag besteht, hätte ich also in etwa die doppelte Anzahl an DB Zugriffen und somit die doppelte Belastung des DB Servers...

[kostaki]

bei einigen Projekten habe ich auch Einträge die entweder hochgezählt oder falls noch nicht vorhanden eben erstellt werden... also sende ich als erstes ein UPDATE, und erst wenn dies zurückliefert das kein Datensatz betroffen war wird ein INSERT ausgeführt... so komme ich in den meisten Fällen mit dem UPDATE aus... wenn ich jetzt jedesmal vorher prüfen würde ob ein Eintrag besteht, hätte ich also in etwa die doppelte Anzahl an DB Zugriffen und somit die doppelte Belastung des DB Servers...

So etwas ähnliches benutze ich auch um select->insert/update Strukturen zu verhindern. Ich nehme nur kein update->insert, sondern ein insert on duplicate key update. Damit braucht man nur noch den insert und nichts anderes. https://dev.mysql.com/doc/refman/5.0/en ... icate.html

[Anonymous]

cool... den muss ich mir merken....

[Airport1]

artverwandt ist REPLACE , den musst dir au merke(l)n..
https://dev.mysql.com/doc/refman/5.0/en/replace.html

[everflux]

Brauchst Du es denn nur zum Lesen oder musst du da auch reinschreiben?

Wenn Du eh nur liesst, dann speicher dir das Ergebnis einfach in einer Datei ab und erneuere diese alle x Minuten wenn erforderlich (das war oben im Beitrag von konstaki "caching" gemeint)

Wenn Du mit englisch kein Problem hast: https://blog.digitalstruct.com/2008/02/ ... echniques/
Da werden die verschiedensten Ansaetze zum Cachen/Beschleunigen ganz gut erklaert. Ich denke in deinem Fall wuerde ein "partial page cache" schon ne Menge bringen.

[kostaki]

Ein REPLACE macht einen INSERT + DELETE + INSERT. INSERT ON DUPLICATE KEY UPDATE macht nur ein INSERT + UPDATE.

[profo]

gibt es in mysql einen tabletype oder eine option um eine tabelle immer komplett im ram zu halten oder komplett zu cachen? ... auf der platte belegt der table inklusive index etwa 1MB bei ~6000 rows; wenn das projekt live geht wird die tabelle wahrscheinlich 2-3x groesser werden.

Indizes behält MySQL automatisch im Ram, solange wie möglich. Wenn Du also jeder Spalte Deiner kleinen Tabelle einen Index gibst, sollte einfach die gesamte Tabelle im Ram bleiben, schätze ich. Ggf. kannst Du noch in der Mysql-Config die key_buffer vergrößern (a la key_buffer = 256M).

[800XE]

Ein REPLACE macht einen INSERT + DELETE + INSERT. INSERT ON DUPLICATE KEY UPDATE macht nur ein INSERT + UPDATE.

--------- "macht nur ein" -------- ist falsch
weil das sagt, da eines weniger macht als das andere,
aber beide das selbe machen
Die Beiden machen aber grundlegend unterschiedliche Dinge
( wobei natürlich bei beiden, zumindest manchmal, ein INSERT dabei ist )

--------- "INSERT + UPDATE" ----------- ist falsch
INSERT ON DUPLICATE .....
... macht ein UPDATE wenn möglich
... wenn nicht möglich, wierd ein INSERT gemacht


ein REPALCE macht ein INSERT .... auch wenn ein INSERT eigentlich, wegen kolision mit einem uniquen index, nicht funktionieren würde

[800XE]

--------- "INSERT + UPDATE" ----------- ist falsch
INSERT ON DUPLICATE .....
... macht ein UPDATE wenn möglich
... wenn nicht möglich, wierd ein INSERT gemacht

z.B. Foren PN

User meldet sich an ... und der PNcounter wird noch nicht eingetragen
beim Verschicken wird der Counter hochgezählt
1000 User mit durchschnittlich 10 PN
= das hochzählen geschiet 10mal Heufiger wie das initialiesieren

=
INSERT .......
UPDATE ON DUPLICATE .....


INSERT ist in Query der 1. Befehl
UPDATE ist der 2. Befehl
Es ist aber dafon auszugehen das in den meisten Fällen eigentlich der 2.Befehl der "Hauptbefehl" ist ..... und der Konstrukt dafür da ist um sicherzustellen das Befehl2 überhaupt funktioniert

[seonewbie]

Das ist keine Frage die man so einfach beantworten kann.

Verwendest Du MyISAM oder InnoDB?
E.v.t. solltest Du auf InnoDB umstellen.

1.) BLOB Colums können mit InnoDB nicht gecached werden
2.) TEXT Columns können mit InnoDB nicht gecached werden

Eigentlich möchtest Du aber das deine MySQL anfragen schnell
beantwortet werden.

Installiere dir tuning-primer.sh und mysqltuner.pl.

https://www.day32.com/MySQL/
https://blog.mysqltuner.com/

So kannst Du deinen SQL sauber tunen.
Aber auch deine Apache und PHP Einstellungen müssen zusammen passen.

Infos:
https://serversupportforum.de/forum/sql ... cript.html

https://www.huschi.net/12_302_de.html
https://www.huschi.net/10_54_de.html
https://www.huschi.net/17_137_de.html?highlight=tuning
https://www.huschi.net/10_299_de.html?highlight=tuning

So wenn Du das durch hast sollten dein Server laufen wie Schmitz Katz

Wenns gar nicht geht Hushi kann man buchen:
https://www.consult-n.de/server/huschi.html

Gruß

Micha

[seonewbie]

Wenn das alles nichts bringt's bringt memcache!
https://memcached.org/

Da mußt Du zwar ein bisschen umstricken aber
da für wird wirklich alles gecached so wie Du es
in deiner Frage eigentlich wolltest.

Harun hat ein schönes http Frontend geschrieben:
https://www.phpdeveloper.org/news/10247

Gruß

Micha

[nerd]

Verwendest Du MyISAM oder InnoDB?
E.v.t. solltest Du auf InnoDB umstellen.

1.) BLOB Colums können mit InnoDB nicht gecached werden
2.) TEXT Columns können mit InnoDB nicht gecached werden

die tabellen sind alle MyISAM (soll wohl beim lesen einen tick schneller sein, und inserts gibts in der tabelle ~2 stueck pro woche) , 2 textfelder, 4 int und 2 dezimal. Mit den meisten plugins und extentions hier kann ich wahrscheinlich nix anfangen da das projekt im moment noch auf einer shared hosting plattform laeuft.

[profo]

Versuch's wie gesagt mit dem Index auf jeder Spalte, das müsste gehen.