MySQL View oder 'pysikalische' Tabellen als Quelle verwenden?

Installation und Anwendung von Datenbankschnittstellen wie SQLite, PostgreSQL, MariaDB/MySQL, der DB-API 2.0 und sonstigen Datenbanksystemen.
Antworten
kaineanung
User
Beiträge: 145
Registriert: Sonntag 5. April 2015, 20:57

Hallo Leute,

ich hätte da mal eine Verständnisfrage die ihr mir vielleicht beantworten könntet.
Es ist mehr eine allgemeine Datenbankfrage als eine Python-Spezifische. Dennoch betrifft es auch die Python-Programmierung bzw. dessen Performance.

Ich habe 2 Python-Parser die mir Daten aus verschiedenen Quellen parsen die jedoch miteinander zusammenhängen bzw. von der Tabellen-Struktur identisch sind. Der Sinn des ganzen: keine Quelle bietet alle Informationen an die ich benötige, zusammen bietet diese jedoch alles was ich benötige.
Dafür habe ich ein Tool geschrieben welches die Daten 'synchronisiert' bzw. eine Auflösungstabelle wo die Foreign-Key untereinander zugeordnet sind.

Ich parse also diese beiden Quellen in jeweils dazugehörige Tabellen in meiner MySQL-DB.

src1.adresse & scr2.adresse
...
src1.tabelle1 & src2.tabelle2
..
usw.

Die Daten sind nun auch synchron so daß ich über die jeweiligen Auflösungstabellen (z.B. src1.name_assign) die zugehörigen Tabellen miteinander verknüpfen bzw. 'joinen' kann.

Jetzt habe ich ein Projekt welches auf den gemeinsamen Datenbestand zugreifen soll.
Dabei stellt sich mir nun die Frage ob es performancetechnisch große Unterschiede gibt wenn ich den Datenbestand als View dem Proejt anbiete oder sollte ich die verknüpften Daten in eine neue Tabelle schreiben lassen damit diese physikalisch in der Datenbank liegen mit eigenen Indizies und der Gleichen?

Dafür müsste ich regelmäßig (entweder zeitlich oder ereignisgesteuert) neue Daten, die per Parser in die dazugehörige Tabellen gekommen sind und auch verknüpft wurden (dafür gibt es ein Feld in der Auflösungstabellen welches besagt ob verknüpft oder noch nicht) automatisch in die nun neue dritte Tabelle einfügen. Bei einem View hätte ich diesen Umweg nicht. Ich brauche aber Geschwindigkeit und somit nun die Frage an euch:
Wie würdet ihr das machen oder, an die die schon vor dieser Frage standen, wie habt ihr dies gemacht?


Kurz und Bündig:
Performance -> View oder lieber echte Tabellen in der DB als Grundlage für Programme die darauf aufsetzen?

Was wahrscheinlich noch hinzukommt: das Programm kann komplexer werden und sicherlich auch wieder Verknüpfungen nutzen wollen. Das wolltei ch noch erwähnt haben.
Sirius3
User
Beiträge: 17710
Registriert: Sonntag 21. Oktober 2012, 17:20

@kaineanung: um was konkret sagen zu können, müßte man die Tabellen und ihre Abfragen kennen. Vom Programm her sollte alles transparent sein, das heißt, Du kannst mit einem View anfangen und wenn es irgendwann sinnvoller ist, Tabellen zu erzeugen, dann läßt man mit Hilfe von DB-Triggern die Tabelle erzeugen. Wenn Du Performance wirklich brauchst (was ich aber bezweifle), dann ist eine SQL-Datenbank das falsche Werkzeug.
kaineanung
User
Beiträge: 145
Registriert: Sonntag 5. April 2015, 20:57

@sirius3

Stimmt auch wieder. Aus einem View eine Tabelle zu erstellen ist schnell geschehen.
Dennoch würde ich gerne wissen was so eure Erfahrungswerte zu diesem Thema sagen.
Ich gehe davon aus das Views langsamer sind. Aber wie viel langsamer? Ist es nur messbar langsamer oder fühlt man es sofort wenn ich mehrere zehntausend Datensätze habe (oder gar mehrere hunderttausend) die miteinander über ca. 6 JOINS (4x 1:1, 2x 1:n) verknüpft sind und dies als Main-Source für z.B. ein PHP-Projekt zur Verfügung gestellt wird? In diesem 'darauf gesetzten' Projekt wird es sicherlich auch weitere 'internen' Verknüpfungen geben. Dabei rede ich nur vom ersten View. Es wird dann auch viele andere geben (eben viele virtuelle Tabellen).


Und was die Schnelligkeit angeht: man programmiert ja erst einmal so als ob, übertrieben dargestellt, Millionen Zugriffe gleichzeitig benötigt werden.
Wenn es viel weniger sind ist es ja ok. Wenn es aber doch viele werden sollten, will man nicht dann nachträglich große Umstrukturierungen machen müssen damit es erträglich von der Geschwindigkeit wird.

Mal salopp gefragt: wenn man große Geschwindigkeit haben will, auf was setzt man dann wenn nicht auf eine SQL-Datenbank?
Sequentielle Daten auf der Festplatte wohl eher nicht. Aber ich frage mich was dann?
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

Die Erfahrung sagt: du wirst überrascht sein, wo die Performance klemmt.

Soll heißen: Korrektheit und Einfachheit sind bei der Programmierung oberstes Gebot. Solche vorauseilenden Optimierungen ohne zu wissen, ob es da wirklich hakt, machen Arbeit, den Code undurchsichtiger, und sind im Zweifel gar kontraproduktiv.

Das man nicht vollkommen bescheuerte Entscheidungen trifft ist davon unberührt.
Benutzeravatar
noisefloor
User
Beiträge: 3843
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,
Und was die Schnelligkeit angeht: man programmiert ja erst einmal so als ob, übertrieben dargestellt, Millionen Zugriffe gleichzeitig benötigt werden.
Nee, macht man nicht. Man programmiert so, dass es sinnvoll und "sauber" ist. Im Vorfeld optimieren ist nicht gut, weil "premature optimization is the root of all evil" :-)

Bei RDBMS kann man ja in der Regel "slow queries" mit den Bordmitteln der DB ermitteln. An dem Punkt bist du aber noch nicht. Außerdem kann man bei DB-Server über die Hardware noch ein bisschen was machen. Bei RAM gilt immer noch: viel hilft viel. Wenn dein DB-Server die Daten z.B. komplett im Speicher halten kann Danke genug RAM, dann bis du auch schon mal schneller als bei viel I/O auf der Platte. Wenn du eine SSD hast bist du auch schneller als bei einer konventionellen HDD.

Gruß, noisefloor
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

Nachtrag: Geschwindigkeit kann zB durch NoSQL Datenbanken erzeugt werden. Aber nochmal: die wenigsten Leute, die Big Data Vorgehen einsetzen, haben Big Data Probleme. Ein paar hunderttausend oder Millionen Einträge sind Pillepalle, und bis eine Postgres wirklich ausgereizt ist, muss man sich schon ganz schön Mühen. Dafür hat man eine wohldefinierte Abfragesprache, ACID-Konformität und gute Anbindung an Bibliotheken und Rahmenwerke.
kaineanung
User
Beiträge: 145
Registriert: Sonntag 5. April 2015, 20:57

Ich bin ein wenig verwirrt.
Ich soll also keine Gedanken an Geschwindigkeit meiner Abfragen bei der Erstellung eines Projektes verschwenden wenn ich nicht gerade mit ungesundem Menschenverstand an die Sache herangehe?

An ein paar Punkten ist es doch sicherlich sinnvoll sich zu überlegen ob Dies oder Jenes schneller ist.
An diesem Punkt 'View oder per Trigger befüllte Tabellen statt der View' ist es sinnvoll würde ich behaupten.

Da ich eurer Meinung nach 'nur' einige Hunderttausend Datensätze habe, würdet ihr mir also empfehlen erst einmal mit Views das Ganze anzugehen und wenn es dann doch zu langsam ist auf Tabellen umzusteigen? Habe ich das so jetzt richtig verstanden?

Wir reden immerhin von ca. 200.000 Datensätzen in einer Tabelle die jeweils in einer dieser Quelle vorhanden ist. Eine Andere hat auch immerhin ca. 50.000 Datensätze in jeweils einer der Quellen. Wiederum andere haben nur einige wenige Einträge. Aber durch die Views, welche u.U. auch über viele Joins gehen können, hätte ich gedacht das die Performance bei Abfragen auf diese Views, die auch wieder Joins haben werden, schrecklich ausfallen könnte. Daher wollte ich erst einmal fragen was Andere, die Erfahrung damit haben, zu diesem Thema sagen können.
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

Auf die Gefahr hin dich zu enttaueschen: das sind nicht immerhin viele Daten, das sind wirklich ziemlich triviale Datenmengen. Die passen ggf komplett in den Speicher.

Wenn ich von gesundem Menschenverstand rede, dann meine ich zB das man schon sinnvolle Tabellen erzeugt, statt einer Gott-Tabelle mit 200 Spalten, die man dann mehrfach mit sich selbst joinen muss. Oder allgemeiner vernuenftige Datenstrukturen - wenn du per Schluessel auf einen Datensatz zugreifen willst, dann nimm ein Woerterbuch, und such nicht durch eine Liste. So Dinge.

Der Sinn von Views ist lediglich Queries mit oft gejointen Tabellen zu vereinfachen. Da passiert bezueglich der Geschwindigkeit AFAIK nicht wirklich etwas. Insofern - benutze sie, wenn sie dir helfen, aber erwarte nicht, dass sie gross an der Geschwindigkeit drehen.

Deine persistierte Tabelle wuerde ich NICHT anlegen. Du machst das System komplizierter, erzeugst eine Inkongruenz zwischen Ursprungstabellen und kondensierter View-Tabelle, und das alles, *ohne* ein nachweisliches Problem zu haben.

Und *wenn* du Probleme hast, nutze die Analyse-Moeglichkeiten deiner DB, um zB Indexe einzufuegen, um full-table-scans zu vermeiden. Aber die ganze Muehe brauchst du dir erst machen, wenn es wirklich mal hakt.

In all meinen Optimierungen die ich so gemacht habe in SQL habe ich ueblicherweise eher an Indizes und Statements rumgedreht. Das ich die DB-Struktur veraendert habe kann ich mich nicht erinnern.
Benutzeravatar
noisefloor
User
Beiträge: 3843
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,

also ein paar Hundertausend Zeilen sind für ein RDBMS nichts. Das kriegt selbst SQLite ohne Probleme gewuppt. Die Frage ist dann schon eher, wie viele Schreib-/Lesevorgänge du pro Sekunden erwartest. Und wie performant deine Hardware ist.
Ich soll also keine Gedanken an Geschwindigkeit meiner Abfragen bei der Erstellung eines Projektes verschwenden wenn ich nicht gerade mit ungesundem Menschenverstand an die Sache herangehe?
Genau, weil alles was du aktuell machen kannst ist ja: raten.

Und da wir auch keine Einblick in die Datenstruktur bzw. die Tabellenlayouts haben können wir noch nicht mal raten :-)

Da du ja scheinbar direkten Zugriff auf die Daten hast, kannst du die Performance View vs. neue Tabelle anlegen doch ganz einfach testen. Entwirf' dir ein anwendungsnahes Testzenario und mess' die Laufzeiten der Queries.

Gruß, noisefloor
Benutzeravatar
kbr
User
Beiträge: 1487
Registriert: Mittwoch 15. Oktober 2008, 09:27

@kaineanung: Vielleicht noch als Ergänzung: Entwirf Deine Datenbank mit einer guten Normalisierung und so, dass die üblichen Abfragen nicht zu komplex werden. Ein paar Joins dürfen da ruhig rein. Halte es einfach, klar und übersichtlich. Du wirst erstaunt sein, wie schnell eine gute SQL-DB arbeitet. Als Vergleich: 200.000 Karteikarten mit 50.000 anderen zwecks Join abzugleichen, wäre für einen Menschen der Horror. Für eine gute DB ist das nichts.

Anders sieht es aus, wenn Du aus einem Message-Broker 200.000 Messages pro Sekunde herausgreifst und in eine Timeseries-DB schreibst. Dann bist Du im Bereich von Big Data. Eine andere Definition sagt, Big Data fängt da an, wo die Kapazität der Festplatte aufhört. Und damit ist eine große Platte gemeint.
kaineanung
User
Beiträge: 145
Registriert: Sonntag 5. April 2015, 20:57

@__deets__
Auf die Gefahr hin dich zu enttaueschen: das sind nicht immerhin viele Daten, das sind wirklich ziemlich triviale Datenmengen. Die passen ggf komplett in den Speicher.
Nein, keine Enttäuschung denn umso weniger für das Ziel benötigt desto besser... also bin ich beruhigt wenn ich von ein paar wenig kleinen Daten hier reden muss :wink:
Wenn ich von gesundem Menschenverstand rede, dann meine ich zB das man schon sinnvolle Tabellen erzeugt, statt einer Gott-Tabelle mit 200 Spalten, die man dann mehrfach mit sich selbst joinen muss. Oder allgemeiner vernuenftige Datenstrukturen - wenn du per Schluessel auf einen Datensatz zugreifen willst, dann nimm ein Woerterbuch, und such nicht durch eine Liste. So Dinge.
Das meinte ich ja damit '...wenn ich nicht gerade mit ungesundem Menschenverstand an die Sache herangehe...' -> also wenn ich die normalen Techniken anwende die dafür benötigt werden. Davon gehe ich ERST EINMAL von aus...
Der Sinn von Views ist lediglich Queries mit oft gejointen Tabellen zu vereinfachen. Da passiert bezueglich der Geschwindigkeit AFAIK nicht wirklich etwas. Insofern - benutze sie, wenn sie dir helfen, aber erwarte nicht, dass sie gross an der Geschwindigkeit drehen.
Meine Befürchtung ist ja gerade das Gegenteil -> ich würde ja die Views eventuell gerne nutzen. Ich habe aber die Befürchtung daß ich dadurch Performance-Probleme bekomme. Irgendwie habe ich deine Aussage so verstanden daß du denkst ich würde Views benutzen wollen um das Ganze schneller zu machen? Also nein, es ist andersherum..
In all meinen Optimierungen die ich so gemacht habe in SQL habe ich ueblicherweise eher an Indizes und Statements rumgedreht. Das ich die DB-Struktur veraendert habe kann ich mich nicht erinnern.
Die Ursprungstabellen habe ihre jeweiligen Indizies selber. Die Tabellen sind meiner Meinung nach gut strukturiert und ich habe eine (gefühlte) 2,5te Normalform befolgt (also keine Gott-Tabellen oder der Gleichen).
Da ich aber diese 2 Quellen miteinander vereinigen möchte, gewisse Daten aus Quelle 1, andere Daten aus Quelle 2 als Basis für ein Programm/Webseite haben möchte, will ich ein Datenbestand haben auf den ich zugreife.
Nur darum geht es. Also diese Zwei Quellen werden zu einer vereinigt und nach 'oben' weitergegeben.
Ich mache mir bei Views nur performance-technisch Sorgen. Ich würde niemals an festgeslegte Strukturen nachträglich ändern müssen.
kaineanung
User
Beiträge: 145
Registriert: Sonntag 5. April 2015, 20:57

@noisefloor
Die Frage ist dann schon eher, wie viele Schreib-/Lesevorgänge du pro Sekunden erwartest.
Das weiß ich nicht. Will mich aber für alle Fälle 'gut wappnen' wenn es viele sind. Wenn nicht, hat man auch nichts falsch gemacht wenn man sich gut vorbereitet hat...
Und da wir auch keine Einblick in die Datenstruktur bzw. die Tabellenlayouts haben können wir noch nicht mal raten
Bei Gelegenheit werde ich es mal posten.
Da du ja scheinbar direkten Zugriff auf die Daten hast, kannst du die Performance View vs. neue Tabelle anlegen doch ganz einfach testen. Entwirf' dir ein anwendungsnahes Testzenario und mess' die Laufzeiten der Queries.
Werde ich wohl nicht drumherum kommen dies zu machen. Ich dachte jemand wird mir gleich sagen: nein, lass den Quatsch mit Views als Datengrundlage eines Programmes weil viel zu langsam usw.. und dann hätte ich es gelassen.
So bleibt mir nichts anderes übrig um selber zu schauen ob gut oder nicht gut...

@kbr
Entwirf Deine Datenbank mit einer guten Normalisierung und so
Wie o.g. eine gefühlte 2,5te Normalform...

Und BIG Data habe ich nicht mal Ansatzweise. Das habe ich kapiert... so gesehen habe ich gar keine Daten wenn man das so vergleicht... :lol:
Benutzeravatar
noisefloor
User
Beiträge: 3843
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,
Will mich aber für alle Fälle 'gut wappnen' wenn es viele sind. Wenn nicht, hat man auch nichts falsch gemacht wenn man sich gut vorbereitet hat...
Das geht IMHO nicht aus. Weil: bei jeder Datenbank ist die Hardware irgendwann der limitierend Faktor. Und dann macht es mehr Sinn, in Hardware zu investieren als "wie Hölle" zu optimieren. Oder andersrum: wenn du einen ultraperformanten DB-Server hast, musst du vielleicht erst viel später optimieren.

Womit wir wieder beim Thema wäre: verfrühte Optimierung macht keinen Sinn :-)

Gruß, noisefloor
Antworten