Geschwindigkeit Python Skript
-
noisefloor
- User
- Beiträge: 3858
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
RAM sowieso nicht. Kann ein Faktor sein, wenn die riesige Menge Daten hast, die ggf. nicht mehr in den Arbeitsspeicher passen. Und wenn der Prozessor aufgrund der Auslastung des Servers sowieso schon auf Anschlag läuft, dann wird dein Skript ggf. auch langsamer abgearbeitet, eben weil die Ressourcen am Limit sind.
Grundsätzlich unterschiedet man bei Programmen zwischen "I/O bound" und "CPU bound", was den geschwindigkeitsbestimmenden Faktor angeht. Solange du nicht sagst, was dein Skript macht lässt sich die Frage nicht beantworten bzw. die Frage macht so keinen Sinn.
Außerdem lassen sich Python Skript ggf. erheblich beschleunigen, wenn man eine andere Python-Implementierungen nimmt (wie PyPy) oder CPython in Kombination mit einem JIT wie Numba. Kann, muss aber nicht. Ob eine dieser Maßnahmen zielführend ist lässt sich auch nur sagen, wenn man das Skript kennt.
Gruß, noisefloor
RAM sowieso nicht. Kann ein Faktor sein, wenn die riesige Menge Daten hast, die ggf. nicht mehr in den Arbeitsspeicher passen. Und wenn der Prozessor aufgrund der Auslastung des Servers sowieso schon auf Anschlag läuft, dann wird dein Skript ggf. auch langsamer abgearbeitet, eben weil die Ressourcen am Limit sind.
Grundsätzlich unterschiedet man bei Programmen zwischen "I/O bound" und "CPU bound", was den geschwindigkeitsbestimmenden Faktor angeht. Solange du nicht sagst, was dein Skript macht lässt sich die Frage nicht beantworten bzw. die Frage macht so keinen Sinn.
Außerdem lassen sich Python Skript ggf. erheblich beschleunigen, wenn man eine andere Python-Implementierungen nimmt (wie PyPy) oder CPython in Kombination mit einem JIT wie Numba. Kann, muss aber nicht. Ob eine dieser Maßnahmen zielführend ist lässt sich auch nur sagen, wenn man das Skript kennt.
Gruß, noisefloor
@noisefloor das stimmt so nicht. Speicher geht nicht nur durch Menge, sondern auch durch Geschwindigkeit ein. Bei einer so notorisch speicherhungrigen Sprache wie Python kann das deutliche Konsequenzen haben. Auf dem Pi 2 zb war Python etwa halb so schnell in unseren benchmarks, als die reine CPU geekbench Ergebnisse das haben erwarten lassen. Die CPU hat einfach auf den Speicher gewartet.
Pardon, mir war nicht klar dass die Funktionsweise der Skripte entscheidend ist, sonst hätte ich die direkt mit aufgeschrieben.
Also im wesentlich ziehe ich mir per API‘s oder webscrapping Finanzdaten die ich mir in verschiedene MySQL Datenbanken speichere. Wahrscheinlich demnächst auch parallel. Anschließend werden dann mit anderen Skripten die Daten aus den db‘s gezogen und daraus für 1000-1500 unternehmen finanzkennzahlen berechnet. Die sollen dann wiederum über einen Webserver abgerufen werden können.
Also hier geht es insbesondere um große Mengen. Z.Bsp. Hab ich eine Datenbank mit historischen Kursdaten aller s&p500 und Euro stoxx 600 unternehmen. Alleine für das Unternehmen M3 sind das knapp 16.000 Einträge (eine table pro Unternehmen)
Aktuell verwende ich eine Synology Diskstation 218play dafür. Mit 1GB Arbeitsspricher. Ich überlege nun mir einen Mini pc zu kaufen der wenn ich das richtig verstehe nicht mehr Strom verbraucht aber deutlich leistungsfähiger ist. Würde den dann als ubuntu- Server laufen lassen wollen.
Also im wesentlich ziehe ich mir per API‘s oder webscrapping Finanzdaten die ich mir in verschiedene MySQL Datenbanken speichere. Wahrscheinlich demnächst auch parallel. Anschließend werden dann mit anderen Skripten die Daten aus den db‘s gezogen und daraus für 1000-1500 unternehmen finanzkennzahlen berechnet. Die sollen dann wiederum über einen Webserver abgerufen werden können.
Also hier geht es insbesondere um große Mengen. Z.Bsp. Hab ich eine Datenbank mit historischen Kursdaten aller s&p500 und Euro stoxx 600 unternehmen. Alleine für das Unternehmen M3 sind das knapp 16.000 Einträge (eine table pro Unternehmen)
Aktuell verwende ich eine Synology Diskstation 218play dafür. Mit 1GB Arbeitsspricher. Ich überlege nun mir einen Mini pc zu kaufen der wenn ich das richtig verstehe nicht mehr Strom verbraucht aber deutlich leistungsfähiger ist. Würde den dann als ubuntu- Server laufen lassen wollen.
"Eine table pro Unternehmen" [sic] klingt schon einmal danach, als wäre das Datenbankdesign kaputt.
Und da fängt es leider schon an.
Es bleibt dabei, dass man das nicht pauschal beantworten kann.
Ich würde erst einmal feststellen, ob du überhaupt ein Geschwindigkeitsproblem hast. Dann würde ich das identifizieren. Und das dann angehen. Vorher ist das alles esoterisches Rumgefummel.
Und da fängt es leider schon an.
Es bleibt dabei, dass man das nicht pauschal beantworten kann.
Ich würde erst einmal feststellen, ob du überhaupt ein Geschwindigkeitsproblem hast. Dann würde ich das identifizieren. Und das dann angehen. Vorher ist das alles esoterisches Rumgefummel.
Datenbankdesign … ja wahrscheinlich ist das Mist. Auch der Code wird alles andere als optimal sein. Ich bin halt nicht ausgebildet, sondern versuche als Fachfremder irgendwie mir das Leben mit den Möglichkeiten die Python und co bietet zu erleichtern. Das alles wird für den Könner sehr dilettantisch aussehen , was es auch ist, daher habe ich versucht die Frage so isoliert wie möglich zu stellen.
Wo kann ich denn etwas über das Datenbankdesign so kompakt wie möglich lesen ?
Wo kann ich denn etwas über das Datenbankdesign so kompakt wie möglich lesen ?
-
noisefloor
- User
- Beiträge: 3858
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
wenn du dir externe Daten über externe APIs ziehst oder Webscraping betreibst ist das erstmal I/O bound, d.h der geschwindigkeitsbestimmende Faktor ist zumindest in dem Schritt der Netzwerkverkehr.
Und 16000 Zeilen in einer Datenbanktabelle sind nicht wirklich viel. Kommt dann halt drauf an, was die damit machst, wie gut (oder schlecht) das Datenbankdesign ist und wie komplex die Abfragen sind.
Bei Datenbankserver kann viel RAM helfen, damit möglichst viele Daten im RAM gehalten werden können. Ob das bei deiner Anwendung schon zutrifft kann hier wohl keiner sagen.
Grundsätzlich solltest du dir um Performance erst Gedanken machen, wenn du ein konkretes Performanceproblem hast. Bis dahin solltest du auf sauber strukturieren und möglichst effizienten Code fokussieren.
In deinem Fall braucht man nicht eine Tabelle pro Unternehmen, sondern eine Tabelle mit allen Unternehmen und eine Tabelle mit allen Werten, wobei jeder Zeile (mit z.B. dem Wert und dem Datum, an dem der Wert galt) ein Unternehmen zugeordnet ist. Das ist dann eine 1:n (one-to-many) Beziehung. Ausformuliert: jedem Wert-Datum ist genau ein Unternehmen zugeordnet, aber jedem Unternehmen können mehrere Wert-Daten Einträge zugeordnet sein.
Es gibt auch noch andere Beziehungsarten, hängt von der Art ab, wie die Datenzusammenhängen.
Wenn das Projekt größer wird, dass ist der Einsatz eines ORM wie SQLAlchemy sinnvoll, weil das viele einfacher macht. Wenn du später eine Webanwendung auf die Daten setzt kann es auch sinnvoll sein, direkt das Django Webframework und dessen ORM zu nutzen. Was für dich wirklich sinnvoll ist (oder eben nicht) lässt sich bei der immer noch dünnen Informationslage nicht sagen.
Gruß, noisefloor
wenn du dir externe Daten über externe APIs ziehst oder Webscraping betreibst ist das erstmal I/O bound, d.h der geschwindigkeitsbestimmende Faktor ist zumindest in dem Schritt der Netzwerkverkehr.
Und 16000 Zeilen in einer Datenbanktabelle sind nicht wirklich viel. Kommt dann halt drauf an, was die damit machst, wie gut (oder schlecht) das Datenbankdesign ist und wie komplex die Abfragen sind.
Bei Datenbankserver kann viel RAM helfen, damit möglichst viele Daten im RAM gehalten werden können. Ob das bei deiner Anwendung schon zutrifft kann hier wohl keiner sagen.
Grundsätzlich solltest du dir um Performance erst Gedanken machen, wenn du ein konkretes Performanceproblem hast. Bis dahin solltest du auf sauber strukturieren und möglichst effizienten Code fokussieren.
Du benutzt eine SQL-Datenbank. Zu SQL gibt es jede Menge Infos und Tutorials im Netz. Bei den Grundlage ist es auch ziemlich egal, welche SQL-DB man einsetzt. "Kompakt" ist auch nicht der richtige Ansatz, es gut um das sinnvolle Strukturieren. Das Stichwort ist: Normalisierung sowie 1., 2. und 3. Normalform. Man kann darüber streiten, wie weit man normalisiert und ob die 3. Normalform immer notwendig ist. Hängt (auch) von den Daten, der Datenmenge und dem Aufwand-Nutzen ab.Wo kann ich denn etwas über das Datenbankdesign so kompakt wie möglich lesen ?
In deinem Fall braucht man nicht eine Tabelle pro Unternehmen, sondern eine Tabelle mit allen Unternehmen und eine Tabelle mit allen Werten, wobei jeder Zeile (mit z.B. dem Wert und dem Datum, an dem der Wert galt) ein Unternehmen zugeordnet ist. Das ist dann eine 1:n (one-to-many) Beziehung. Ausformuliert: jedem Wert-Datum ist genau ein Unternehmen zugeordnet, aber jedem Unternehmen können mehrere Wert-Daten Einträge zugeordnet sein.
Es gibt auch noch andere Beziehungsarten, hängt von der Art ab, wie die Datenzusammenhängen.
Wenn das Projekt größer wird, dass ist der Einsatz eines ORM wie SQLAlchemy sinnvoll, weil das viele einfacher macht. Wenn du später eine Webanwendung auf die Daten setzt kann es auch sinnvoll sein, direkt das Django Webframework und dessen ORM zu nutzen. Was für dich wirklich sinnvoll ist (oder eben nicht) lässt sich bei der immer noch dünnen Informationslage nicht sagen.
Gruß, noisefloor
Ich hab mich noch garnicht für eure Antworten und eure Mühe bedankt. Also erstmal ganz lieben Dank für die aufschlussreichen Antworten. Dann werde ich jetzt mal bei YouTube und Co. nach Normalisierung einer SQL Datenbank auf die Suche gehen.
Aber vorab… wenn ich dich richtig verstanden habe @noisefloor ist es sinnvoller Millionen von Daten in eine Tabelle zu packen wenn die Spalten identisch sind als das in einzelne Tabelle aufzuteilen ? Bei den historischen Daten wäre das tatsächlich auch kein Problem da identische Spalten. 16.000 Zeilen sind nicht viel , das ist schonmal ne gute Info … aber 16.000 x 1100 Unternehmen ? Vielleicht demnächst 2000 Unternehmen. Da kommt schon einiges zusammen…
Die Beziehung zu anderen Tabellen ist das Ticker Symbol. Ich weiß nicht in wie weit du dich mit Aktien und deren Analyse schonmal beschäftigt hast. Das Ticker Symbol ist so ziemlich das international übliche Erkennungszeichen für eine Aktie. Die historischen Daten (Kurs und Volumen pro Tag) ziehe ich mir aus einer API von Yahoo Finance. Des Weiteren ziehe ich mir die Geschäftsberichte , also Bilanz, Gewinn und Verlustrechnung und CashFlow Statement der Unternehmen via Webscapping. Das sind pro Unternehmen auch nochmal hunderte Spalten für zich Quartale (Zeilen). Hier können die Spalten jedoch recht unterschiedlich sein. Daher hier tatsächlich schwierig alle Daten in eine Tabelle zu schreiben. Je nach Kennzahlen verbinde ich die Tabellen dann über die Ticker mit joints je nach zu ermittelnder Kennzahl. Die fertigen Kennzahlen wiederum , also die Daten die ich irgendwann mal via Browser abfragen möchte, übertrage ich in eine finale Tabelle. Eine „Livetabelle“ so zu sagen um die mit so wenig Prozessen im Hintergrund anzeigen zu lassen. Da ich hier auch aus allen Unternehmen filtern möchte.
Ich hoffe es wird jetzt etwas klarer was ich da vor hab. Oder braucht ihr noch mehr Infos ? Wenn ja welche ?
Aber vorab… wenn ich dich richtig verstanden habe @noisefloor ist es sinnvoller Millionen von Daten in eine Tabelle zu packen wenn die Spalten identisch sind als das in einzelne Tabelle aufzuteilen ? Bei den historischen Daten wäre das tatsächlich auch kein Problem da identische Spalten. 16.000 Zeilen sind nicht viel , das ist schonmal ne gute Info … aber 16.000 x 1100 Unternehmen ? Vielleicht demnächst 2000 Unternehmen. Da kommt schon einiges zusammen…
Die Beziehung zu anderen Tabellen ist das Ticker Symbol. Ich weiß nicht in wie weit du dich mit Aktien und deren Analyse schonmal beschäftigt hast. Das Ticker Symbol ist so ziemlich das international übliche Erkennungszeichen für eine Aktie. Die historischen Daten (Kurs und Volumen pro Tag) ziehe ich mir aus einer API von Yahoo Finance. Des Weiteren ziehe ich mir die Geschäftsberichte , also Bilanz, Gewinn und Verlustrechnung und CashFlow Statement der Unternehmen via Webscapping. Das sind pro Unternehmen auch nochmal hunderte Spalten für zich Quartale (Zeilen). Hier können die Spalten jedoch recht unterschiedlich sein. Daher hier tatsächlich schwierig alle Daten in eine Tabelle zu schreiben. Je nach Kennzahlen verbinde ich die Tabellen dann über die Ticker mit joints je nach zu ermittelnder Kennzahl. Die fertigen Kennzahlen wiederum , also die Daten die ich irgendwann mal via Browser abfragen möchte, übertrage ich in eine finale Tabelle. Eine „Livetabelle“ so zu sagen um die mit so wenig Prozessen im Hintergrund anzeigen zu lassen. Da ich hier auch aus allen Unternehmen filtern möchte.
Ich hoffe es wird jetzt etwas klarer was ich da vor hab. Oder braucht ihr noch mehr Infos ? Wenn ja welche ?
Mit 30 Jahren Erfahrung mit relationalen Datenbanken: ja, das ist es. Passende Indizes in der DB sollten natürlich verwendet werden. Bei Bedarf kannst du innerhalb der Datenbank, falls diese das anbietet, weitere Optimierungen vornehmen (z.B. Partitioning).
Aus meiner Sicht kann es sinnvoll sein, sich vorab zu überlegen, welche Art von Daten man speichern möchte, wie diese miteinander in Beziehung stehen und welche Art von Abfragen man darauf ausführen möchte. Und dann überlegt man sich, wie man diese modellieren kann und welche Datenbanksoftware sich dafür am Besten eignet. Das kann eine relationale Datenbank sein, muss es aber nicht. Insbesondere man wenn sehr unterschiedlich strukturierte Daten aus ganz verschiedenen Quellen zusammen bringen möchte, kann es nach meiner Erfahrung sinnvoll sein, auch über andere Datenbank-Ansätze nachzudenken, statt alles irgendwie in Tabellenform in MySQL/Mariadb zu pressen.
-
__blackjack__
- User
- Beiträge: 13123
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@Monjy: „Hunderte Spalten“ klingt komisch bis falsch.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
-
noisefloor
- User
- Beiträge: 3858
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
Realistischer Weise kann man das doch auch nie ohne Megaaufwand vernünftig abfragen, weil du dir für jedes Unternehmen eine eigene Abfrage bauen musst. Und falls Unternehmen $FOO mal die Art und Weise ändert, wie es seine Quartalsdaten aufbereitet, fängst du wieder von vorne an.
Die Frage ist, ob du diese Daten überhaupt in ein RDBMS speichern musst. Weil so wie ich das verstanden habe analysierst du die Daten und erhältst dann ein vereinheitlichtes Ergebnis, egal wie die Ausgangsdaten von $FOO und $BAR aussehen.
Ansonsten bin ich auch bei @nezzcarth, dass man über die Art der DB nachdenken sollte. ja, man kann alles in ein RDBMS packen - aber das ist nicht immer sinnvoll. Wenn die Daten sich stark unterscheiden ist ggf. eine schemalose DB besser.
Wobei, um Missverständnisse zu vermeiden: für das Ausgangsproblem "Unternehmen - Wert -Tag" ist ein RDBMS schon genau richtig.
Gruß, noisefloor
War auch mein Gedanken. Und erst recht, wenn's das Mehrfach gibt, d.h. Unternehmen $FOO hat 98 Spalten und Unternehmen $BAR hat 85 Spalten aber mit anderen Überschriften.__blackjack__ hat geschrieben: ↑Sonntag 12. November 2023, 23:32 @Monjy: „Hunderte Spalten“ klingt komisch bis falsch.
Realistischer Weise kann man das doch auch nie ohne Megaaufwand vernünftig abfragen, weil du dir für jedes Unternehmen eine eigene Abfrage bauen musst. Und falls Unternehmen $FOO mal die Art und Weise ändert, wie es seine Quartalsdaten aufbereitet, fängst du wieder von vorne an.
Die Frage ist, ob du diese Daten überhaupt in ein RDBMS speichern musst. Weil so wie ich das verstanden habe analysierst du die Daten und erhältst dann ein vereinheitlichtes Ergebnis, egal wie die Ausgangsdaten von $FOO und $BAR aussehen.
Ansonsten bin ich auch bei @nezzcarth, dass man über die Art der DB nachdenken sollte. ja, man kann alles in ein RDBMS packen - aber das ist nicht immer sinnvoll. Wenn die Daten sich stark unterscheiden ist ggf. eine schemalose DB besser.
Wobei, um Missverständnisse zu vermeiden: für das Ausgangsproblem "Unternehmen - Wert -Tag" ist ein RDBMS schon genau richtig.
Gruß, noisefloor