[Datenbank] Vielen Anfragen @ große Tabelle

Hi,

ich habe zur Zeit ein kleines Verständnisproblem. Und zwar bei solchen Preisvergleichsseiten wie zum Beispiel geizahls.at/de werden doch in kurzer Zeit ständig Suchanfragen an eine Tabelle geschickt (nennen wir sie mal "artikel").

Wie wird so etwas realisiert?

1. die Suche geht total schnell
2. das Ergebnis ist eine .html Seite (zB: *klick*)
   Gut, hier wirft sich mir eigentlich die wirkliche Frage auf: Jetzt kann jeder von euch auf den link klicken, es wird die gleiche Seite aufgerufen - ohne natürlich den Suchvorgang nochmal neu zu starten (ist ja quasi ein statischer Aufruf).
   Speichert Geizhals zu jeder Suchanfrage wirklich jedesmal das Ergebnis in einer .html Seite und aktualisiert diese in einem vorgegebenen Intervall, damit diese immer auf dem neusten Stand bleiben?! Eher unwahrscheinlich, schließlich sind das doch ewig viele Artikel...

Kurz zusammengefasst: Wie könnte man so etwas in der Art wie Geizhals realisieren, mit dem Zusatz, dass eine gute Performance der Seite immer bestehen bleibt?
Jedes Mal eine neue Suche über die komplette Tabelle "artikel" anzustoßen kann man sich doch nicht leisten...

1. hast du auf einen Artikel verlinkt und nicht auf eine Suche. Der Artikel ist wohl ein Eintrag in der Datenbank (verknüpft mit mehreren Anbietern etc.) und aus diesen Daten wird die Seite generiert. Hat aber nichts mit der Suche selbst zu tun. Die gewünschte Seite wird an der URL erkannt und aufgerufen.

Du kannst aber wirklich auch auf Suchen direkt verlinken: *klick*

Dabei wird die Seite natürlich nicht generiert und auf dem Server gespeichert, sondern die nötigen Information, wonach jetzt egtl. gesucht werden soll, bezieht sich der Server aus der URI, wenn du genau schaust, siehst du, dass dort die Daten, nach welchen gesucht wird, enthalten sind.

Siehe dazu auch Hypertext Transfer Protocol (HTTP) - Argumentübertragung - HTTP GET.

Erst mal danke

Die Suche an für sich ist mir klar. 'tschuldige, der 1. Beitrag von mir war echt unglücklich formuliert. Aber mittlerweile ist mir mein Problem, das ich habe, selber erst klar geworden.


Nämlich:

Kamikatze schrieb:

1. hast du auf einen Artikel verlinkt und nicht auf eine Suche.

...

Die gewünschte Seite wird an der URL erkannt und aufgerufen.

Zum Vergrößern anklicken....

Ja. Aber existiert für jeden Artikel eine Seite bereits auf dem Server? Wird diese dann im - beispielsweise - zwei Stunden takt aktualisiert mit den neuen Preisen der Shops, die in der Zwischenzeit von den Shopbetreibern hochgeladen worden sind?
Mir will nicht in den Kopf, was der Server macht, wenn ihr auf den Link von dem Artikel klickt Na gut, er ruft die Seite auf, das ist mir klar Aber wie kommt er zu der Seite?

Bei der Suche werden die Links aus ID`s zusammengebaut, die eindeutig auf dieses Produkt verweisen.
Und wenn man auf einen Link klickt und die HTML Datei nicht existiert oder veraltet ist, wird man auf die
PHP Seite weitergeleitet wo dann die Daten neu aus der Datenbank geladen werden.
Und die HTML Seite wird neu gespeichert. Somit ist die Seite immer Aktuell.

Grüße

tewes

Hi,

1. hast du auf einen Artikel verlinkt und nicht auf eine Suche.

Zum Vergrößern anklicken....

Wer sagt dir denn, dass die .html nicht über php/perl/asp oder was auch immer laufen lassen. Reintechnisch ist das kein Problem, ist ne Zeile in der Apache-Config.

@topic:
Wenn du Content hast der fast keine Schreibvorgänge hat aber enorm viel read-only-Zugriffe, dann geht das relativ einfach, dafür gibts mehrere Methoden. Was man macht hängt von der jeweiligen Seite ab. Beispiele:

1: Viele Server. Man hat z.B. 1 SQL-Master und Dutzende Slaves. Alle rw-Anfragen gehen an den Master, read geht an die Slaves. Die load bei Lesen steigt fast linear mit der Anzahl der Slaves.
Vorteil hier: alles wird realtime generiert
Nachteil hier: Braucht realtiv viele Rechner

2: Die Seiten liegen statisch vor und werden nur neu genieriert wenn Sie nicht da sind. Man verlinkt direkt auf die html-Seiten. Wenn eine Seite nicht da ist wird die Error-Seite 404 rausgegeben. Diese generiert dann die fehlende Seite und speichert Sie auf dem Server und redirected oder included selbige. Bei nächsten Aufruf ist die Seite dann direkt erreichbar. Wenn sich der Inhalt der Seite ändern soll löscht man Sie einfach, dann wird sie beim nächsten Aufruf neu generiert.

3: Man benutzt einen Proxie. Die Anfragen gehen nicht an den Webserver sondern an einen Proxie. Dieser cached alles mögliche und die Webserver müssen nur beantworten was abgelaufen oder nicht im Cache ist.

Vorteil bei 2+3: relativ wenig Rechenleistung notwendig
Nachteil: Man muss sicherstellen, dass keine Veralteten Seiten ausgegeben werden.

Gibt sicher noch massig anderer Tricks mit denen man sowas realisieren kann, aber zumeist klappt das alles nur wenn nicht schreibend auf eine DB zugegriffen wird. Für ein Forum z.B. kannste das idR vergessen.

Die zweite Lösung hat mich wirklich nennenswert weiter gebracht. Super Vorschlag! Danke