Du befindest Dich im Archiv vom ABAKUS Online Marketing Forum. Hier kannst Du Dich für das Forum mit den aktuellen Beiträgen registrieren.

MySql: tabelle komplett im RAM halten?

Ajax, Hijax, Microformats, RDF, Markup, HTML, PHP, CSS, MySQL, htaccess, robots.txt, CGI, Java, Javascript usw.
nerd
PostRank 10
PostRank 10
Beiträge: 4023
Registriert: 15.02.2005, 04:02

Beitrag von nerd » 22.05.2010, 02:56

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?

Anzeige von ABAKUS

von Anzeige von ABAKUS »

SEO Consulting bei ABAKUS Internet Marketing
Erfahrung seit 2002
  • persönliche Betreuung
  • individuelle Beratung
  • kompetente Umsetzung

Jetzt anfragen: 0511 / 300325-0.


kostaki
PostRank 4
PostRank 4
Beiträge: 175
Registriert: 26.10.2009, 22:19
Wohnort: Berlin

Beitrag von kostaki » 22.05.2010, 10:28

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

Beitrag von Anonymous » 22.05.2010, 12:38

kostaki hat geschrieben: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
PostRank 4
PostRank 4
Beiträge: 175
Registriert: 26.10.2009, 22:19
Wohnort: Berlin

Beitrag von kostaki » 22.05.2010, 14:04

net(t)worker hat geschrieben: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

Beitrag von Anonymous » 22.05.2010, 14:12

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

Airport1
PostRank 10
PostRank 10
Beiträge: 4489
Registriert: 16.08.2004, 18:50
Wohnort: Backnang / bei Stuttgart

Beitrag von Airport1 » 22.05.2010, 14:20

artverwandt ist REPLACE , den musst dir au merke(l)n..
https://dev.mysql.com/doc/refman/5.0/en/replace.html
Linktauschanfragen zwecklos
https://www.bot-trap.de/ Spamschutz fuer Webmaster - zentrale Meldestelle fuer Web Spam
https://www.airport1.de/blog/ Lombagruschd Blog mid Gardadierle
https://www.ranking-hits.de/ Counter & PR Service

everflux
PostRank 8
PostRank 8
Beiträge: 939
Registriert: 01.05.2006, 17:15

Beitrag von everflux » 22.05.2010, 15:06

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.
https://everflux.de/ blogging about life, programming, seo and the net

kostaki
PostRank 4
PostRank 4
Beiträge: 175
Registriert: 26.10.2009, 22:19
Wohnort: Berlin

Beitrag von kostaki » 22.05.2010, 15:14

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

profo
PostRank 9
PostRank 9
Beiträge: 1703
Registriert: 18.01.2007, 18:51

Beitrag von profo » 22.05.2010, 15:24

nerd hat geschrieben: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
PostRank 10
PostRank 10
Beiträge: 5223
Registriert: 02.12.2004, 03:03

Beitrag von 800XE » 22.05.2010, 21:47

kostaki hat geschrieben: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
PostRank 10
PostRank 10
Beiträge: 5223
Registriert: 02.12.2004, 03:03

Beitrag von 800XE » 22.05.2010, 21:52

800XE hat geschrieben:--------- "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
PostRank 9
PostRank 9
Beiträge: 1939
Registriert: 21.10.2006, 20:50

Beitrag von seonewbie » 23.05.2010, 00:05

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
Zuletzt geändert von seonewbie am 23.05.2010, 00:12, insgesamt 1-mal geändert.
Suche Linktausch zum Thema Mode. Bitte PM
Backlink-Generator | Artikelverzeichnis | PageRank | SEnuke X
Don't smoke, don't fight, don't light no cigarettes,
Or else you'll wind up in the can!
No jokes, no rights, sit tight, don't fool around,
You are a guest of Uncle Sam!
AC/DC "I'll be damned"

seonewbie
PostRank 9
PostRank 9
Beiträge: 1939
Registriert: 21.10.2006, 20:50

Beitrag von seonewbie » 23.05.2010, 00:11

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
Suche Linktausch zum Thema Mode. Bitte PM
Backlink-Generator | Artikelverzeichnis | PageRank | SEnuke X
Don't smoke, don't fight, don't light no cigarettes,
Or else you'll wind up in the can!
No jokes, no rights, sit tight, don't fool around,
You are a guest of Uncle Sam!
AC/DC "I'll be damned"

nerd
PostRank 10
PostRank 10
Beiträge: 4023
Registriert: 15.02.2005, 04:02

Beitrag von nerd » 23.05.2010, 02:35

seonewbie hat geschrieben: 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
PostRank 9
PostRank 9
Beiträge: 1703
Registriert: 18.01.2007, 18:51

Beitrag von profo » 23.05.2010, 11:07

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

Antworten
  • Vergleichbare Themen
    Antworten
    Zugriffe
    Letzter Beitrag