MySql - wie der Geschwindigkeitsgewinn gegenüber Texdatei zustande kommt

[GoodFella]

[18:12] <Sawfish> hast du schon öfters mit datenbanken gearbeitet?
[18:12] <GF> erstes mal mit DBI
[18:12] <GF> ansonsten immer mit textdbs
[18:13] <GF> aber das schon sehr lange
[18:13] <Sawfish> ok, dann is auch klar warum du das so machst ^^
[18:13] <GF> ich weiss, wies anders geht
[18:13] <GF> aber dann bräuchte ich einen weiteren table
[18:13] <GF> aber das wollte ich nicht
[18:14] <GF> ich hab lieber alle wichtigen infos auf einem fleck
[18:14] <GF> mag zwar performance kosten, dafür reduziert es aber bugs
[18:15] <Sawfish> mehrere datensätze sollten nicht in der selben spalte stehen, das is unsauber
[18:15] <Sawfish> ich würd in der tabelle news einfach eine zusätzlich spalte mit spielerid machen
[18:15] <GF> das hatte ich auch zuerst
[18:15] <GF> aber überleg mal
[18:16] <GF> wenn du die newslist anzeigen willst
[18:16] <Sawfish> jo
[18:16] <GF> musst du die ganze Table News nach (=ownerid) durchsuchen
[18:16] <GF> wenn du die liste aber schon hast, entfällt das suchen
[18:17] <GF> da die table news bei 34k spielern recht gross wird, ist das ein riesiger Performancegewinn
[18:17] <Sawfish> ich mach: select * from news where ownerid=1234
[18:18] <Sawfish> das gibt mir alle news des spielers zurück
[18:18] <Sawfish> das is viel schneller als wenn ich lauter einzelne select * from news where id=xxx mach
[18:20] <GF> hmmmmm
[18:21] <GF> ok
[18:21] <GF> machs so
[18:22] <GF> hmmmm
[18:23] <GF> select * from news where id=xxx
[18:24] <GF> das ist ein zugriff
[18:24] <GF> die genaue adresse ist ja bekannt, die ist id * datensatzgrösse
[18:24] <GF> also kein suchen
[18:25] <GF> select * from news where ownerid=1234 <--- das sind im schlechtesten fall 34k*maxnews zugriffe
[18:25] <Sawfish> <@GF> die genaue adresse ist ja bekannt, die ist id * datensatzgrösse <-- wirklich?
[18:25] <GF> ja
[18:26] <GF> hab einiges gelesen über relationale Datnebanksysteme
[18:26] <GF> der zugriff erfolgt über ine lineare Funktion
[18:26] <GF> deshalb ist das auch so schnell
[18:26] <Sawfish> kannst mir zeigen wo das steht?
[18:26] <GF> und deshalb gibt es auch nur statische typen
[18:26] <GF> hmmmmmmm
[18:26] <GF> ich such mal
[18:26] <GF> ist ewig her, bestimmt 1/2 Jahr
[18:27] <Sawfish> hast auch über die Normalformen gelesen?
[18:27] <GF> nicht dass ich mich erinnern kann
[18:28] <GF> aber erzähl mal
[18:28] <Sawfish> les dir das mal durch wennst zeit hast: http://de.wikipedia.org/wiki/Normali...28Datenbank%29
[18:28] <GF> ich lass mich gerne belehren
[18:28] <GF> solange ich was dabei lerne
[18:29] <Sawfish> wennst das noch nicht weißt, lernst sicher was dabei
[18:29] <Sawfish> aber such trotzdem weiter
[18:35] <GF> hmmm
[18:36] <GF> was da steht, ist nicht übertragbar auf unser problem
[18:37] <Sawfish> naja, die datenbank sollte den normalformen entsprechen
[18:37] <GF> anomalien könne hier nicht auftreten
[18:37] <GF> *können
[18:38] <GF> und vor allem: das sagt nichts darüber aus, wie schnell bestimmte abfragen sind
[18:38] <Sawfish> anomalien können immer auftreten
[18:38] <GF> ich habe hier keinen zweiten schlüssel, nur werte
[18:38] <Sawfish> <@GF> und vor allem: das sagt nichts darüber aus, wie schnell bestimmte abfragen sind <-- das nicht, das stimmt
[18:39] <GF> hmmm
[18:39] <Sawfish> z.b. könnte es so passieren, dass 2 spieler die selbe news id in ihrer liste haben
[18:39] <GF> kann den beitrag nicht finden
[18:39] <Sawfish> oder dass ein news eintrag keinen besitzer hat
[18:39] <GF> hä? wìe?
[18:40] <GF> das könnte nur dann passieren, wenn schlecht gecoded wird
[18:40] <Sawfish> genau dann kann es passieren
[18:40] <GF> bei mir wird aber nicht schlecht gecoded
[18:40] <GF> und mal zum Thema Geschwindigkeit
[18:41] <GF> das kann man auch durch nachdenken herausfinden
[18:41] <GF> 1. Jeder Datensatz hat eine feste Grösse
[18:41] <GF> richtig?
[18:41] <Sawfish> eine saubere datenbank muss so designed sein, dass solche dinge garnicht auftreten können
[18:41] <Sawfish> nicht unbedingt
[18:42] <Sawfish> es gibt auch datentypen mit variabler breite
[18:42] <GF> wenn das nicht so ist, hat Mysql keinen vorteil gegenüber ner textdatei
[18:42] <Sawfish> doch, das hat noch einige andere vorteile...
[18:42] <GF> ja schon, aber die haben trotzdem eine feste grösse .. du meinst varchar() etc..
[18:42] <Sawfish> jo z.b.
[18:42] <GF> aber erstmal angenommen, jeder datensatz hat eine feste grösse
[18:43] <Sawfish> k
[18:43] <GF> und 2. jeder datensatz hat seinen festen platz
[18:43] <GF> => id 2 kommt nach 1
[18:43] <GF> etc etc..
[18:44] <Sawfish> muss ich das jetzt auch annehmen?
[18:44] <GF> wie findet man dann den speichertanfangsort des n-ten datensatzes?
[18:44] <GF> `jo
[18:45] <Sawfish> pointer = start + n*size
[18:45] <GF> genau
[18:45] <Sawfish> von dem zweiten kannst aber nicht ausgehen
[18:45] <GF> ich dachte immer, genau das wäre der geschwindigkeitsvorteil gegenüber suchen
[18:46] <GF> soso, also heisst mysql suchen wie in einer textfile?
[18:46] <Sawfish> dann müssten alle news von 1 bis n immer in der datenbank bleiben
[18:46] <GF> naja
[18:47] <GF> vielleicht gibt es ja so eine art id->speicherort zuordnungstabelle
[18:47] <Sawfish> vielleicht ^^
[18:47] <GF> hehe
[18:47] <GF> mir reichts, ich werd mal in nem Forum fragen
[18:48] <Sawfish> gut

Vielleicht kann uns jemand genaueres sagen

PS: Edit: Code durch Quote ersetzt, da schwer lesbar

[RFC822]

Es gibt Datensätze mit variabler und mit fester Größe. Das spielt aber wenig Rolle, da man sowieso Indizies verwendet und die immer eine fixe Größe haben und sortiert sind (bzw. schnell durchsuchbar, zB mit B-Trees).

Wenn man eine SQL-Abfrage wie SELECT * FROM news WHERE owner=123 macht, sollte man einen Index für "owner" anlegen. Dieser wird dann schnell durchsucht und findet die Datensätze, ohne die ganze Tabelle zu durchsuchen.

Stichwörter für mehr Infos:
* Index, Indizes
* B-Tree
Siehe auch Dokumentation von MySQL und anderen DB-Servern. Bei MySQL kannst du dir mit EXPLAIN SELECT * FROM news WHERE owner=123 anzeigen lassen, was der Server genau tut und welche Indizes er (nicht) verwendet. In der MySQL-Dokumentation gibt's ein eigenes Kapitel über Tabellen- und Abfrageoptimierung, da werden Indizies genau behandelt.

[native]

Salve,

du benutzt Dateien?!
Da dauert nur schon das oeffnen und lesen laenger, als die Benutzung einer DB
Mit den IDs, es ist voellig egal, wie die Nummerierung ist also es muss nicht durchgehend sein - was ist, wenn du einen Datensatz loeschst?!
Allg. werden die Datensaetze als Baeume dargestellt, dabei gibt es Baeume welche speziell fuer Suchen konzepiert sind.
Schau dir mal B-Baeume von Bayer an.

gruss

n

// edit:
RFC822:

also schau dir mal DB genauer an, nur zu empfehlen!

[GoodFella]

erstmal danke für die schnelle Antwort, RFC

konkret ging es darum:

Table data:
Primary key ist id, dann gibts da noch ein feld "news" mit den news-ids kommagetrennt. Der aktuelle Datensatz ist global im script verfügbar.

Table news:
Primary key ist id. Es sind sehr viele Datensätze vorhanden.

Ìst ein
"select * from news where ownerid=123" (suche nach nicht primary key) schneller oder ein mehrfaches
"select * from news where id=..." (suche nach primary key),
wobei die ids aus dem feld der table data verwendet werden ?

..

[GoodFella]

Salve,

du benutzt Dateien?!
Da dauert nur schon das oeffnen und lesen laenger, als die Benutzung einer DB
Mit den IDs, es ist voellig egal, wie die Nummerierung ist also es muss nicht durchgehend sein - was ist, wenn du einen Datensatz loeschst?!
Allg. werden die Datensaetze als Baeume dargestellt, dabei gibt es Baeume welche speziell fuer Suchen konzepiert sind.
Schau dir mal B-Baeume von Bayer an.

gruss

n

// edit:
RFC822:

also schau dir mal DB genauer an, nur zu empfehlen!

Ich benutze keine Dateien, hatte mich nur für die Mechanismen hinter dem Geschwindigkeitszuwachs interessiert, danke für deine Antwort.

[RFC822]

=> Einfach für ownerid einen Schlüssel anlegen, dann wird das sicher schneller als lauter einzelne Primärschlüssel-Abfragen.

Du willst aber trotzdem keine kommagetrennten Werte in der data-Tabelle haben (ich spreche aus Erfahrung - hab unlängst ein altes kommaverseuchtes System von mir in Ordnung bringen dürfen), sondern für jeden Wert eine eigene Zeile. Also kein

ID | Werte
---|-------
 1 | a,b,c

sondern

ID | Wert
---|-------
 1 | a
 1 | b
 1 | c

Dazu einen nicht-eindeutigen Schlüssel auf ID, dann kannst du dir mit SELECT Wert FROM tabelle WHERE ID=1 alle Werte holen. Scheint umständlicher zu sein, ist aber mindestens genauso schnell und VIEL übersichtlicher. Außerdem kannst du dann später kompliziertere Abfragen basteln, was sonst nicht geht (SQL kann kein vernünftiges explode()).

[GoodFella]

explode ist schon gecoded, genauso wie ein implode Für mich ist deine Methode un-intuitiver, aber ich werd mal etwas googlen und mehr lesen. Vielleicht wird mir dann einiges klarer.

Also du sagst, ein "Select Nichtprimärschlüssel", der 35k Datensätze durchwühlt ist schneller als ein paar (max.50) "Select Primärschlüssel", die Sofortzugriff haben? Seh ich das richtig?

[destructor]

Sehr wahrscheinlich ja.

Das kommt daher, dass wie bereits erwähnt die Indices in speziellen Datenstrukturen gehalten werden, die für die schnelle Suche optimiert sind. Zudem werden die Daten da drin auch noch sortiert gehalten, was die Suche weiter beschleunigt (mal grob gesprochen: du suchst nach "Hans", dann muss die DB nur alle Werte größer gleich "Ha..." und kleiner "Hb..." durchsuchen)

Die DB sucht dann eben in dieser Datenstruktur und findet da drin dann gleich die Position der Daten in der Datei (oder eben den Primärschlüssel - wasweisich wie das intern von den DBs gehandhabt wird)

Zudem kann man wie hier ja auch schon erwähnt nur mithilfe eines Primärschlüssels nicht direkt auf eine Zeile 'springen', weil der Primärschlüssel ja auch Löcher haben kann oder die Datensätze unterschieldlich lang sind - eine Formel ala Position = n * size funktioniert also nicht.