zurück zur Startseite
  


Zurück XHTMLforum > Webentwicklung (außer XHTML und CSS) > Serveradministration und serverseitige Scripte
Seite neu laden Menge an SQL Befehlen pro Seite / MySQL Leistungsfähigkeit

Antwort
 
LinkBack Themen-Optionen Ansicht
  #1 (permalink)  
Alt 18.07.2007, 11:34
Neuer Benutzer
neuer user
Thread-Ersteller
 
Registriert seit: 18.07.2007
Beiträge: 10
gelleneu befindet sich auf einem aufstrebenden Ast
Standard Menge an SQL Befehlen pro Seite / MySQL Leistungsfähigkeit

Hallo,

ich entwickle zur Zeit ein eigenes CMS und stehe vor einem Problem. Das System muß sehr performant sein, da viele (gleichzeitige) Zugriffe zu erwarten sind. Gleichzeitig soll es sehr flexibel sein und nicht nur vorgefertigte, sondern individuelle Objektstrukturen beinhalten.

Um Objekte bzw. XML-artige Strukturen in MySQL zu speichern gibt es zwei in Frage kommende Ansätze:

1. Jedes Objekt bekommt eine eigene Tabelle (das ist meine Jetzige Variante).
So gibts also:

obj_artikel

mit den Feldern:
ueberschrift
body
text
author usw..

obj_link
obj_video
obj_seite

usw...

Das dumme daran ist, das der Verwaltungsaufwand sehr hoch ist, da ich die Objekte pro Seitenaufbau einzeln abfragen muß und zusätzlich noch die Rechte, Sichten, Tags usw.. für jedes Objekt einbinden muß. Macht schonmal 50-150 kleinere MySQL Abfragen pro Seite...

Eine andere Variante habe ich bei ezPublish gefunden:

Dann gibt es eine Tabelle "objekt" in der die Objekte hinterlegt sind, also
z.B. "Artikel 1, Artikel 2", und eine Tabelle Elemente, in der die Elemente eines Objektes zugeordnet sind.

Also z.B. ein Datensatz Artikel 1, text ...., ein Datensatz Artikel 1, ueberschrift.. usw..

Bei dieser Vorgehensweise besitzt ein Artikel also soviele Element-Datensätze,
wie Bestandteile. Besteht ein artikel aus 5 Bestandteilen macht es 5-Datensätze pro Artikel. Bei 1000 Artikeln sind es also 5000 Datensätze.
Nun kommen noch beliebig viele andere Objekte, beliebig strukturiert dazu...


Meine Frage: ich finde die zweite vorgehensweise eleganter, da flexibler, aber ich habe allergrößte Sorgen, das mir die Tabelle "elemente" aus allen Nähten platzt und die performance leidet. Zwar kann man alles wunderschön indizieren, und auch hier im Forum gibt es immer wieder Aussagen wie "mach dir um die Tabellengröße keine Gedanken", aber wie gesagt, es geht ja auch um Performance dabei...

Was ist, wenn 50 User gleichzeitig 50 Objekte auf der Seite Abfragen die wiederum pro Objekt 10 Elemente beherbergen?

Kann das gut gehen?

Habe bislang schlechte Erfahrungen mit großen MySQL Tabellen gemacht: lange Ladezeiten schon ab 5.000 Datensätzen...
Mit Zitat antworten
Sponsored Links
  #2 (permalink)  
Alt 18.07.2007, 12:28
Benutzerbild von loci
Benutzer
neuer user
 
Registriert seit: 17.02.2005
Ort: Saarland
Beiträge: 62
loci befindet sich auf einem aufstrebenden Ast
Standard

du wirst mit 10000 datensaetzen in einer tabelle wesentlich weniger probleme bekommen, als mit 150 abfragen je aufruf!
Mit Zitat antworten
Sponsored Links
  #3 (permalink)  
Alt 18.07.2007, 12:41
Neuer Benutzer
neuer user
Thread-Ersteller
 
Registriert seit: 18.07.2007
Beiträge: 10
gelleneu befindet sich auf einem aufstrebenden Ast
Standard

OK, das heißt ich optimiere meine Tabellenstruktur hinsichtlich der Zahl der Aufrufe...

Momentan hab ich es noch so, das ich mir zunächst aus einer Tabelle "klasse" die Namen des zu ladenden Objekttabellen hole, und dann alle Objekte, die auf der Seite vorkommen mit ihren Daten aus der Objekttabelle mit JOINS verknüpfe.

So nach dem Motto: SELECT * FROM seitenelemente LEFT OUTER JOIN obj_artikel ON... LEFT OUTER JOIN obj_links ON ... LEFT OUTER usw..

So habe ich zwar mit nur einer Abfrage alle Objekte der Seite erstmal abgerufen, aber das ganze scheint mir zu Lasten der übersichtlichkeit zu gehen, da eine verdammt "breite" Tabelle mit vielen NULL Feldern entsteht (jedes Objekt fügt ja seine Elemente an die Query an). Gerade wenn
viele Unterschiedliche Objekte gefragt sind. Wenn nun noch Sichten, Rechte, Tags und weiß der Fuchs noch was vorkommen, dann ist diese Variante halt nur sehr schwer handlebar...

Geändert von gelleneu (18.07.2007 um 12:44 Uhr)
Mit Zitat antworten
  #4 (permalink)  
Alt 18.07.2007, 14:20
Benutzerbild von loci
Benutzer
neuer user
 
Registriert seit: 17.02.2005
Ort: Saarland
Beiträge: 62
loci befindet sich auf einem aufstrebenden Ast
Standard

mit joins waere ich genauso vorsichtig, da diese sich dann bei hoher datensatzanzahl SEHR negativ auf die performance auswirken.

wenn das system spaeter nicht unbedingt auf jedem billigserver laufen muss und es wirklich auf performance ankommt, dann wuerde ich mir mal das entwurfsmuster der "data access objects" anschauen.
eine sinnvolle kapselung von programmlogik und datenzugriffsalgorithmen kann dir z.b. die einbindung eines leistungsfaehigen cache-systems (wie memcache) erlauben.
dem data access object ist es dann moeglich die daten aus einem cache zu laden bzw. wenn nicht im cache vorhanden aus der datenbank anzufragen und zu cachen. im idealfall wird hier also nur der (wesentlich leistungsfaehigere) cache beansprucht und die datenbank nur zum dauerhaften speichern der daten gebraucht.
Mit Zitat antworten
  #5 (permalink)  
Alt 18.07.2007, 15:03
Neuer Benutzer
neuer user
Thread-Ersteller
 
Registriert seit: 18.07.2007
Beiträge: 10
gelleneu befindet sich auf einem aufstrebenden Ast
Standard Danke

Danke loci, für deine Antwort.

Hmm. Ich fürchte das DAO Muster kommt nicht in Frage, da die Systemvorraussetzungen tatsächlich überschaubar sein müßen. Sie sollen tatsächlich Webhosting-Paket kompatibel sein (bedeutet u.a. auch leider noch PHP4, MySQL 4 usw...). Also kurzum: es geht um maximale Performance mit minimalen Systemanforderungen.

Einsatzgebiet sind Sites mit hohem redaktionellen Aufwand wie z.B. welt.de oder spiegel.de und vielen verschiedenen Unterseiten, Layoutänderungen (über Templates), Modulen und Services - allerdings natürlich nicht mit gleichhohen Zugriffszahlen. Natürlich wird auch ein sinnvolles Maß gefunden, also bei zugriffsstarken Seiten muß einfach die entsprechende Serverpower als Minimalanforderung stehen.

Bei ezPublish hört man z.B. das es doch recht behäbig ist, und daher nur bei entsprechend vorhandener Hardware empfehlenswert. Von daher kamen meine Bedenken, ob das Speicherprinzip mit zig Tausend Datensätzen in einer Tabelle wirklich das performance-günstigste ist...
Mit Zitat antworten
  #6 (permalink)  
Alt 20.07.2007, 13:44
Benutzerbild von loci
Benutzer
neuer user
 
Registriert seit: 17.02.2005
Ort: Saarland
Beiträge: 62
loci befindet sich auf einem aufstrebenden Ast
Standard

irgendwie passt das nicht ganz zusammen. seiten mit hohem redaktionellen aufwand und vielen benutzerzugriffen, die auf langsamen shared-hosting-servern laufen sollen

was scheinbar auch mit hohen benuzterzahlen funktioniert ist wordpress. leider habe ich da keinerlei erfahrungen mit, sehe es nur im einsatz bei hoeher frequentierten angeboten wie spreeblick oder dem bildblog.

vielleicht hilft es dir ja.
Mit Zitat antworten
  #7 (permalink)  
Alt 20.07.2007, 14:04
Neuer Benutzer
neuer user
Thread-Ersteller
 
Registriert seit: 18.07.2007
Beiträge: 10
gelleneu befindet sich auf einem aufstrebenden Ast
Standard Nee.

Nein, @loci, das hast Du wiederum falsch verstanden: das CMS soll für beide Varianten einsetzbar sein / minimal eben shared Hosting. Es sollte aber auch höheren Ansprüchen genügen, wobei dann ein eigener Server auch zur Verfügung stehen sollte. Nur ich kann halt nicht davon ausgehen, das die künftigen Nutzer a) am Server rumschrauben (lassen) können bzw. b) das CMS nur mit professioneller Hilfe installieren können.

Aber mal ne andere Frage:

ich habe mich jetzt für mein zweites Konzept entschieden und jetzt stehe ich wiederum vor folgender Frage: bis wann (ca. Datensatzzahl) sind Left Joins sinnvoll, und ab wann lohnt sich ne extra Abfrage?

Beispiel: ich habe meinen Strukturbaum, der listet mir für die auszugebende Seite 60 Objekte auf. Jedes dieser Objekte hat (je nach "Typ" durchschnittlich 10 Attribute, wie z.B. Überschrift, Inhalt, Autor usw..).

Nun könnte ich jedes Objekt die Attribute per Left Join abfragen -> macht dann ein Ergebnis von 600 Datensätzen (aus einer Tabelle mit vielleicht 100.000 DS). Dieses Ergebnis ist allerdings nach oben und unten Variabel. Es könnten auch schonmal 1000-2000 Datensätze sein.

Ist es da sinnvoller einfach die Objekt-ID zu nehmen und anhand dessen die Attribute in einer Extra Abfrage zu holen?
Mit Zitat antworten
  #8 (permalink)  
Alt 20.07.2007, 14:30
Benutzerbild von loci
Benutzer
neuer user
 
Registriert seit: 17.02.2005
Ort: Saarland
Beiträge: 62
loci befindet sich auf einem aufstrebenden Ast
Standard

da kann man ja mal einen Versuch starten

Versuchsaufbau:
- Tabelle "schulen" mit 36480 Schulen aus ganz Deutschland
- Tabelle "staedte" mit 14127 Städten aus ganz Deutschland
- Tabelle "plz" mit 16371 Postleitzahlen aus ganz Deutschland

- Tabelle "schulen" referenziert "staedte"
- Tabelle "plz" referenziert "schulen"

Datenbanktyp MySQL, Tabellentyp InnoDB, Foreign Keys und Indizes gesetzt.

Aufgabe Suche alle Schulen in Stuttgart (241) und zu Stuttgart alle möglichen Postleitzahlen (36).

Ergebnis (bei 100 Durchlaeufen je Abfrageart in Sekunden):

single query (inner join):
Datensaetze (gesamt): 8676
Zeit: 6.2226781845093

single query (left join):
Datensaetze (gesamt): 8676
Zeit: 4.1232039928436

multiple queries:
Datensaetze (Schulen): 241
Datensaetze (Städte): 1
Datensaetze (Postleitzahlen): 36
Zeit: 0.21742701530457

noch Fragen?
Mit Zitat antworten
  #9 (permalink)  
Alt 20.07.2007, 15:04
Neuer Benutzer
neuer user
Thread-Ersteller
 
Registriert seit: 18.07.2007
Beiträge: 10
gelleneu befindet sich auf einem aufstrebenden Ast
Standard Wow

Hee, danke für den Vergleich! Genau sowas hab ich gebraucht... OK... Hm, dann stellt sich gleich noch eine abschließende Frage, danach glaub ich, hab ich das Rüstzeug um eine Sinnvolle Architektur zu basteln.

Hab mir als Ziel gesetzt pro Seitenaufruf nicht mehr als 10-15 Queries zu verbraten, davon bin ich weit entfernt, und von daher soll man auch nicht
übermäßig geizen.

Wie stehst Du zum Thema, häufig gebrauchte Tabellenwerte am Anfang des Seitenaufrufes in Arrays zu laden und damit weiterzuarbeiten?

Bei mir wären das z.B. die Klassen. brauche da immer mal wieder nen Wert an unterschiedlichen Stellen im Programm. Ständig zu joinen oder direkt abzufragen wäre wohl quatsch, zumal es meist nur um ein, zwei benötigte Felder geht. Habe mal überschlagen, und denke das pro Website / Webapplikation wohl allerhöchstens 100 verschiedene Klassen aufkommen, sprich es wären einmal 100 Datensätze auszulesen. Nun könnte ich ruhiger schlafen, wenns auch mal 2-300 sein dürfen, ohne das jeder halbwegs performance-bedachte die Hände überm Kopf zusammenschlägt und sagt, "meine Güte, kannst du das nicht direkt aus der DB fischen?"....
Mit Zitat antworten
Sponsored Links
  #10 (permalink)  
Alt 20.07.2007, 15:18
Benutzerbild von loci
Benutzer
neuer user
 
Registriert seit: 17.02.2005
Ort: Saarland
Beiträge: 62
loci befindet sich auf einem aufstrebenden Ast
Standard

Da wären wir wieder beim Stichwort DAO
Es muss hier ja keine Abstraktion des Datenzugriffes erfolgen. Du könntest so z.B. einfach Daten einer gewissen Art nachladen und später auch sinnvoll auf bereits geladene Daten zugreifen.
Um bei mehreren Datensätzen nicht jeden einzeln anfragen zu müssen kann das DAO ja auch Kollektionen von Datensätzen laden können.

Das ladende DAO als Singelton, welches sich Datenobjekte mit den Inhalten hält. Werden Daten nachgeladen so wird einfach ein weiteres Datenobjekt im DAO angelegt und befüllt. Auf diese Datenobjekte kann dann später jederzeit wieder zugegriffen werden.
In solch einem Fall ist es z.B. extrem einfach einen optionalen Cache-Server einzubinden.

Ein solches System habe ich schon entwickelt, kann es aber leider aktuell nicht veröffentlichen.

Geändert von loci (20.07.2007 um 15:24 Uhr)
Mit Zitat antworten
Sponsored Links
Antwort

Themen-Optionen
Ansicht

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus


Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
header in CSS definieren und individueles Hintergrundbild pro Seite raba43 CSS 6 01.09.2009 12:17
Problem mit einbinden von Dropdown-Navigation in Seite... epsylon2 CSS 4 29.03.2009 00:25
Gelistete "Treffer" oder "Anzeigen" pro Seite begrenzen - aber wie? fossy (X)HTML 4 23.10.2008 11:29
Mootools: Mehrere Elemente pro Seite? isa007 Javascript & Ajax 2 11.06.2008 14:34
Wordpress: „Es werden x Einträge pro Seite angezeigt“ E|H Serveradministration und serverseitige Scripte 0 30.10.2005 16:14


Alle Zeitangaben in WEZ +2. Es ist jetzt 18:27 Uhr.