[php] =?iso-8859-1?Q?RE:_=5Bphp=5D_Viele_Datens=E4tze=2C_dran_teilnehmen_=3F_-_?= =?iso-8859-1?Q?Eilt.?= =?iso-8859-1?Q?Eilt.?=

[Johann-Peter Hartmann]

Hi Burkhard, hallo Liste,

> ich soll für ein Projekt eine Tabelle Teilnehmer einbinden (ca.400.000) .
> Jeder Teilnehmer hat im Schnitt 100 Einträge. Also die 2. Tabelle für
> Details hat ca. 40 Mio Einträge.
>
> Ist dies mit Mysql/PHP realisierbar ?
>
> Die Daten werden über einen Zeitraum von 5 Monaten von den Teilnehmern ,
> jeder hat nur für sich eine Berechtigung, eingegeben oder
> eingespielt. Dabei
> wird eine erste Plausibilitätskontrolle durchgeführt.
> Da aber jeder der 40 Mio. Datensätze dieser
> Plausibiltätskontrolle (Doppelte
> Einträge bei anderen Teilnehmern,...) unterliegt, dürfte schon einiges an
> Rechenzeit abverlangt werden. Dann soll nach Korrektur nochmals geprüft
> werden. Bislang ist diese Anwendung Offline in C programmiert worden
> (Annahme)
> Schafft dies überhaupt PHP ?

	Wenn PHP mit einem Zugriff jeweils nur einige 100 Daten
	(und davon ist bei Online-Anwendungen ja im Regelfalle
	 auszugehen) anfassen muss, hat es keine Probleme.

	Das Problem liegt hier IMHO mehr beim MySQL .

	MySQL kann an diesen Stellen Probleme machen :

	1. Geschwindigkeit
	Wenn grosse Mengen Daten bewegt oder rausgesucht
	werden sollen, dann dauert das lange.

	Wenn die Datei nicht nach den Abfrageparametern
	indiziert ist, dauert das laenger.
	(Dh. wenn man z.B.immer nur nach Teilnehmer und Datum
	 oder nach Teilnehmer abfragt, dann spart ein
	 Index auf Teilnehmer und einer auf Teilnehmer/Datum
	 deutlich Zeit, und die Abfrage kann halbwegs schnell
	 von statten gehen. )

	Wenn man bei grossen Abfragen Lookups auf andere
	Tabellen machen muss, dann dauert das noch viel länger.
	Wenn man also zum Beispiel jeden Teilnehmereintrag mit
	einem Schluessel kodiert, und dieser Schluessel aus einer
	Tabelle geholt werden muss, dauert es unter Umstaenden
	laenger als die Alternativlösung, bei der direkt der Wert
	hinter dem Schluessel eingetragen wird - obwohl dies
	natürlich eigentlich schöner (= normalisiert) wäre.

	40 Mio. Eintraege sind ein ganzer Haufen, und imho
	mit MySQL nicht zwangsläufig gut anzufassen.

	Meine groesste Datenbank bei MySQL waren 3,5 Mio Daten
	(für den Futurefarmer : Schlachtrohdatenauswertung
	für ein Markenfleischprogramm über 4 Jahre mit Daten
	aus 8 Schlachtstellen ) , die mit 4 Indizes versehen waren,
	und die Werte in 27 Spalten hatte.

	Eine Abfrage "Select Feld1, Feld2, Feld3, Feld4, Feld5 from
	Table where Index4='bla'" hat dabei zwischen 1 und 2 Minuten
	gedauert, je nach Menge der Daten. Das ganze ohne
	konkurrierende Abfragen, nur 1 Nutzer zur Zeit.

	Es gibt aber mit Sicherheit einen Haufen Leute hier
	auf der Liste, die schon grössere datenbanken angefasst
	haben.


	Grundsätzlich halte ich 40 Mio Datensaetze für realisierbar,
	aber ...:
	- die Daten duerfen nicht zu breit sein .
	- die Daten muessen sauber indiziert sein, und die Abfragen
	  nur anhand der Indizes stattfinden
	- Locking : zur Zeit benutzt MySQL nur Tableweite Locks, dh.
	  jeder Schreibzugriff verhindert alle Lesezugriffe und
	  umgekehrt.

	Dagegen kann man folgendes tun :

	- Die Tabellen zerlegen.
	  Aus der Tabelle mit den Einträgen z.B. 10 Tabellen machen, das
	  geht recht gut, wenn man z.B. anhand der Indizes bequem
	  10 etwa gleichgrosse bereiche finden kann.
	  Der Vorteil ist klar : Es muss jeweils nur 10 % durchsucht
	  werden, und es wird jeweils nur 10 % gelocked.
	  Allerdings muss dafuer die ganze "Welche Tabelle brauch ich
	   denn jetzt?" - Logik selbst programmieren, und es ist nicht
	  immer realisierbar.

	- Optimierung von Schreibzugriffen .
	  MySQL bietet mit "Insert delayed" und "insert low priority"
	  die Möglichkeit, Schreibzugriffe nicht gleich durchzuführen,
	  sondern auf einen gute Zeitpunkt zu warten.
	  Daneben kann man natuerlich auch Schreibzugriffe zu Gruppen
	  zusammenfassen und dann unmittelbar nacheinander ausführen
	  lassen, oder man kann jeden tag einen temporären Table mit
	  den Daten füllen, und dann nachts um 3 diesen in die
	  eigentliche Tabelle einfügen .

	- eine andere Datenbank verwenden
	  "richtige" Datenbanken unterstützen grosse Tabellen mit
	  einem Haufen von Möglichkeiten, und schieben die
	  Performancegrenze durch mehrere Recher etc. ziehmlich hoch.


	Ich würde mir vermutlich mal zwei Beispieltabellen
	mit Deinen Parametern automatisch bauen lassen, und dann
	über diese ein paar Abfragen durchmessen - damit sollte
	man ein halbwegs verlässliches Ergebnis bekommen, ob
	MySQL das abkann.

	Viele Grüße, johann