[SQL allgemein] Onlineliste/letzte Aktion - high performance Lösung gesucht

**jahlives** · 20.05.2008, 16:17

Wieso brauchst du überhaupt einen Lock auf die Tabelle? Ich würde in der Usertabelle einfach eine Spalte LastAction anfügen und bei jedem Klick des Users das Feld aktualisieren. Kann mir nicht so recht vorstellen für wieviele User du das planst. Aber das einfache Updaten eines Feldes kann imho die DB doch nicht kippen

**onemorenerd** · 20.05.2008, 16:38

Ich glaube er meint, dass MyISAM kein Row Level Locking kann und fürs Update eines Wertes die ganze Tabelle sperrt.

**Heady23** · 20.05.2008, 18:54

Original geschrieben von onemorenerd
Ich glaube er meint, dass MyISAM kein Row Level Locking kann und fürs Update eines Wertes die ganze Tabelle sperrt.

Genau.

**tontechniker** · 22.05.2008, 15:33

fürs Update eines Wertes die ganze Tabelle sperrt.

Aber nur wenn vom Entwickler veranlasst, von daher weiterhin die Frage

Wieso brauchst du überhaupt einen Lock auf die Tabelle?

Ich sehe da kein Problem, solange der Datenbankserver die Seite für alle anzeigen kann sollte er auch ein Update pro Aufruf verkraften können (solange die Sekunden uninteressant sind für ich nur ein Update / Minute machen).

**onemorenerd** · 22.05.2008, 15:49

Original geschrieben von tontechniker
Aber nur wenn vom Entwickler veranlasst

Ich rede nicht über LOCK TABLE sondern das interne Locking.

**tontechniker** · 22.05.2008, 16:15

Ich rede nicht über LOCK TABLE sondern das interne Locking.

Sollte das bei UPDATE tatsächlich zu einem Problem werden kannst du entweder INSERTS verwenden und eine extra Tabelle verwenden oder du musst dafür tatsächlich eine eigene Verwaltung auf Shared Memory bzw. MEMORY Tabellen Basis aufbauen. Du kannst dann ja in regelmäßigen Abständen die Daten in die User Tabelle übernehmen.

**Heady23** · 23.05.2008, 01:01

Original geschrieben von tontechniker
Sollte das bei UPDATE tatsächlich zu einem Problem werden kannst du entweder INSERTS verwenden und eine extra Tabelle verwenden oder du musst dafür tatsächlich eine eigene Verwaltung auf Shared Memory bzw. MEMORY Tabellen Basis aufbauen. Du kannst dann ja in regelmäßigen Abständen die Daten in die User Tabelle übernehmen.

An sowas habe ich auch gedacht. Aber dann inserte ich und sobald ich dann (per cron) da aufräume und in die users merge habe ich (gefühlt) den doppelten overhead.
MEMORY Tabellen brachten in meinen 1. Benchmarks nur unwesendlich mehr Performance. Das Locking Problem (das hier viele nicht verstehen) bleibt hierbei auch bestehen.

Ich habe mir jetzt per Memcache was selbst gebastelt, was vom Gefühl her SCHRECKLICH ist, aber scheinbar in 1. Tests 50% mehr Performance als eine MEMORY Tabelle bringt.
Hier update ich je Klick im Memcache die Zeit des Users in einem Wert und schreibe einen weiteren Wert durchnummeriert mit der user_id.
Um die letzte Aktualisierung des Users abzurufen muss ich nur auf den Memcache Wert mit der user_id zugreifen. Perfekt.
Wenn ich allerdings eine Liste aller User abrufen will muss ich nun meine durchnummerierten Einträge manuell durchgehen bis ich xhundert distinct User habe. Klingt schrecklich, scheint aber recht gut zu performen.

**tontechniker** · 23.05.2008, 01:20

Klingt schrecklich, scheint aber recht gut zu performen.

Warum schreibst du nicht ein assoziatives Array mit den user_id => last_action Zuordnung und nimmst dir dann einfach 100 raus? Die könntest du sortieren und es wäre wesentlich performanter.

MEMORY Tabellen brachten in meinen 1. Benchmarks nur unwesendlich mehr Performance. Das Locking Problem (das hier viele nicht verstehen) bleibt hierbei auch bestehen.

Das Problem verstehe ich inzwischen schon, ich kann nur noch nicht ganz nachvollziehen warum es solche Probleme mit dem internen Locking gibt.

**Heady23** · 23.05.2008, 02:22

Original geschrieben von tontechniker
Warum schreibst du nicht ein assoziatives Array mit den user_id => last_action Zuordnung und nimmst dir dann einfach 100 raus? Die könntest du sortieren und es wäre wesentlich performanter.

Und wie aktualisiere ich das Array? Dazu muss ich es ja auslesen, ändern, speichern. Da muss ich manuell locken wenn 2 User gleichzeitig eine Aktion durchführen.

Das Problem verstehe ich inzwischen schon, ich kann nur noch nicht ganz nachvollziehen warum es solche Probleme mit dem internen Locking gibt.

Weil meine schöne 32 Core Kiste 32 updates gleichzeitig machen will, dann die mysql sagt "ah, ich sperr mal eben die ganze Tabelle für ein Update" und EIN Update durchführt, während dem zu allem übel auch kein select mehr laufen kann, das sitzt dann auch und wartet bis das update fertig ist. Usw...
Vielleicht versteh ich es auch nicht sooo genau, ich weiss nicht wie der Server bitte PARALLEL aus dem Ram/der HDD Daten holen will... das geht doch eh nicht wirklich?
Aber dieses gelocke/aufstauen von Querys benötigt performance und mir zerhauts die Server wenn man es "einfach so" macht.

**tontechniker** · 23.05.2008, 02:48

quote:Original geschrieben von tontechniker Warum schreibst du nicht ein assoziatives Array mit den user_id => last_action Zuordnung und nimmst dir dann einfach 100 raus? Die könntest du sortieren und es wäre wesentlich performanter. Und wie aktualisiere ich das Array? Dazu muss ich es ja auslesen, ändern, speichern. Da muss ich manuell locken wenn 2 User gleichzeitig eine Aktion durchführen.

Du darfst halt nur auf bestimmte Speicherbereiche zugreifen, mit ein wenig Aufwand geht das sicherlich, die Daten sind ja im Prinzip immer gleichlang und verändern sich in der Länge auch nicht, sodass du genau an eine bestimmte Stelle schreiben kannst. Die shmop-Funktionen beispielsweise erlauben einen derartigen Zugriff.

während dem zu allem übel auch kein select mehr laufen kann, das sitzt dann auch und wartet bis das update fertig ist. Usw...

Was du mit Inserts laut MySQL Doku verhindern kannst, bei so hohen Anforderungen ist eine nicht Datenbank basierte Lösung aber wohl doch besser.

**onemorenerd** · 23.05.2008, 03:22

Oh Vorsicht. Unter bestimmten Bedingungen kann MySQL in MyISAM-Tabellen parallel Lesen und Einfügen, das ist richtig. Diese Bedingung sind aber nur dann zuverlässig gegeben, wenn man ausschließlich INSERTs und SELECTs ausführt.

Aber auch dann stauen sich die Writes auf. Das kann man nur mit (noch) besserer Hardware erschlagen.

Der Ansatz mit Memcache ist vielleicht wirklich eine gangbare Alternative. Die Liste aller User, die jetzt noch so teuer ist, kannst du als separate Datenstruktur anlegen.

Quasi für jeden Zweck eine MEMORY-Tabelle. Dank Memcache ohne den Overhead eines DBMS, dafür auch ohne ACID.

**TheFish511** · 24.05.2008, 12:22

Schonmal an MyISAM Merge-Tabellen gedacht?
Habs selber noch nicht praktisch gemacht aber vom Prinzip her würds doch passen?!
Einfach die user nach der userid auf mehrere Tabellen aufteilen, auf die du dann auch die UPDATE-Queries ausführst. Über die Merge-Tabelle kannst du dann deine SELECTs ausführen, oder?

**Heady23** · 24.05.2008, 12:30

Original geschrieben von TheFish511
Schonmal an MyISAM Merge-Tabellen gedacht?
Habs selber noch nicht praktisch gemacht aber vom Prinzip her würds doch passen?!
Einfach die user nach der userid auf mehrere Tabellen aufteilen, auf die du dann auch die UPDATE-Queries ausführst. Über die Merge-Tabelle kannst du dann deine SELECTs ausführen, oder?

Nachgedacht ja, getestet noch nicht.
Irgendwie missfällt mir der Gedanke per Hand viele kleine Tabellen anzulegen, nur damit es dann besser ist als eine. Ich finde, das ist die Aufgabe der mysql :-/
Aber kann ich mal testen.
Die Shared Memory Variante ist auch interessant, allerdings nicht verteilbar auf mehrere Server.

[SQL allgemein] Onlineliste/letzte Aktion - high performance Lösung gesucht