RootForum Community

hi!

Ich möchte eine Datenbank anlegen (unter für "privat-homepage-verhältnisse" extremen Bedingungen)

vielleicht kann mir jemand sagen ob es sinn macht und welche performance bei welcher datenbank zu erwarten ist? =)
(Außer ein paar vorlesungen über MySQL datenbanken und Kleinstanwendungen habe ich bisher keine erfahrungen mit datenbanken)

Szenario:
ich hab einen Server mit ca 3TB, ca. 50millionen files ca 50% *.htm und 50% *.jpg/gif. ca 1Million Pageviews/Tag
Die liegen einfach lose in /var/www/ auf der festplatte
Die inhalte sind soweit statisch und eine abgeschlossene sammlung die sich nicht mehr verändert. Soweit sogut.

Nun würde ich gerne eine Datenbank anlegen um u.a die Möglichkeit zu haben dass user einzelen files bewerten können und solche melden können, die gegen die Nutzungsbedingunen verstoßen oder ihnen kategorien (Tags) zuordnen.

Sprich eine datenbank mit ca 50Millionen datensätzen.

und es stellt sich die frage ob es sinn macht, die kompletten datein, welche durschnittlich nur wenige Kilobyte groß sind, in die Datenbank zuschreiben?

Welche performance ist bei diesem Vorhaben zu erwarten wenn ich einfach mal anfange mit php & mysql?

danke

BLOB- oder TEXT-Felder in einem RDBMS abzulegen ist grundsätzlich ineffizient. Grundsätzlich deshalb, weil ein RDBMS von der Philosophie her Datensätze verwaltet. Bei Datensätzen geht man von gleichgestaltigen Daten aus, die sich nur im Inhalt unterscheiden. Das ist bei BLOBs oder TEXT-Feldern nicht gegeben: Allein die Länge der Daten variiert (zumeist deutlich). Daraus resultiert auch, dass BLOB- oder TEXT-Felder in den meisten RDBMS-Implementierungen deutlich benachteiligt gegenüber VARCHAR- oder numerischen Feldtypen sind (z. B. schlechtere Indizierung, kein Caching von Abfragen, an denen BLOBs beteiligt sind, temporäre Tabellen nicht im RAM, ...)

Die beste Datenbank für Dateien ist und bleibt eben das Dateisystem. Meta-Daten zu den Dateien kann man aber durchaus in ein RDBMS packen. Wenn auch hier eine starke Varianz des Datenumfangs auftritt, wäre ggf. aber ein dokumentenorientiertes DBMS wie CouchDB die effizientere Lösung.

danke soweit!
klingt als ob die kompletten datein mit in die datenbank zu packen mit mysql (=kostenlos) nichts wird.

dann speicher ich eben nur die durchschnittliche bewertung einer datei und ob sie freigegeben oder gesperrt ist in der datenbank usw.

aber wie kann ich alle zugriffe über ein (php-)script umleiten?
es gibt bisher folgende mögliche datei zugriffe die lose im apache www ordner liegen

• meineseite.tld/abc.html
• meineseite.tld/001.jpg
• meineseite.tld/download1.zip
  aber auch
• meineseite.tld/unterordner/ (= meineseite.tld/unterordner/index.htm oder html)
  (auch die apache indexer funktion verwende ich für einige unterordner, ist aber nicht unbedingt nötig.)

in Zukunft müssen alle Anfragen über ein (php-)script geleitet werden
damit das script also anhand von den parametern aus der datenbank(mysql)
die bewertung der datei in die erste Zeile schreiben kann und
entscheiden kann ob die seite das bild überhaupt angezeit werden darf.
oder diese verweigert werden soll.

apache konfiguration:
RewriteRule ^(.*)$ /var/www/script.php?pfad=%{SCRIPT_FILENAME}

/var/www/script.php:
$pfad = $_GET['pfad'];
(....läd datenbank-paremeter für $pfad und zeigt durschnittliche bewertung an etc...)
wenn zulässig:
include("/var/www/".$pfad)

das funktioniert schonmal für alle
meineseite.tld/abc.html aber die bilder auf den seiten fehlen natürlich
bilder und downloads gibts nur in textform im browser angezeigt und
meineseite.tld/unterseite/ geht natürlich auch nicht :/

weiss grade überhaupt nicht wie/ob ich da zum ziel komme.
aber mir fällt sonst nichts ein. irgendwie sollte es das doch einfach gehen?

vielen dank nochmal.... =)

matzewe01 wrote:BTW: Oracle XE gibt es auch kostenlos!
Zudem ist Mysql nicht pauschal kostenlos.
Wenn Du einen entsprechenden support willst, kostet das auch Geld.

Bei Oracle XE ist auch kein Support drin; selbst bei Enterprise musste man den AFAIR zur Lizenz noch dazu kaufen.

Oracle 10g Express Edition wrote:Oracle Database XE can be installed on any size host machine with any number of CPUs (one database per machine), but XE will store up to 4GB of user data, use up to 1GB of memory, and use one CPU on the host machine.

4GB sind deutlich weniger als die o. g. benötigten knappen 4TB... XE ist zum entwickeln (v. a. Application Express) ganz nett, aber schon bei Lasttests muss man eigentlich die SE haben.

Wenn es keinen Weg darum herum gibt, Binärdaten in einem RDBMS zu verwalten, würde ich derzeit zu PostgreSQL 8.4 raten. Dort werden BLOBs in Stripes abgelegt, die wiederum B-Tree-indiziert werden. Außerdem erlaubt die API von PostgreSQL, auf BLOBs wie auf einen Stream zuzugreifen. Gerade wenn man große Dateien über's Netz schicken will, erleichtert das die Programmierung deutlich, da man nicht selbst partitionieren muss. Details gibt es hier.

matzewe01 wrote:

jfreund wrote:aber schon bei Lasttests muss man eigentlich die SE haben.

Da muss ich Dir wiedersprechen. die Oracle XE bietet den gleichen Funktionsumfang wie eine SE oder SE One. Lässt sich also auch entsprechend "stabil" und Performant betreiben.

Nun muss ich Dir widersprechen: die XE bietet (annähernd) denselben Funktionsumfang wie die 10g Release 2. Für kleine Anwendungen macht das aber kaum einen Unterschied; APEX kann man ja schließlich upgraden.

Worauf ich mich bezog: Wenn man wirklich Performance-Daten gewinnen möchte, taugt die XE nicht viel, da sie genau in den Punkten eingeschränkt ist, die dafür relevant sind: CPU-Nutzung (nur ein Kern), RAM (nur 1GB) und Datenbankgröße (4GB). Aus Tests mit einer XE kann man daher nur sehr schlecht schließen, wie eine Applikation auf einer SE performt, die auf etwas dickerem Blech (z. B. 8 Kerne und 32GB RAM) rumturnt und mehr als nur ein paar Gig Testdaten im Bauch hat.

matzewe01 wrote:Bezüglich 4GB viel kleiner als 3 TB.
Er soll ja nicht die Dateien in die DB schieben. Das ist für seinen Anwendungsfall, offen gestanden, auch ziemlich unsinnig. Egal ob nun auf Postgres, Oracle Mysql oder auch MS SQL.

Full ACK, Dateien in DB ist Unsinn (zumindest in diesem Fall). Mein Posting bezog sich ja nur darauf, was wäre, falls der OP doch auf seine ursprüngliche Idee zurückkäme