MySQL - Sehr sehr schwerer Query, ich schaffs nicht alleine

[Emiel]

Hallo.

Ich code ein eigenes Forum zur Zeit.
Nun geht es Darum einen Thread darzustellen.
Dafür müssen sämtliche Informationen aus der Datenbank geholt werden.
Wenn möglich mit einem Query.

Hier die Datenbank _mit_ Beispieleinträgen:

board_category
##############
categoryid subcategoryid categoryname
1          0             Sport
2          1             Handball
3          2             Vereine
4          0             Ernährung

board_post
##########
postid threadid uid creationtime post
1      1        1   TIMESTAMP    "Hier steht der Text des Posts1"
2      1        2   TIMESTAMP    "Hier steht der Text des Posts2"
3      1        1   TIMESTAMP    "Hier steht der Text des Posts3"

board_thread
############
threadid threadtitel uid categoryid
1        "Ein Test"  1   3

board_thread_pics
#################
threadid picurl pictitle
1        htt..  "Ein Elefant!"
1        htt..  "Ein zweiter Elefant!"
1        htt..  "Ein Elefant!"

users

uid loginname
1   Franz
2   Joe

Ich habe den Wert 1 und möchte Thread 1 auslesen.
Der Query sieht in Pseudo so aus:
Hole mir den Threadtitel und die Userid die den Thread erstellt hat sowie die Category id. Lese die Category mit der Categoryid aus und alle Subcategories. Hole mir ausserdem alle Posts die zu dieser Threadid gehören und dazu die Erstellungszeiten der Posts und die Authoren der jewiligen Posts. Ausserdem lese alle Bilder aus die der Thread-Ersteller in seinen Post einbezogen hat.

Besonders schwer tue ich mich bei den Categories diese sind ja so aufgebaut das solange der subcategoryid-Wert != 0 ist, eine weiter Category darunter liegt.
Also ich will in diesem Fall später ausgeben können:
Sport -> Handball -> Vereine

Mein Ansatz sieht so aus, ich weiß das das nicht klappen kann so und ich blicke bei subselects und dem umgang damit auch überhaupt nicht durch:

  
SELECT  
board_thread.threadtitel,  
board_thread.categoryid,  
board_category.categoryname,  
  
board_thread_post.postid,  
board_thread_post.uid,  
board_thread_post.creationtime,  
board_thread_post.post,  
  
board_thread_media.mediatype,  
board_thread_media.mediaurl,  
board_thread_media.mediatitle  
  
FROM board_thread  
JOIN board_thread_post ON board_thread_post.threadid = '1'  
JOIN board_thread_media ON board_thread_media.threadid = '1'  
JOIN users ON users.uid = board_thread_post.uid  
JOIN board_category ON board_category.categoryid = board_thread.categoryid  
WHERE board_thread.threadid = '1'

PUH Also mir ist das eindeutig ne Ecke zu hoch wie ich sowas bewältigen soll.

Gruß,

Emiel

[Jan Feddersen]

ALSO hier erstmal was ich an deinem Select nicht kapier !:

  
SELECT  
board_thread.threadtitel,  
board_thread.categoryid,  
  
  
board_category.categoryname,  
  
board_thread_post.postid,  
board_thread_post.uid,  
board_thread_post.creationtime,  
board_thread_post.post,  
  
?? board_thread_media.mediatype,  
?? board_thread_media.mediaurl,  
?? board_thread_media.mediatitle  
  
FROM board_thread  
JOIN board_thread_post ON board_thread_post.threadid  
JOIN board_thread_media ON board_thread_media.threadid  
JOIN users ON users.uid = board_thread_post.uid  
JOIN board_category ON board_category.categoryid = board_thread.categoryid  
WHERE board_thread.threadid = '1'  

So würde es sinn machen Wenn du deine DB nochn bisi erweiterst:

  
SELECT  
board_thread.threadid,  
board_thread.threadtitel,  
board_thread.categoryid,  
  
  
board_category.categoryname,  
  
board_thread_post.postid,  
board_thread_post.uid,  
board_thread_post.creationtime,  
board_thread_post.post,  
  
board_thread_pics.threadid,  
board_thread_pics.picurl,  
board_thread_pics.pictitle  
  
FROM board_thread  
JOIN board_thread_post ON board_thread_post.threadid = board_thread.threadid  
JOIN board_thread_media ON board_thread_media.threadid = board_thread.threadid  
JOIN users ON users.uid = board_thread_post.uid  
JOIN board_category ON board_category.categoryid = board_thread.categoryid  
WHERE board_thread.threadid = '1'  

--------------

IT & PR - Fenebris.com
janfeddersen _at_ dunkelnetz _dot_ de
Kredite, Umschuldung, Finanzen

[Emiel]

Sorry.

Hier der richtige:
http://forum.de.selfhtml.org/my/?t=188078&m=1251413

[Emiel]

Hey.

Sorry der QUery sieht so aus:

SELECT  
board_thread.threadtitel,  
board_thread.categoryid,  
board_category.categoryname,  
  
board_thread_post.postid,  
board_thread_post.uid,  
board_thread_post.creationtime,  
board_thread_post.post,  
  
board_thread_pics.picurl,  
board_thread_pics.pictitle  
  
FROM board_thread  
JOIN board_thread_post ON board_thread_post.threadid = '1'  
JOIN board_thread_pics ON board_thread_pics.threadid = '1'  
JOIN users ON users.uid = board_thread_post.uid  
JOIN board_category ON board_category.categoryid = board_thread.categoryid  
WHERE board_thread.threadid = '1'

[Jan Feddersen]

SELECT

board_thread.threadid,

board_thread.threadtitel,
board_thread.categoryid,
board_category.categoryname,

board_thread_post.postid,
board_thread_post.uid,
board_thread_post.creationtime,
board_thread_post.post,

board_thread_pics.picurl,
board_thread_pics.pictitle

FROM board_thread
JOIN board_thread_post ON board_thread_post.threadid = board_thread.threadid
JOIN board_thread_pics ON board_thread_pics.threadid = board_thread.threadid
JOIN users ON users.uid = board_thread_post.uid
JOIN board_category ON board_category.categoryid = board_thread.categoryid
WHERE board_thread.threadid = '1'

Zur erklärung:
JOIN board_thread_post ON board_thread_post.threadid = board_thread.threadid
und nicht:
JOIN board_thread_post ON board_thread_post.threadid = 1

da wir am ende der Joins Sowieso board_thread.threadid auf 1 setzen können wir es uns bequemer machen und die Variable 1 nur 1 mal reinschreiben und sonst nur refferenzieren

JOIN board_thread_pics ON board_thread_pics.threadid = board_thread.threadid
und nicht
JOIN board_thread_pics ON board_thread_pics.threadid = 1
wieder das selbe wie oben

oben im select sollte auch board_thread.threadid als selectierter param stehen ! :)
--------------

IT & PR - Fenebris.com
janfeddersen _at_ dunkelnetz _dot_ de
Kredite, Umschuldung, Finanzen

[Emiel]

War mir eigentlich schonklar, dachte nur das würde das ganze jetzt einfacher machen ;)

Kannst du mir bei meinem eigentlichen Problem weiterhelfen?

Gruß, Emiel

[Emiel]

Kann mir denn keiner helfen??

Dedlfix, Tom, Rautenberg, Gunnar usw .. wo seid ihr =(..

[dedlfix]

echo $begrüßung;

Nun geht es Darum einen Thread darzustellen.
Dafür müssen sämtliche Informationen aus der Datenbank geholt werden.
Wenn möglich mit einem Query.

Möglich ist das - irgendwie - aber nicht sinnvoll. Denn dazu müsstest du mehrere Abfragen mit UNION verbinden, was nur bei gleichen oder vergleichbaren Feldern sinnvoll ist. Die Anzahl muss auch übereinstimmen. Und beim Auswerten musst du unterscheiden, welcher Datensatz für welche Informationsart (Thread, Posting, Pic) steht. Andererseits kannst du joinen, wobei aber ohne Join-Bedingung x Datensätze aus der einen Tabelle und y Datensätze aus der anderen Tabelle x × y Datensätze in der Ergebnismenge ergeben (jeder mit jedem - kartesisches Produkt). Mit einer Join-Bedingung kann man die Menge reduzieren, aber es entstehen dann immer noch für beispielsweise 5 Postings gejoint mit einem Thread insgesamt 5 Postings mit 5 mal den Thread-Daten dazu, obwohl du die Thread-Daten vielleicht nur einmal für den Seitenkopf brauchst. Noch schlimmer wird es, wenn Pics in wechselnder Anzahl und unregelmäßig in die Postings eingestreut sind. Dann hast du entweder zu viele sich wiederholende Postingdaten oder zu viele Bilder im Ergebnis oder beides. Joine also nur da, wo es für das Ergebnis sinnvoll ist und mach dir das Programm nicht an anderer Stelle unnötigerweise komplexer, nur weil du hier etwas sparen willst. Optimieren geht meist ganz anders.

Ich würde mit einer Abfrage die Daten zu Thread 1 aus board_thread holen. Eine zweite Abfrage holt die Postings zu diesem Thread. Eine dritte die Pics. Gejoint werden müssen nur die Userdaten mit den Postings, denn nur die stehen in einem direkten 1:1-Zusammenhang.

Besonders schwer tue ich mich bei den Categories diese sind ja so aufgebaut das solange der subcategoryid-Wert != 0 ist, eine weiter Category darunter liegt.
Also ich will in diesem Fall später ausgeben können: Sport -> Handball -> Vereine

Auch die Abfrage der Kategorienhierarchie bekommt eine eigene Abfrage, wenn nicht sogar eine komplette Umgestaltung. Die Kategorie mit dem niedrigsten Level bekommst du aus der Thread-Abfrage über die dortige categoryid.

board_category
##############
categoryid subcategoryid categoryname
1          0             Sport
2          1             Handball
3          2             Vereine
4          0             Ernährung

Die Herausforderung ist jetzt aber, an die jeweils übergeordneten Levels zu kommen, ohne ständig die subcategoryid aus dem Ergebnis auswerten und eine neue Abfrage absenden zu müssen. Das Problem dabei ist, dass du nicht in einer Bedingungsformulierung alle übergeordneten Kategorien und nur diese ansprechen kannst. Jedenfalls nicht dann, wenn die Tiefe unterschiedlich ist, also einmal 3, ein anderes Mal 2 und manchmal 4 Level bis oben abzufragen sind. Bei feststehender Tiefe kann man da mit Selfjoins was hinbekommen, was bei n Levels n-1 Joins bedeutet. Für dieses Dilemma gibt es (besser: kenne ich) zwei Lösungswege.

Wenn die Anzahl der Kategorien überschaubar klein ist, kann man einfach alle Datensätze abfragen und die passenden Kategorienamen rekursiv im Programm heraussuchen. Der Aufwand das in Code zu fassen ist nicht besonders hoch. Allerdings erhöht sich mit steigender Kategorienanzahl die für jedes Level benötigte Zeit beim Durchlaufen der Datenmenge.

Bei umfangreichem Kategorie-Baum ist es deshalb sinnvoller, nur die benötigten Daten aus dem DBMS zu holen. Dafür hat man Nested Sets erfunden. Jedoch erkauft man sich die Vorteile von Nested Sets mit einer erhöhten Komplexität bei der Datenpflege. Einfügen und Löschen sind aufwendig, weil stets mehr oder weniger große Teile der Datensätze zu ändern sind. Nested Sets spielen ihre Vorteile aus, wenn viel gelesen und wenig geändert wird. Zu Nested Sets gibt es einiges Material im Netz, einfach mal danach googeln oder bingen.

Mein Bauchgefühl rät mir zur Alles-und-dann-selbst-suchen-Variante statt Nested Sets. Die Kategorienanzahl wird sich im niedrigen zweistelligen Bereich bewegen, da ist das vertretbar, wenn man sich auf der anderen Seite den Nested-Sets-Aufwand dazu anschaut.

JOIN board_thread_post ON board_thread_post.threadid = '1'
JOIN board_thread_media ON board_thread_media.threadid = '1'
JOIN users ON users.uid = board_thread_post.uid
JOIN board_category ON board_category.categoryid = board_thread.categoryid
WHERE board_thread.threadid = '1'[/code]

In der ON-Klausel eines Joins sollten nur die Verknüpfungsbedingungen stehen. Die Datenmenge einschränkende Bedingungen gehören ins WHERE. Lediglich die für die Verknüpfung relevanten/notwendigen einschränkenden Bedingungen kommen noch mit ins ON. Doch auf den Fall trifft man(/ich) eher selten.

echo "$verabschiedung $name";

[Emiel]

Hey Dedlfix.

Hm okay du hast Recht.
Ich dachte mir wenn ich daraus 3 oder 4 Queries mache dann habe ich bei 400 zugriffen gleich 1200 I/O Zugriffe in der Datenbank statt ein Drittel oder Viertel. Ich sehe sowas immer sehr sehr kritisch und versuche möglichst wenig Queries zu verwenden.

Also ich schneide bevor ich auf den Rest eingehe ein kleines weiteres Thema an. Ich hatte ursprünglich vor das nur der Threadersteller Bilder einbinden darf. Denn ich sehe das Problen folgendem: Ich möchte dem User nicht die Möglichkeit geben Fotos hochzuladen, das sind mir zu hohe Serverkosten, ich möchte das sie nur von extern einen Link setzen können.
Da kommen weiter Probleme auf.
1. Rechtliche - die habe ich aber auch beim Threadersteller, aber es sind dann deutlich weniger rechtliche Probleme die entstehen könnten.
2. Der andere könnte das Bild nach dem Post ändern in ein 4000*9000px Bild. Die Folge ist klar.
3. Die Wartezeit verlängert sich nochmehr.

Also ich stehe da noch sehr im Zwiespalt.

Also ausgehend davon das nur der Threadersteller Bilder einbinden darf, würde ich mit Query 1:
Query 1: Die Thread-Informationen + Bilder + Userinfos
Query 2: Die Post informationen + Userinfos
Query 3: Die Kategorien
holen.

Was hälst du davon? Er darf btw. maximal 10 Bilder einbinden.

»» board_category
»» ##############
»» categoryid subcategoryid categoryname
»» 1          0             Sport
»» 2          1             Handball
»» 3          2             Vereine
»» 4          0             Ernährung

Ich ich sehe das auch als Problemeatisch, ich dachte das würde mit einer einfachen Query funktionieren. Du vertust dich leider, die Kategorien gehen mindestens in den 3 wenn nicht sogar 4,5- maybe in a few year 6,7 - stelligen Bereich, alleine weil es die Kategorien in mehreren Sprachen geben wird, d.h. wenn es 300 Kategorien sind - werden daraus 1200 Datensätze usw... Die Abfrage muss wirklich schnell sein.
Ich habe aber für mich eine maximal "verschachtelung" von 5 Ebenen festgelegt. Also maximal:
Kategorie 1 -> Kategorie 2 -> Kategorie 3 -> Kategorie 4 -> Kategorie 5

Mein Bauchgefühl rät mir zur Alles-und-dann-selbst-suchen-Variante statt Nested Sets. Die Kategorienanzahl wird sich im niedrigen zweistelligen Bereich bewegen, da ist das vertretbar, wenn man sich auf der anderen Seite den Nested-Sets-Aufwand dazu anschaut.

Siehe oben. Wie sieht dein Bauchgefühl jetzt aus?

In der ON-Klausel eines Joins sollten nur die Verknüpfungsbedingungen stehen. Die Datenmenge einschränkende Bedingungen gehören ins WHERE. Lediglich die für die Verknüpfung relevanten/notwendigen einschränkenden Bedingungen kommen noch mit ins ON. Doch auf den Fall trifft man(/ich) eher selten.

Ich weiß, ich weiß, ich weiß, ich habs beim posten hier aus Faulheit schnell so hingeschrieben um deutlicher zu demonstrieren, was bei dem Wert 1 sein würde.

alert("Danke Dedlfix. Auf Wiedersehen Dedlfix.");

[dedlfix]

echo $begrüßung;

Ich dachte mir wenn ich daraus 3 oder 4 Queries mache dann habe ich bei 400 zugriffen gleich 1200 I/O Zugriffe in der Datenbank statt ein Drittel oder Viertel. Ich sehe sowas immer sehr sehr kritisch und versuche möglichst wenig Queries zu verwenden.

400 Zugriffe in welcher Zeit? Möglichst wenig Datenbankabfragen kann man erreichen, indem man oft gefragtes Zeug in einem Cache ablegt. Auch für aufwendig zu berechnende Geschichten ist es günstig, das Resultat zu cachen, wenn es danach noch ein paar Mal benötigt wird.

Also ich schneide bevor ich auf den Rest eingehe ein kleines weiteres Thema an.
[Probleme mit Bildern]
Also ich stehe da noch sehr im Zwiespalt.

Aus dem kann ich dich auch nicht rausholen. Ich sehe diese Probleme auch, hab aber kein Rezept dagegen.

Also ausgehend davon das nur der Threadersteller Bilder einbinden darf, würde ich mit Query 1:
Query 1: Die Thread-Informationen + Bilder + Userinfos
Was hälst du davon? Er darf btw. maximal 10 Bilder einbinden.

(hältst - mit zwei t) Die Thread-Information benötigst du unbedingt und nur einmal und nicht so oft wie die Bilder, von denen es 0 bis 10 gibt. Das bekommst du mit einem LEFT JOIN geregelt, also dass auch bei 0 Bildern die Thread-Daten kommen, aber bei mehr als einem Bild hast du die Threaddaten mehr als einmal abgefragt. Was ist nun effektiver, zwei Querys oder ein zweifelhafter Join und unnötig redundante Daten? Eine kleine Messreihe wird die Antwort liefern. Überhaupt ist das Messen der verschiedenen Szenarien besser als theoretische Überlegungen. Auch das Definieren von Indexen kann optimierend wirken und die Kontrolle mit EXPLAIN, ob sie auch verwendet werden, sollte man ebenfalls nicht vergessen.

Du vertust dich leider, die Kategorien gehen mindestens in den 3 wenn nicht sogar 4,5- maybe in a few year 6,7 - stelligen Bereich, alleine weil es die Kategorien in mehreren Sprachen geben wird, d.h. wenn es 300 Kategorien sind - werden daraus 1200 Datensätze usw... Die Abfrage muss wirklich schnell sein.

Am besten messen. Das setzt voraus, dass du beide Szenarien implementierst. Schlimmstenfalls hast du Zeit verbraucht, dabei aber Erfahrung gesammelt. Ist es notwendig, den Kategorienbaum je Sprache extra zu verwalten? Sind die Kategorien andere und/oder anders geschachtelt, wenn die Sprache wechselt? Oder ist der Aufbau der gleiche und du hast das Übersetzungsproblem nicht nur für die Kategorien sondern auch für alles andere und brauchst allein dafür schon einen eigenständigen Übersetzungsmechanismus?

Wie auch immer, die Kategorien werden sich nicht soo häufig ändern, der Nested-Sets-Aufwand wird sich vermutlich rechnen. Man könnte auch alle Pfade einmalig (nach jeder Änderung) vorberechnen. Das ergibt auch nur so viele Datensätze wie Kategorien vorhanden sind. Eine Abfrage darauf ist einfachst und ergibt stets einen Datensatz. Noch schneller wirst du es nur mit Caching hinbekommen.

Wie sieht dein Bauchgefühl jetzt aus?

Genauere Vorgaben lassen meinen Bauch genauer fühlen :-) Was auch immer der rausbekommt: Probier es aus. Selbst wenn ich in einem meiner Projekte mit einem ähnlichen Fall Erfahrung hätte, könnten bei dir mit anderen Eingangsparametern andere Werte rauskommen. Versuch es mit dem geringsten Aufwand zu implementieren. Austauschen gegen etwas (nachgemessen) schnelleres kann man es immer noch. (Kapselung von Funktionalitäten und eine möglichst lose Bindung zwischen ihnen erleichtern solche Refactoring-Prozesse.)

echo "$verabschiedung $name";

[Emiel]

Hi.

400 Zugriffe in welcher Zeit?

Pro Sekunde.

Möglichst wenig Datenbankabfragen kann man erreichen, indem man oft gefragtes Zeug in einem Cache ablegt. Auch für aufwendig zu berechnende Geschichten ist es günstig, das Resultat zu cachen, wenn es danach noch ein paar Mal benötigt wird.

Das Problem ist, bei 1.000.000 Threads - welche sich aktiv ständig verändern, welche Resultate soll ich da im Cache behalten? Und welchen Cache? Reverse Proxy, DB-Cache, PHP-Cache usw..

Aus dem kann ich dich auch nicht rausholen. Ich sehe diese Probleme auch, hab aber kein Rezept dagegen.

Verdammt ;).

»» Also ausgehend davon das nur der Threadersteller Bilder einbinden darf, würde ich mit Query 1:
»» Query 1: Die Thread-Informationen + Bilder + Userinfos
»» Was hälst du davon? Er darf btw. maximal 10 Bilder einbinden.

(hältst - mit zwei t) Die Thread-Information benötigst du unbedingt und nur einmal und nicht so oft wie die Bilder, von denen es 0 bis 10 gibt. Das bekommst du mit einem LEFT JOIN geregelt, also dass auch bei 0 Bildern die Thread-Daten kommen, aber bei mehr als einem Bild hast du die Threaddaten mehr als einmal abgefragt. Was ist nun effektiver, zwei Querys oder ein zweifelhafter Join und unnötig redundante Daten? Eine kleine Messreihe wird die Antwort liefern. Überhaupt ist das Messen der verschiedenen Szenarien besser als theoretische Überlegungen.

Ich denke also mal das zwei Queries besser sind.
Ich werde es am Ende einfach mal testen mit super-smach, MyBench oder der MySQL Benchmark Suite.

Ich hab mir von Jeremy D. Zawodny & Derek J. Balling "High Performance MySQL" geholt. Ich hoffe ich werde damit am Ende einiges rausholen können.

Ist es notwendig, den Kategorienbaum je Sprache extra zu verwalten? Sind die Kategorien andere und/oder anders geschachtelt, wenn die Sprache wechselt? Oder ist der Aufbau der gleiche und du hast das Übersetzungsproblem nicht nur für die Kategorien sondern auch für alles andere und brauchst allein dafür schon einen eigenständigen Übersetzungsmechanismus?

Also ich hab da noch so mein Problem mit der Sprachumsetzung aber ich gehe davon aus, das jede Sprache ihre eigene Datenbank bekommt.

Wie auch immer, die Kategorien werden sich nicht soo häufig ändern, der Nested-Sets-Aufwand wird sich vermutlich rechnen. Man könnte auch alle Pfade einmalig (nach jeder Änderung) vorberechnen. Das ergibt auch nur so viele Datensätze wie Kategorien vorhanden sind. Eine Abfrage darauf ist einfachst und ergibt stets einen Datensatz. Noch schneller wirst du es nur mit Caching hinbekommen.

Bei Caching stehe ich halt wieder völlig im zugestopften Raum. Ich weiß nicht was Cachen, wo anfangen und wann was und überhaupt. Auch das Buch das ich mir da gekauft habe, gibt mir nicht wirklich das was ich haben will.

Genauere Vorgaben lassen meinen Bauch genauer fühlen :-) Was auch immer der rausbekommt: Probier es aus. Selbst wenn ich in einem meiner Projekte mit einem ähnlichen Fall Erfahrung hätte, könnten bei dir mit anderen Eingangsparametern andere Werte rauskommen. Versuch es mit dem geringsten Aufwand zu implementieren. Austauschen gegen etwas (nachgemessen) schnelleres kann man es immer noch. (Kapselung von Funktionalitäten und eine möglichst lose Bindung zwischen ihnen erleichtern solche Refactoring-Prozesse.)

Hm ich weiß nicht was ich dir an genaueren Angaben geben könnte.
Es handelt sich um ein sehr sehr großes Projekt. Kommerziell - ich beschäme mich fast das ich hier sowas fragen muss ;). Aber man lernt schließlich mit jedem Projekt dazu.

Was ich mich aber schon immer gefragt habe: Was haben Leute aus dem Forum wie du für Projekte. So Erfahrung und soviel Ahnung. Ich mein um "erfolgreich" zu sein gehört meines Erachtens nicht hauptsächlich das Wissen wie man es technisch umsetzt, sondern vor allem eine Idee die noch keiner vorher hatte aber ich lese soviel hier in Forum, poste mal hier mal da - mit irgendeinem Nick der mir gerade einfällt und es stechen viele Leute seit Jahren ins Auge, wahasaga(oder so / ChrisB??), Sven R., du Dedlfix, Tom(der mir aber erst seit kurzem auffällt weil eher fast jeden deiner Posts kommentiert) usw..  Was hast du für Projekte? Könntest du mal deine größten nennen? Oder mir eine Mail schicken? [e-mail] (ja der Name ist kindisch, aber meine - ich melde mich überall damit an E-Mail)

Gruß, Emiel

[dedlfix]

echo $begrüßung;

Das Problem ist, bei 1.000.000 Threads - welche sich aktiv ständig verändern, welche Resultate soll ich da im Cache behalten? Und welchen Cache? Reverse Proxy, DB-Cache, PHP-Cache usw..

Mangels Erfahrung kann ich dir das nicht fundiert beantworten. Meinst du wirklich, dass ständig eine Million aktive Threads laufen oder ist das die Gesamtanzahl und die aktiven machen nur einen mehr oder weniger geringen Teil aus? Der Cache müsste dann dafür sorgen, dass die mit der meisten Nachfrage drinbleiben und die anderen aus dem DBMS geholt werden. Da erzähle ich dir sicher nichts Neues, denn so arbeiten Caches im Allgemeinen. Bei den Thread ist es vielleicht nicht unbedingt nötig, sie zu cachen, vor allem aufgrund ihrer hohen Veränderlichkeit und ihrer relativ einfachen Abfragbarkeit. Da wirst du vielleicht mit gezielter Denormalisierung etwas hinbekommen, wenn Thread nicht mehr mit den Usern gejoint werden müssen. (Siehe PDF-Dokument Flickr and PHP - "Normalised data is for sissies". Auch aus dem Rest des Dokuments kann aus der Erfahrung anderer mit einem großen Projekt lernen.) Der Cache wird eher Vorteile ausspielen, bei Daten die aufwendig berechnet werden müssen, sich aber nicht ständig ändern.

Bei Caching stehe ich halt wieder völlig im zugestopften Raum. Ich weiß nicht was Cachen, wo anfangen und wann was und überhaupt.

Jedes größere Projekt ist individuell. Man kann zwar allgemeine Grundsätze beachten, denen sollte man aber nicht blind vertrauen, sondern sich von ihrer Wirksamkeit überzeugen. Am Anfang steht vor allem die Implementation der Funktionalität. Wenn man da schon Erfahrung reinbringt ist das gut, erhöht aber nicht selten den Implementierungsaufwand. Am Ende lässt man die Funktion fallen und außer Zeit verloren hat man höchstens Erfahrung gewonnen. Die Optimierung in einem späteren Schritt vorzunehmen, wäre eine Möglichkeit. Dann sollte man die alte Funktion messen und mit der neuen Funktion vergleichen. Nicht dass man am Ende eine Bremse hinein"optimiert" hat.

Hm ich weiß nicht was ich dir an genaueren Angaben geben könnte.
Es handelt sich um ein sehr sehr großes Projekt.

Eine ungefähre Größenordnung ist immer gut. Vereinswebsite versus weltweitem Online-Handelsunternehmen - da muss man schon mit anderen Kalibern bei der Lösungsfindung rangehen.

Kommerziell - ich beschäme mich fast das ich hier sowas fragen muss ;). Aber man lernt schließlich mit jedem Projekt dazu.

Falsche Bescheidenheit führt gelegentlich zu falschen Ergebnissen.

Was ich mich aber schon immer gefragt habe: Was haben Leute aus dem Forum wie du für Projekte.

Keine so großen. Aber ich sehe gelegentlich, wenn Andere ihre Probleme und Lösungen veröffentlichen. Auch versuche ich einigermaßen den Überblick zu behalten, was es an Problemlösungsstrategien gibt. Auch die aktive Forumsteilnahme trägt bei mir zur Mehrung von Wissen und Erfahrung bei. Nicht immer weiß ich auf eine Frage eine Antwort. Doch wenn mich das Thema interessiert, forsche ich nach einer Lösung, laboriere dran rum, sammle nebenbei Wissen und Erfahrung, antworte ... und werde dann gelegentlich vergöttert :-) Doch viel mehr als der Einäugige unter den Blinden bin ich nicht.

Was hast du für Projekte? Könntest du mal deine größten nennen?

Nein, kann ich nicht, denn die sind nicht groß. Ich bin nur Hobby-Programmierer, das aber schon lange.

echo "$verabschiedung $name";