SQL 3 mal in der Minute Datenban abfragen, Problem?

[Belee]

Hi

Das ist hier die Frage, ich nehme an es wäre kein Problem wenn sich 1 User auf der Seite befindet, nur was ist wenn es mal 100 sind?

Das ganze funktioniert via Ajax, ein Script refresht eine Seite 3 mal die Minute um immer die aktuellen Daten die ich via CronJob jede Minute hole und in die Datenbank ablege, anzuzeigen.

Ich denke das wird ein Problem oder? falls ja, wie könnte ich das lösen?

 

[firevegeta]

nein das sollte eigentlich kein Problem sein ich meine schau dir mal andere große seiten an die ähnlich funktionieren hast du es denn schon getestet?? via Stresstest ??

 

[bu1137]

300 Anfragen pro Minute sollten ein Problem sein? Sofern das ganze nicht sauschlecht optimiert und auf einer sacklahmen Kiste läuft, dürfte das eigentlich kein Problem sein.

Achja, bei MySQL gäb's zb. noch MEMORY (HEAP) Tables, dann würd das ganze komplett im RAM ablaufen. Wäre noch eine Option, falls die Daten komplett temporär sind, wonach es sich etwas anhört.

 

[IceMatrix]

Achja, bei MySQL gäb's zb. noch MEMORY (HEAP) Tables, dann würd das ganze komplett im RAM ablaufen. Wäre noch eine Option, falls die Daten komplett temporär sind, wonach es sich etwas anhört.

Im Normalfall ist das völlig unnötig. Dafür gibts den Datenbankpuffer, da liegt eh der Großteil im Arbeitsspeicher.

300 "einfache" Requests pro Minute sind ein Witz für eine normale Datenbank, da ist locker ein Hundertfaches möglich.

 

[Belee]

Nein habe ich nicht
Ich rechne halt nur, bei sagen wir mal 100 gleichzeitigen User, wären das im schlimmsten Fall 300 gleichzeitige Abfragen in der Minute. Wie soll das funktionieren? wirft SQL nicht einen Fehler? von wegen Race-Condition?

 

[bu1137]

Huh? Was meinst du, wie funktioniert zb. Computerbase? für jeden Benutzer einen Server? Das ist Pippifax, dafür sind Datenbanken gemacht. Und mit Race Condition hat das ganze gar nix zu tun.

 

[ice-breaker]

300 Anfragen pro Minute sollten ein Problem sein? Sofern das ganze nicht sauschlecht optimiert und auf einer sacklahmen Kiste läuft, dürfte das eigentlich kein Problem sein.

korrekt, wenn die Abfrage mit einem EXPLAIN einen guten QEP (Query Execeution Plan) hat, gibt es da keine Probleme, 300 pro Minute ist noch wenig, wir sprechen hier von 5 Anfragen pro Sekunde, eine gut optimierte Datenbank auf potenter Hardware schafft einige Tausend pro Sekunde.

Ich rechne halt nur, bei sagen wir mal 100 gleichzeitigen User, wären das im schlimmsten Fall 300 gleichzeitige Abfragen in der Minute. Wie soll das funktionieren? wirft SQL nicht einen Fehler? von wegen Race-Condition?

Darum musst du dich selbst kümmern (MyIsam) oder schaust dir gleich an wie richtige Datenbanken funktionieren (InnoDB), Stichwort Transaktionen.

 

[IceMatrix]

Wieso denn Race Condition? Die Zugriffe sind read-only. Da gibts per Defintion keine Race Condition.

Mit den Schreibzugriffen brauchst du dir auch keine Sorgen zu machen. Je nach verwendeter Storage-Engine kommen unterschiedliche Lockingverfahren zum Einsatz. Während INSERT, UPDATE oder DELETE werden bei MyISAM beispielsweise alle Leser blockiert. InnoDB differenziert etwas feiner und deshalb ohnehin vorzuziehen.

 

[Belee]

Nein
Gut, also ist es kein Problem, ok, wollte es nur wissen.

@matrix
Problem ist dass das CronJob-Script der die Daten holt ja jede Minute in die Datenbank schreibt, und genau hier mache ich mir die Gedanken, wenn genau dann z.B. sehr viele Abfragen kommen. Also der Zeitpunkt des schreibens/überschreibens und auslesens zu genau dem Zeitrpunkt!

 

[ice-breaker]

Mit den Schreibzugriffen brauchst du dir auch keine Sorgen zu machen. Je nach verwendeter Storage-Engine kommen unterschiedliche Lockingverfahren zum Einsatz. Während INSERT, UPDATE oder DELETE werden bei MyISAM beispielsweise alle Leser blockiert. InnoDB differenziert etwas feiner und deshalb ohnehin vorzuziehen.

Der Table-Lock von MyIsam schützt nicht vor Race-Conditions, denn er sichert nur einen einzelnen Query, die Race-Condition entsteht aber durch eine Abfolge von Querys bei der die Anwendung im Regelfall davon ausgeht, dass in der Zwischenzeit die Daten nicht modifiziert wurden.

 

[bu1137]

@Belee: Die Frage ist ja wohl: Wieviele Daten werden vom Cronjob geschrieben? Wenn du einen konsistenten output willst, musst du ev. die ganze Table locken. Aber wegen einzelner rows musst du dir keine Sorgen machen.

 

[IceMatrix]

Der Table-Lock von MyIsam schützt nicht vor Race-Conditions, denn er sichert nur einen einzelnen Query, die Race-Condition entsteht aber durch eine Abfolge von Querys bei der die Anwendung im Regelfall davon ausgeht, dass in der Zwischenzeit die Daten nicht modifiziert wurden.

Die Race Condition könnte genausogut innerhalb eines einzelnen Queries passieren, würde es kein Locking geben. Die Beschreibung hier klingt für mich nach einem einzelnen SELECT, welches sich alle Daten holt.

Sollten es tatsächlich mehrere sein und willst du Race Conditions verhindern, dann musst du InnoDB für alle beteiligten Tabellen wählen und alle Requests als Transaction durchführen.

Das machst du mit START TRANSACTION als ersten Request. Anschließend die eigentlichen Lese- und Schreiboperation und zum Schluss ein COMMIT oder ROLLBACK.

 

[Belee]

Die Daten die upgedatet werden, das ist lächerlich, maximal 100 Zeichen, an einer anderen Seite nur max. 8 Zeichen z.B. On/Off/Ready/Waiting
Vll. mache ich mir auch zuviel Sorgen.

 

[bu1137]

InnoDB würde ich mal als Overkill bezeichnen. Wenn du mich fragst, würde es genügen, beim Schreiben/Updaten der Daten die Table per Write-Lock zu sperren.

 

[ice-breaker]

Die Race Condition könnte genausogut innerhalb eines einzelnen Queries passieren, würde es kein Locking geben.

natürlich, ich möchte eben nur erwähnen, dass es nicht hilft, wenn man MyIsam und mehrere Querys nutzt die aufeinander aufbauen, ich sehe es immerwieder, dass der Fehler gemacht wird.

Die Beschreibung hier klingt für mich nach einem einzelnen SELECT, welches sich alle Daten holt.

ja, hier sollte es kein Problem sein, ich wollte es nur nochmal hervorheben, nicht dass sich "falsches" Wissen einprägt (, dass ein Tabel-Lock für einen Query gegen Race-Conditions hilft)

Sollten es tatsächlich mehrere sein und willst du Race Conditions verhindern, dann musst du InnoDB für alle beteiligten Tabellen wählen und alle Requests als Transaction durchführen.

Das machst du mit START TRANSACTION als ersten Request. Anschließend die eigentlichen Lese- und Schreiboperation und zum Schluss ein COMMIT oder ROLLBACK.

ich weiß

InnoDB würde ich mal als Overkill bezeichnen. Wenn du mich fragst, würde es genügen, beim Schreiben/Updaten der Daten die Table per Write-Lock zu sperren.

InnoDB ist nie Overkill, im Gegenteil: MyISAM zu Nutzen ist fahrlässig !
MyISAM bietet dir zu keiner Sekunde eine Garantie, dass deine Datenbank sicher gespeichert oder konsistent sind.
Schreib mal ein Script, dass kontinuierlich Daten in eine MyISAM-Tabelle schreibt und zieh dann den Stecker des Servers, die Wahrscheinlichkeit, dass du beim Anschalten des Servers korrupte Tabellen hast ist sehr hoch und beim Reparieren gehen dann eventuell Daten verloren.
Bei InnoDB hast du das Problem nie, durch die ACID-Regeln kannst du jederzeit den Stecker ziehen und du wirst nie korrupte Daten haben, einzig eine nicht abgeschlossene Transaktion wird - wie man es erwartet - nie ausgeführt worden sein, diese Garantie bietet dir MyISAM auch nicht, ein UPDATE über eine ganze Tabelle kann die Hälfte Zeilen updaten und dann durch einen Fehler unterbrechen und die andere Hälfte unberührt lassen.

MyISAM ist eine Spielwiese und funktioniert nur so gut, weil man davon ausgeht, dass es keine katastrophalen Fehler gibt !

 

[Belee]

Hmm...
Meine Tabellen sind alle MyISAM - sehe ich gerade. Kann man das problemlos auf InnoDB umstellen? und worauf muss man dann noch achten?

 

[bu1137]

Bevor InnoDB nötig wird, würd ich gleich auf PostgreSQL umstellen... Wenn du nur eine poplige Table mit nicht wirklich viel/relevantem Datenmüll hast, bist du mit Myisam immernoch besser bedient. Bei mehr read als write ist's damit schneller (nicht, dass das in deinem Fall wirklich relevant wäre).

 

[Belee]

Alles klar, und wie sieht mit mischen aus? ist das problemlos möglich? das z.B. einfache Sachen
mit MyISAM laufen und z.B. Forum, Userverwaltung usw. also etwas größere Sachen bzw. die Tabellen dann auf InnoDB?
Bei einer API die viel genutzt wird, könnte ich mir zudem vorstellen das MyISAM nicht das richtige wäre oder?

 

[IceMatrix]

Bevor InnoDB nötig wird, würd ich gleich auf PostgreSQL umstellen...

Wozu? PostgreSQL ist zwar ne schöne Sache, die meisten Webhoster und auch Web Applications unterstützen es aber nicht.

Ergänzung (11. Juni 2011)

Alles klar, und wie sieht mit mischen aus? ist das problemlos möglich? das z.B. einfache Sachen
mit MyISAM laufen und z.B. Forum, Userverwaltung usw. also etwas größere Sachen bzw. die Tabellen dann auf InnoDB?

In den meisten Fällen ist eine Umstellung unproblematisch. Vorsichtig musst du nur bei Tabellen mit FULLTEXT-Indices sein. Die werden bei InnoDB nicht unterstützt.

MyISAM und InnoDB mischen ist auch kein Problem. Dabei ist allerdings zu beachten, dass SQL-Transaktionen natürlich nur dann Sinn machen, wenn die beteiligten Tabellen alle InnoDB sind. Wenn du MyISAM mit drin hast wird für diese Tabellen die Transaktion schlicht ignoriert und es sind weiter Race Conditions möglich.

InnoDB ist übrigens auch die Empfehlung seitens MySQL. Spätestens ab MySQL 5.5 bringen sie gegenüber MyISAM in den meisten Szenarien auch deutliche Geschwindigkeitsvorteile mit sich.

 

[ice-breaker]

Wenn du nur eine poplige Table mit nicht wirklich viel/relevantem Datenmüll hast, bist du mit Myisam immernoch besser bedient. Bei mehr read als write ist's damit schneller (nicht, dass das in deinem Fall wirklich relevant wäre).

nicht unbedingt, das ist noch ein Mythos aus alten Zeiten, InnoDB ist mittlerweile so hochoptimiert und wenn der InnoDB-BufferPool richtig konfiguriert wird, dann ist InnoDB deutlich schneller.
Mit HandlerSocket (mit InnoDB über eine NoSQL-API sprechen) erreicht es sogar die Geschwindigkeit von NoSQL-Datenbanken.