Hab eben mal ein paar Geschwindigkeitsmessungen gemacht zwischen MyISAM und Heap. Leider konnte ich nur eine Verbesserung von 20% bei Heap gegenüber MyISAM feststellen(read/write mix). Wer hat noch damit Erfahrung? Bekom ich mit besserem Ram mehr Geschwindigkeit bei Heap? Nach meinem Verstand müsste Ram gegenüber festplatte doch viel mehr Geschwindigkeit bringen. Leider konnte meine Heap Tabelle nur 60150 Einträge aufnehmen mit einem Hash Index. Weiss einer warum genau dass so ist?
Meine Überlegung bei der Sache war,das Rohstoffzeugs was ja möglichst aktuell sein sollte ins Memory zu verlegen. Ich kann ja nebenbei was laufen lassen was den Kram peu a peu in ner anderen Tabelle sichert, sodass bei nem Serverdown nur 5mins Rohstoffe fehlen oder so. Oder ist das ganze Quatsch weils viel zuviel Ram schluckt?
Bitte jetzt keine Diskussion darüber wie man das mit den Rohstoffen anders machen kann, hier gibts genug andere Threads wo das ganze ausführlich steht.
Wer gar keine Ahnung hat wovon ich rede guckt ma hier:
http://dev.mysql.com/doc/mysql/en/memory-storage-engine.html
MySQL Tabellentyp Heap(Memory)
gepostet vor 19 Jahre, 10 Monate von Gambler
gepostet vor 19 Jahre, 10 Monate von schokofreak
Heap macht dann sinn, wenn die HardDisk stark genutzt wurde.
Bei einer Abfrage, welche so funktioniert wie du es skizierst...
Da laufen deine MyISAM Abfragen immer über indexe, richtig?
Wenn du eine Abfrage in MyISAM über indexe machst, halten sich die Plattenzugriffe extremstens in grenzen; sprich man spürt fast nicht, dass das ganze aus der Platte und ned aus dem Ram kommt.
Komplett anders verhält es sich jedoch, wenn man Zugriffe macht, wo keine Indexe möglich sind.
DANN ist der Unterschied extrem, ob Ram oder HD durchsucht werden muss.
Merke: Grössere Datenmengen, welche immer nach einem Index abgefragt werden, macht Heap nur bedingt sinn.
Kleiner / Mittlere Datenmengen, wo nach beliebigen Spalten durchsucht werden soll, macht Heap viel eher sinn.
Weiterhin zu beachten ist auch noch dies:
Wenn du misst, stellst du ev. bei einem heap Zugriff fest, dass er 20 % schneller ist, was die Ausführungszeit angeht. Denk jedoch daran, wo ein Festplattenzugriff stattfindet, wird ein anderer ausgebremst. Und da die Festplatte parallel zum eigentlichen Prozessor arbeitet.
=> Selbst wenn die ausführungszeit gleich gross ist bei Heap wie bei MyISAM. Sparst du ressourcen, da parallele Festplattenzugriffe schneller funktionieren / HD Cache weniger beansprucht wird, ...
-> Dies macht mehr aus, als man denkt.
Fazit:
Heap denke ich, lohnt sich normalerweise bei Abfragen mit Indexen nicht.
Bei Abfrage nach beliebigen Werten ohne Indexe sehr wohl.
Was mach ich in der Praxis?
Bei Abfragen mit Index gebrauch, welche sehr oft durchgeführt werden, da lagere ich (nach möglichkeit) in Shared Memory aus.
=> gibt n gewaltigen Performance Boost.
Bei Abfragen ohne Index Gebraucht überleg ich mir ob Heap oder doch lieber MyISAM.
Das Problem an Heap und Shared Memory ist, dass man immer kucken muss das alles synchron bleibt.
Fazit: Ich nutze für Sessions Heap. Und für persistente Readonly Daten wie z.B. Karte SharedMemory
Gruss
Bei einer Abfrage, welche so funktioniert wie du es skizierst...
Da laufen deine MyISAM Abfragen immer über indexe, richtig?
Wenn du eine Abfrage in MyISAM über indexe machst, halten sich die Plattenzugriffe extremstens in grenzen; sprich man spürt fast nicht, dass das ganze aus der Platte und ned aus dem Ram kommt.
Komplett anders verhält es sich jedoch, wenn man Zugriffe macht, wo keine Indexe möglich sind.
DANN ist der Unterschied extrem, ob Ram oder HD durchsucht werden muss.
Merke: Grössere Datenmengen, welche immer nach einem Index abgefragt werden, macht Heap nur bedingt sinn.
Kleiner / Mittlere Datenmengen, wo nach beliebigen Spalten durchsucht werden soll, macht Heap viel eher sinn.
Weiterhin zu beachten ist auch noch dies:
Wenn du misst, stellst du ev. bei einem heap Zugriff fest, dass er 20 % schneller ist, was die Ausführungszeit angeht. Denk jedoch daran, wo ein Festplattenzugriff stattfindet, wird ein anderer ausgebremst. Und da die Festplatte parallel zum eigentlichen Prozessor arbeitet.
=> Selbst wenn die ausführungszeit gleich gross ist bei Heap wie bei MyISAM. Sparst du ressourcen, da parallele Festplattenzugriffe schneller funktionieren / HD Cache weniger beansprucht wird, ...
-> Dies macht mehr aus, als man denkt.
Fazit:
Heap denke ich, lohnt sich normalerweise bei Abfragen mit Indexen nicht.
Bei Abfrage nach beliebigen Werten ohne Indexe sehr wohl.
Was mach ich in der Praxis?
Bei Abfragen mit Index gebrauch, welche sehr oft durchgeführt werden, da lagere ich (nach möglichkeit) in Shared Memory aus.
=> gibt n gewaltigen Performance Boost.
Bei Abfragen ohne Index Gebraucht überleg ich mir ob Heap oder doch lieber MyISAM.
Das Problem an Heap und Shared Memory ist, dass man immer kucken muss das alles synchron bleibt.
Fazit: Ich nutze für Sessions Heap. Und für persistente Readonly Daten wie z.B. Karte SharedMemory
Gruss
gepostet vor 19 Jahre, 10 Monate von Kampfhoernchen
@gambler:
Ich nehme an, das ist ein Schutz vor einem Memory Overflow. Zitat mysql-doku:
Das hier sollte man beachten:
#
Sie sollten immer MAX_ROWS im CREATE-Statement angeben, um sicherzustellen, dass Sie nicht versehentlich den gesamten Arbeitsspeicher benutzen.
#
Indexe werden nur bei = und <=> benutzt (sind aber SEHR schnell).
#
HEAP-Tabellen können nur ganze Schlüssel benutzen, um nach einer Zeile zu suchen. Vergleichen Sie das mit MyISAM-Tabellen, bei denen jedes Präfix des Schlüssels für das Suchen von Zeilen benutzt werden kann.
#
HEAP-Tabellen benutzen ein festes Datensatzlängenformat.
#
HEAP unterstützt keine BLOB/TEXT-Spalten.
#
HEAP unterstützt keine AUTO_INCREMENT-Spalten.
#
HEAP unterstützt keinen Index auf eine NULL-Spalte.
Ich hoffe das hilft dir.
@schokofreak:
Das stimmt schon, aber in dem Falle sollte man sich nochmal Gedanken über seine Datenbankstruktur machen.
Merke: Grössere Datenmengen, welche immer nach einem Index abgefragt werden, macht Heap nur bedingt sinn.
Kleiner / Mittlere Datenmengen, wo nach beliebigen Spalten durchsucht werden soll, macht Heap viel eher sinn.
Wo siehst du die Grenze zwischen kleineren und größeren Datenmengen? Weil klein und groß sind dehnbare begriffe.
Mein Fazit:
Heap lohnt sich höchstens für Session-Daten, auf die eigentlich bei jedem Seitenaufruf zugegriffen wird. Für alles andere ist der RAM-Verbrauch eigentlich zu hoch, da du bei Browsergames ja doch relativ schnell viele Daten zusammenkriegst. Für normale Tabellen benutz ich nur MyISAM, und achte auf saubere Indexe (schreibt man das so???), das bringt genug Performance.
EDIT: Wenn ich so überlege, für Flotten, die ja auch nur wenige Stunden unterwegs sind, könnte sich vielleicht ein Heap auch rentieren. Müsste man ausprobieren.
Leider konnte meine Heap Tabelle nur 60150 Einträge aufnehmen mit einem Hash Index. Weiss einer warum genau dass so ist?
Ich nehme an, das ist ein Schutz vor einem Memory Overflow. Zitat mysql-doku:
Um sicherzustellen, dass Sie nicht versehentlich etwas Unkluges tun, können Sie keine HEAP-Tabellen größer als max_heap_table_size erzeugen.
Das hier sollte man beachten:
#
Sie sollten immer MAX_ROWS im CREATE-Statement angeben, um sicherzustellen, dass Sie nicht versehentlich den gesamten Arbeitsspeicher benutzen.
#
Indexe werden nur bei = und <=> benutzt (sind aber SEHR schnell).
#
HEAP-Tabellen können nur ganze Schlüssel benutzen, um nach einer Zeile zu suchen. Vergleichen Sie das mit MyISAM-Tabellen, bei denen jedes Präfix des Schlüssels für das Suchen von Zeilen benutzt werden kann.
#
HEAP-Tabellen benutzen ein festes Datensatzlängenformat.
#
HEAP unterstützt keine BLOB/TEXT-Spalten.
#
HEAP unterstützt keine AUTO_INCREMENT-Spalten.
#
HEAP unterstützt keinen Index auf eine NULL-Spalte.
Ich hoffe das hilft dir.
@schokofreak:
Komplett anders verhält es sich jedoch, wenn man Zugriffe macht, wo keine Indexe möglich sind.
Das stimmt schon, aber in dem Falle sollte man sich nochmal Gedanken über seine Datenbankstruktur machen.
Merke: Grössere Datenmengen, welche immer nach einem Index abgefragt werden, macht Heap nur bedingt sinn.
Kleiner / Mittlere Datenmengen, wo nach beliebigen Spalten durchsucht werden soll, macht Heap viel eher sinn.
Wo siehst du die Grenze zwischen kleineren und größeren Datenmengen? Weil klein und groß sind dehnbare begriffe.
Mein Fazit:
Heap lohnt sich höchstens für Session-Daten, auf die eigentlich bei jedem Seitenaufruf zugegriffen wird. Für alles andere ist der RAM-Verbrauch eigentlich zu hoch, da du bei Browsergames ja doch relativ schnell viele Daten zusammenkriegst. Für normale Tabellen benutz ich nur MyISAM, und achte auf saubere Indexe (schreibt man das so???), das bringt genug Performance.
EDIT: Wenn ich so überlege, für Flotten, die ja auch nur wenige Stunden unterwegs sind, könnte sich vielleicht ein Heap auch rentieren. Müsste man ausprobieren.
gepostet vor 19 Jahre, 10 Monate von schokofreak
Mit klein mein ich die grössenordnung so bis ev. 10'000 Einträgen.
Sprich da haben gerade mal Session daten mit ev. einer kleinen Erweiterung platz (was für einen Zustand hat der eingeloggte User, das wichtigste halt).
Alles darüber würde ich niemals in Heap stellen.
Gruss
Sprich da haben gerade mal Session daten mit ev. einer kleinen Erweiterung platz (was für einen Zustand hat der eingeloggte User, das wichtigste halt).
Alles darüber würde ich niemals in Heap stellen.
Gruss
gepostet vor 19 Jahre, 10 Monate von Mudder
Mal so aus Neugier.. aber wie gestalltet Ihr ein Sessionsystem auf Heap-Basis? Bzw. welche Vorteile bringt das gegenüber dem herkömmlichen Sessionhandling?
gepostet vor 19 Jahre, 10 Monate von Gambler
Also dass Heap kein auto_increment beherrscht stimmt nicht mehr so ganz. Seit der 4.1 wurde das dort eingeführt laut Doku.
gepostet vor 19 Jahre, 10 Monate von schokofreak
Bei mir funktioniert das so:
Ich möchte die Kontrolle darüber, wie viele User so online sind.
Sprich: Es existiert eine Tabelle, mit einem maxRow.
Will sich ein User einloggen, wird ihm eine SessionID zugewiesen wert so zwischen 1 und 100, 1000, whatever.
Dort drinnen wird gespeichert:
-> welche UserId hat die Session
-> Was für einen Status hat die Session
==>> interessant für das löschen InAktiver.
-> diverse Cachings von nicht so "lebendigen" Daten
Wird user Ausgeloggt, wird in der heap Tabelle die SessionID wieder auf "frei" gestellt.
Das Aufsetzen einer Session ist zwar eher müsam... auch ned soo das schnellste. Dafür funktioniert es danach sehr gut und zuverlässig.
Ah ja... Session Daten im Stile von PHP SessionDaten gibt es bei mir praktsich gar nicht... dort steht (wenn überhaupt) gerade mal die zugehörige DB Session ID drinnen.
Gruss
Ich möchte die Kontrolle darüber, wie viele User so online sind.
Sprich: Es existiert eine Tabelle, mit einem maxRow.
Will sich ein User einloggen, wird ihm eine SessionID zugewiesen wert so zwischen 1 und 100, 1000, whatever.
Dort drinnen wird gespeichert:
-> welche UserId hat die Session
-> Was für einen Status hat die Session
==>> interessant für das löschen InAktiver.
-> diverse Cachings von nicht so "lebendigen" Daten
Wird user Ausgeloggt, wird in der heap Tabelle die SessionID wieder auf "frei" gestellt.
Das Aufsetzen einer Session ist zwar eher müsam... auch ned soo das schnellste. Dafür funktioniert es danach sehr gut und zuverlässig.
Ah ja... Session Daten im Stile von PHP SessionDaten gibt es bei mir praktsich gar nicht... dort steht (wenn überhaupt) gerade mal die zugehörige DB Session ID drinnen.
Gruss
gepostet vor 19 Jahre, 10 Monate von Kampfhoernchen
dort drinnen wird gespeichert:
-> welche UserId hat die Session
-> Was für einen Status hat die Session
==>> interessant für das löschen InAktiver.
-> diverse Cachings von nicht so "lebendigen" Daten
Wird user Ausgeloggt, wird in der heap Tabelle die SessionID wieder auf "frei" gestellt.
Das Aufsetzen einer Session ist zwar eher müsam... auch ned soo das schnellste. Dafür funktioniert es danach sehr gut und zuverlässig.
Ah ja... Session Daten im Stile von PHP SessionDaten gibt es bei mir praktsich gar nicht... dort steht (wenn überhaupt) gerade mal die zugehörige DB Session ID drinnen.
Gruss
Hast du von mir abgeschrieben?
Ich speichere nur zusätzlich zur Session-Id und der User-Id noch ein paar informationen mit ab, zum Beispiel, auf welchem seiner Planeten sich der User grade befindet. So muss ich den Planet nicht immer in der URL mit herumschleppen.
gepostet vor 19 Jahre, 9 Monate von Moogly
Ich arbeite auch mit einer Datenbankgebundenen Session wobei sich bei mir die Sessionid aus IP|user_id|und 3 Faktor zusammensetzt.... So muss ich den Wert für die Session_Id nicht immer freigeben!
MfG Moogly
MfG Moogly