nicht angemeldet
Indizierung + Performance
Matrix-Performance
Hallo zusammen,
habe eine Frage bzgl. der Indizierung bzw. performanten Umsetzung einer Matrix in MySQL
Beispiel:
Ich habe eine Tabelle "Personen"
id name
--------------
1 Peter
2 Horst
3 Heidi
usw.
Und ich habe eine Tabelle in der festgehalten wird, in welchem Verhältnis diese Personen zu einander stehen "verhaeltnisse"
p1 verhaeltnis p2
------------------------------------
1 mag 2
2 kann nicht leiden 1
1 liebt 3
2 liebt 3
3 liebt nur 2
usw.
Mit jedem "Scriptaufruf" wird eine gewisse Anzahl an Verhältnissen zur Weiterverarbeitung aufgerufen, d.h. z.B.
SELECT verhaeltnis FROM verhaeltnisse WHERE (p1 = 1 AND p2 = 3) OR (p1 = 2 AND p2 = 3) OR (p1 = 3 AND p2 = 1)
Mit jedem "Scriptaufruf" ändert sich einige Verhältnisse d.h. ein "UPDATE" wird auf die Tabelle angewendet.
Bei einer großen Anzahl N von Personen gibt es demnach bis zu (N^2 - N) Einträge in der Verhältnisse-Tabelle, bei 10.000 wären dies also satte 99990000 Einträge.
1. Frage: Gibt es einen anderen Weg eine solche Matrix zu erstellen, ohne dass die Tabelle so groß wird?
2. Frage: Wenn man eine solch große Tabelle benutzt, ist natürlich eine sinnvolle Indizierung zwingend. Laut Referenz soll man "abwägen" welche Spalten zur Indizierung sinnvoll wären. Klar könnte ich einfach p1 und p2 nehmen, aber: Da bei jedem Scriptaufruf sowohl ein SELECT (mag Indizes, weil es dadurch viel schneller wird) als auch ein UPDATE (mag keine Indizes, weil es jedesmal den Index neu schreiben muss) anfallen - was wäre denn nun die sinnvollste Indizierung einer solchen Matrix? Hat da jemand Erfahrungswerte oder weiss, wie man die Performance vergleicht zwischen dem, was man bei Suche durch Indexe spart und dem was man beim Updaten wieder einbüßt?
Danke und Gruß,
Matzze
-
你好 Matzze,
- Frage: Gibt es einen anderen Weg eine solche Matrix zu erstellen, ohne dass die Tabelle so groß wird?
Mir würde jetzt konkret keine andere Möglichkeit einfallen.
- Frage: Wenn man eine solch große Tabelle benutzt, ist natürlich eine sinnvolle Indizierung zwingend. Laut Referenz soll man "abwägen" welche Spalten zur Indizierung sinnvoll wären. Klar könnte ich einfach p1 und p2 nehmen, aber: Da bei jedem Scriptaufruf sowohl ein SELECT (mag Indizes, weil es dadurch viel schneller wird) als auch ein UPDATE (mag keine Indizes, weil es jedesmal den Index neu schreiben muss) anfallen - was wäre denn nun die sinnvollste Indizierung einer solchen Matrix? Hat da jemand Erfahrungswerte oder weiss, wie man die Performance vergleicht zwischen dem, was man bei Suche durch Indexe spart und dem was man beim Updaten wieder einbüßt?
Naja, ich an deiner Stelle würde einen kombinierten Index über p1 und p2 erstellen. Also nicht zwei einzelne Indizes, sondern einer über beide Spalten.
Denn m.E.n. ist deine Abfrage immer abhängig von sowohl p1 (als erstes Kriterium) als auch von p2 (als zweites Kriterium) und ist damit prädestiniert für diese Art von Index.
再见,
克里斯蒂安--
http://wwwtech.de/
<Tim> Ich bin nicht hier, um zu helfen. Mir hilft ja auch keiner. Sogar mein Brötchen muss ich mir jetzt selber schmieren.
Kompromisse und andere Widerlichkeiten – Hochzeit mit Flitterwochen
-
Naja, ich an deiner Stelle würde einen kombinierten Index über p1 und p2 erstellen. Also nicht zwei einzelne Indizes, sondern einer über beide Spalten.
Denn m.E.n. ist deine Abfrage immer abhängig von sowohl p1 (als erstes Kriterium) als auch von p2 (als zweites Kriterium) und ist damit prädestiniert für diese Art von Index.
Ja, wäre auch mein Ansatz gewesen, der kombinierte Index könnte dann ja sogar auch unique sein.
Hab nur leider in der MySQL-Referenz schwer rausfinden können, wie performance-aufwändig in dem Fall dann ein INSERT oder UPDATE (resp. "REPLACE") sein würde. Vielleicht hilft mir ja EXPLAIN weiter, ich check das mal.
Danke dennoch!
-
你好 Matzze,
Hab nur leider in der MySQL-Referenz schwer rausfinden können, wie performance-aufwändig in dem Fall dann ein INSERT oder UPDATE (resp. "REPLACE") sein würde. Vielleicht hilft mir ja EXPLAIN weiter, ich check das mal.
Ich glaube, du liegst der Fehlinformation auf, dass Indizes prinzipiell schlecht sind für INSERT oder UPDATE. Das ist nicht der Fall. Je nachdem, wie viele Datensätze ein UPDATE betrifft, kann ein Index sogar ein massiver Gewinn sein – denn auch hier muss ja das WHERE ausgewertet werden. Ähnlich beim INSERT: ein Index kann z. B. dann förderlich sein, wenn Constraints beachtet werden müssen, etwa ein Unique.
再见,
克里斯蒂安--
http://wwwtech.de/
Death is God's way of telling you not to be such a wise guy.
Kompromisse und andere Widerlichkeiten – Hochzeit mit Flitterwochen
-
-
moin,
- Frage: Gibt es einen anderen Weg eine solche Matrix zu erstellen, ohne dass die Tabelle so groß wird?
nicht wirklich, du brauchst ja all diese informationen. insofern müssen sie auch rein in die datenbank. was man machen könnte wäre eine partitionierung, das heißt in teilbereiche aufteilen.
- Frage: Wenn man eine solch große Tabelle benutzt, ist natürlich eine sinnvolle Indizierung zwingend.
eine nicht ganz richtige aussage. die frage ist nicht nur, ob die tabelle gross ist, sondern welche anweisungen du dort ausführst. wenn du zum beispiel immer alle datensätze ändernst oder selektierst, dann bringt dir ein index wenig, egal wie große die tabelle ist.
Da bei jedem Scriptaufruf sowohl ein SELECT (mag Indizes, weil es dadurch viel schneller wird) als auch ein UPDATE (mag keine Indizes, weil es jedesmal den Index neu schreiben muss) anfallen - was wäre denn nun die sinnvollste Indizierung einer solchen Matrix?
erst einmal stellst sich die frage, ob man das SELECT vorher überhaupt braucht und nicht gleich ein update machen kann. das hängt von dem jeweiligen fall ab. und auch bei einem update kann ein index, sehr viel bringen. so wie bei den abfragen hängt dies aber sehr stark davon ab, wie das update genutzt wird.
oder mit anderen worten, tuning ist eine sehr individuelle sache, je mehr infos man hat, desto besser.
Ilja