Seite 1 von 1
Datenbank-Design
Verfasst: 26.04.2004, 21:48
von warry
Hallo,
ich grüble jetzt schon ne Weile über einem neuen Projekt, habe allerdings etwas Angst vor den Ausmaßen.
Es geht darum, eine Datenbank mit ca. 1 Mio Datensätzen online zu bringen. Jeder Datensatz hat ca. 10 Felder, ein Datensatz hat ca. 1 KB.
Das ganze soll suchfähig sein (im Prinzip müßte die ganze Site aus Suchanfragen dynamisch gespeist werden). Mehrere Indizes wären wohl auch vonnöten um die Suchanfragen schneller zu verarbeiten.
Grob angepeilte Besucherzahl dürfte zwischen 5 und 10 TD pro Tag liegen, könnten aber durchaus auch erheblich mehr werden, wenn man es richtig aufzieht.
Hat von euch schonmal jemand etwas in der Größenordnung gemacht, wieviele Server würde man wohl brauchen, welches DB-System schafft das ohne stottern?
Fragen über Fragen...
Gruß
warry
Verfasst:
von
SEO Consulting bei
ABAKUS Internet Marketing Erfahrung seit 2002
- persönliche Betreuung
- individuelle Beratung
- kompetente Umsetzung
Jetzt anfragen:
0511 / 300325-0.
Verfasst: 26.04.2004, 22:14
von Nexus
Hi,
da passt in solchen Fällen eine Antwort immer am Besten: Kommt darauf an
Was für eine DB? MySQL (ja die könnte das), MSSQL, Oracle etc. Grundsätzlich sind 1 Million Datensätze nicht wirklich viel für 'ne Datenbank. Lässt sich allerdings nicht auf 'nem Standard 2&2 Gästebuch-Server realisieren.
Wieviele Tabellen hat deine DB denn? Wie komplex werden deine Abfrage (joins über wieviele Tabellen, outer joins, subqueries)?
Dann ist das Verhältnis Lese- Schreiboperation nicht zu vernachlässigen. Lesen ist bei vernünftigen Abfragen mit Indizes auf den wesentlichen Feldern sehr schnell; schreiben, besonders einfügen kann bei mehreren Indizes recht langsam werden. Und das zu umgehen könnte man Datensätze z.B. auf einem anderen Server schreiben (evt. in die gleiche Tabellenstruktur ohne Indizes) und dann nachts (bei Zugriffen hauptsächlich aus unserer Zeitzone ist statistisch gesehen ca 4. Uhr die beste Zeit dafür) die Datensätze auf den ersten Server kopieren.
Bei bestimmten DBs gibts auch einen Query-Cache, d.h. das Ergebnis einer Abfrage wird vom Server im Hauptspeicher gehalten. Wenn die gleiche Abfrage nochmals geschickt wird, wird diese gar nicht mehr ausgeführt sondern direkt aus dem Speicher zurüchgegeben. (Vorsicht: z.B. bei MySQL wird der Vergleich noch vor dem Parsen gemacht, d.h. die Erkennung der gleichen Queries ist case-sensitive.
So, dann wollen wir mal rechnen: 5-10T Zugriffe. Gehen wir mal davon aus das 30% deiner Besucher in den 3 aktivsten Stunden kommen (das kommt wiederum auf deine Zielgruppe an, solltest du mal Logs wälzen)
7500 * 30% = 2250 / 3 Stunden = 750 / 60 /60 = 0,2 Zugriffe pro Sekunde maximale Belastung.
Das sollte eigentlich jeder vernünftige Server verkraften
Mal davon abgesehen das ich bei einem solchen Teil die meisten Abfragen sowieso aus einem eigenen Cache bedienen würde...
hth
Raphael
Verfasst: 26.04.2004, 22:38
von warry
Was für eine DB? MySQL (ja die könnte das), MSSQL, Oracle etc. Grundsätzlich sind 1 Million Datensätze nicht wirklich viel für 'ne Datenbank. Lässt sich allerdings nicht auf 'nem Standard 2&2 Gästebuch-Server realisieren.
Keine Frage, ich würde dann schon in vernünftige Server investieren, MySQL hört sich schon gut an. Im Prinzip bin ich da nicht gebunden.
Wieviele Tabellen hat deine DB denn? Wie komplex werden deine Abfrage (joins über wieviele Tabellen, outer joins, subqueries)?
Ich denke 3-4 Tabellen würden reichen, bin allerdings kein DB-Spezi.
Dann ist das Verhältnis Lese- Schreiboperation nicht zu vernachlässigen. Lesen ist bei vernünftigen Abfragen mit Indizes auf den wesentlichen Feldern sehr schnell; schreiben, besonders einfügen kann bei mehreren Indizes recht langsam werden. Und das zu umgehen könnte man Datensätze z.B. auf einem anderen Server schreiben (evt. in die gleiche Tabellenstruktur ohne Indizes) und dann nachts (bei Zugriffen hauptsächlich aus unserer Zeitzone ist statistisch gesehen ca 4. Uhr die beste Zeit dafür) die Datensätze auf den ersten Server kopieren.
Im Prinzip wird nur gelesen, Updates können grundsätzlich nachts stattfinden.
So, dann wollen wir mal rechnen: 5-10T Zugriffe. Gehen wir mal davon aus das 30% deiner Besucher in den 3 aktivsten Stunden kommen (das kommt wiederum auf deine Zielgruppe an, solltest du mal Logs wälzen)
7500 * 30% = 2250 / 3 Stunden = 750 / 60 /60 = 0,2 Zugriffe pro Sekunde maximale Belastung.
Das sollte eigentlich jeder vernünftige Server verkraften
Mit Besucher waren Visits gemeint, gehen wir mal von 5 Queries pro Visit aus, da wären wir dann bei 1 Zugriff/sec
Was kann ein vernünftiger Server denn ab, wo liegen da die Grenzen?
Mal davon abgesehen das ich bei einem solchen Teil die meisten Abfragen sowieso aus einem eigenen Cache bedienen würde...
Ich merke schon, da fehlt´s bei mir an den Grundlagen, ein bischen Perl für den Hausgebrauch reicht da wohl nicht. Werde wohl einen Profi engagieren müssen, wenn ich mich dazu durchringe.
Meine Idee war 2 Server hinzustellen, einen für die DB und einen reinen Webserver, der die Seiten ausgibt.
Schonmal besten Dank für deine Tipps.
Gruß
warry
Verfasst: 26.04.2004, 23:57
von SISTRIX
1 Query pro Sekunde ist für eine MySQL-Datenbank ein Witz. Auf einem alten Server (P3 2x1.4Ghz, 1GB-Ram, SCSI) habe ich ~30 Querys pro Sekunde bei einem Load von unter 0.1. Auch sollte bei Dir das Cachen recht einfach sein (Reverse Proxy?)
Gruss Johannes
Verfasst: 26.04.2004, 23:59
von sandoba
@warry: Die Idee mit zwei getrennten Webservern ist prinzipiell nicht schlecht. Vor allem ist man dann nicht mehr an einen Datenbankserver gebunden, sondern kann diesen recht zügig austauschen.
Bei der angepeilten Nutzerzahl und dem Umfang von Datensätzen, Queries etc. würde ich weiterhin für MySQL plädieren mit PHP als Sprache. Allerdings kann bei ausreichendem Budget auch eine Oracle-DB sowie eine Realisierung in Java in Frage kommen.
Der von Nexus angesprochene lokale Cache ist für die Seite zudem auf keinenfall zu unterschätzen, denn richtig eingesetzt lässt sich damit erheblich Last vom Server nehmen. Voraussetzung ist dafür natürlich, dass nicht für jeden Nutzer die Abfragen derart personalisiert ausfallen, dass ein Cache nur für diesen Nutzer sinnvoll wäre.
Verfasst: 27.04.2004, 05:18
von innuendo
Hallo,
ich kann nur in das gleiche Horn stossen.
Ein eigener Datenbankserver und ein sinnvoller Cache der Queries bewirken Wunder in Sachen Lastverhalten am Server. Denke auch an die Zukunft und dimensioniere immer lieber etwas größer, damit du, wenn es erfolgreich ist, nicht in den Zugzwang kommst in der Eile Falsch-Entscheidungen zu treffen.
lg,
Innuendo