Hallo, um der Nettiquette gerecht zu werden möchte ich ersteinmal schilden was ich vor haben. Das Projekt hat bereits in einem anderen Thread gestartet aber da sich die Fragestellung nun ändert möchte ich aus Gründen der Übersichtlichkeit einen neuen Thread öffnen. Alter Thread: Beitrag "Screen Scraping C/C++". Das Gesammtziel ist es, Daten aus dem Internet zu empfangen und abzuspeicher, so dass die Daten später visualisiert werden können und das diverse mathematische Algorithmen angewendet werden können (rein privat). Das ganze möchte ich in C++ programmieren. Ich bin jetzt so weit, dass ich mit der folgenden Seite http://www.finanzen.net/aktien/realtimekurse.asp?inindex=1 ein Verbindung herstelle, anfordere welche Daten ich möchte und ich diese empfange. Ich bekomme dann jede Sekunde, wenn sich ein Wert ändert folgenden Code zugeschickt: d(4,12,"10.30","10.30","16:56:23"); 4 --> Information, was ankommt 12 --> Entspricht einer Aktie "10.30" --> Ask "10.30" --> Bid "16:56:23" --> Uhrzeit Die Frage ist nun, wie ich die Daten am sinnvollsten abspeichere. Im einfachsten Fall könnte ich einfach für jede Aktie eine csv-Datei erstellen. Das könnte dann so aussehen Uhrzeit Ask Bid xxx xxx xxx xxx xxx xxx Problem ist dann schon, ob ich die Zahlenwerte ASCII Codiere oder ob ich andere Formate wähle. Z.B.: Uhrzeit --> Int. Zahlenwerte --> float. ASCII Zeichen lassen sich nicht gerade gut verarbeiten. Ggf. macht es auch Sinn, die Datenverwaltung komplett an ein externes Programm (Datenbank wie MySQUL?)zu übergeben, so dass ich nur noch die Daten übergebe und dieses Programm dann die Abspeicherung übernimmt. Wollte einfach mal höhren, welche Ansätze Ihr hierbei verfolgen würdet. Natürlich währe es auch sehr Sinnvoll, ein "standart" Speicherformat zu wähle, so dass kommerzielle Programme die Daten direkt Visualisieren können.
A. R. schrieb: > ASCII Zeichen lassen sich nicht gerade gut verarbeiten. In einer CSV-Datei schon. Das ist eine Textdatei, also müssen alle Werte als Text (was Du "ASCII Zeichen" nennst) drinnenstehen. Das ist das einfachste Standar_D_format, das sich zum Beispiel mit Excel auswerten lässt, und das auch als universelles Austauschformat zwischen verschiedenen Datenbankfrontends verwendet werden kann. Achte allerdings darauf, daß Du als Feldtrennzeichen Semikola anstelle von Kommata verwendest, obwohl das "C" in CSV für Komma steht. Und verwende für Floatingpointzahlen ein Dezimalkomma anstelle des Dezimalpunktes; Excel berücksichtigt die landesspezifischen Einstellungen. 2011-01-01 16:32:15;100,23;13,04;16,07;BLA 2011-07-30 12:34:56;-13,2;0,0;21,03;FUSEL Natürlich könntest Du auch Deine Daten in eine SQL-Datenbank eintragen, aber das ist programmierseitig mehr Aufwand, auch müsstest Du die Datenbank auch entsprechend einrichten, Tabellen darin anlegen etc. Der erste Schritt sollte daher das Erzeugen von CSV-Dateien sein. Die lassen sich später immer noch mit anderen Mitteln weiter"verdauen".
Ok schoneinmal danke für die Info. Wusste nicht das CSV immer im Text Format ist macht aber durchaus Sinn. Das ist natürlich "fürs erste" wirklich das einfachste. Ich weiß aber nicht ob das auch langfristig so ist. Z.B. der Zeitstempel "2011-01-01 16:32:15;" sind hier 20Byte. Wenn ich von einem Wert jede Sekunde und das 8 Stunden pro Tag ausgehe sind das in einem Jahr 365*8*60*60 Werte also 10.500.000Werte. Das sind ca. 200MB. Das ganz noch für vielleicht 50 Aktien sind dann ca. 10GB in einem Jahr nur für den Zeitstempel. Das ist zwar nicht viel aber bei jedem Zugriff muss diese Datenmenge auch gelesen werden (kann nicht abschätzen wie lange das dauert). Wie sähe das bei einer CSV-Datei aus, wenn ich jede Minute einen Wert haben möchte. Muss ich dann die gesammte CSV-Datei nach dem passenden Zeitstempel absuchen oder kann man direkt mit Pointern in der CSV-Datei arbeiten. Entschuldige, wenn das "dumme" Fragen sind habe mich aber mit dem Thema noch nie beschäftigt und möchte ersteinmal eine Art Brainstorming machen. Könnte mir nämlich vorstellen, dass eine Datenbank später mehr Sinn macht.
Schreibs am besten gleich in eine Datenbank, Da gibt es z.B. auch SQLite welches Dateibasiert ist. Der ganze Schnickschnack mit Suche, Filtern, bearbeiten etc... das nimmt dir die DB ab, und du willst ja wohl dich nicht die meiste zeit mit dem CSV Verwalten rumschlagen.
Du kannst dir auch mal rrdtool ansehen. Und achte auch darauf, Datum und Zeit in eine Spalte zu schreiben (so wie Rufus) Das C in CSV kann auch für Character stehen.
A. R. schrieb: > Z.B. der Zeitstempel "2011-01-01 16:32:15;" sind hier 20Byte. > Wenn ich von einem Wert jede Sekunde und das 8 Stunden pro Tag ausgehe > sind das in einem Jahr 365*8*60*60 Werte also 10.500.000Werte. Das sind > ca. 200MB. Musst du wirklich jeden Trade der irgendwo irgendwann passiert speichern? Der Trick heisst hier sinnvolle Datenreduktion! Es würde doch wahrscheinlich genügen wenn du alle 1 (10) min den Kurs jeder Aktie speicherst. > Das ganz noch für vielleicht 50 Aktien sind dann ca. 10GB in einem Jahr > nur für den Zeitstempel. Wer nix wegschmeisst wird über kurz oder lang zum Messie :-)
Läubi .. schrieb: > Da gibt es z.B. auch SQLite > welches Dateibasiert ist. Und die kann mit 200GByte großen Datenbanken noch sinnvoll umgehen? (Siehe was der TO alles speichern will) Das wage ich mal zu bezweifeln.
Ich denke auch, dass bei der Datenmenge (minütlich) du keinen Spaß kriegen wirst mit einer csv Datei. Da das alles sehr nach Server klingt, wäre die Frage, ob C++ nicht da auch schon durch etwas "Besseres" ersetzt werden sollte. Ich persönlich hätte das mit einem php-Skript in eine MySQL/Postgre-Datenbank erledigt, Cronjob minütlich ausführen lassen. (Mit dem Zend-Framework hat man das in wenigen Zeilen erschlagen). Auch wenn du bei C++ bleiben willst, nimm irgendwas Datenbank mässiges- die Dinger sind für solche Zwecke geschrieben: viele Daten, möglichst schnell einlesen/auslesen sortieren, filtern, suchen. Ohne dir zu Nahe treten zu wollen- ich halte es für unwahrscheinlich, dass du in einer vernünftigen Zeitspanne an die gleiche Performance wie DBs ran kommen wirst mit csv- falls es überhaupt möglich ist. Läubi .. schrieb: > du willst ja wohl dich > nicht die meiste zeit mit dem CSV Verwalten rumschlagen. Kann ich nur zustimmen
Bei solchen GByte Datenmengen wird eine Datenbankabfrage wesendlich länger dauern wie neue Daten im Sekundentakt hereinkommen und somit direkt veraltet sein ;)
Udo Schmitt schrieb: > Und die kann mit 200GByte großen Datenbanken noch sinnvoll umgehen? > Das wage ich mal zu bezweifeln. http://www.sqlite.org/speed.html naja es ist veraltet aber es zeigt ungefähr die Richtung, wenn die Perfomance nicht passt, man aber vernünftig Entwickelt hat, dann sollte eine Datenbankengineänderung trotzdem recht schnell möglich sein.
datenbank macht in diesem fall wenig sinn, find ich ich würd die daten a) binär speichern b) z.b. jeden tag ein neues file c) für übersichten usw. daten zusammenfassen (tages/stunden min/max/durchschnitt) und in eigene files.. d) das ganze ist hoffentlich eine "ÜBUNG" und nichts mit dem du Geld verdienen willst ;-)
Marcus B. schrieb: > Udo Schmitt schrieb: >> Und die kann mit 200GByte großen Datenbanken noch sinnvoll umgehen? >> Das wage ich mal zu bezweifeln. > > http://www.sqlite.org/speed.html > > naja es ist veraltet > > aber es zeigt ungefähr die Richtung, wenn die Perfomance nicht passt, Zitat aus der von dir angegebenen URL: These tests are on a relatively small (approximately 14 megabyte) database. They do not measure how well the database engines scale to larger problems. Wir reden hier von 200GByte also mal kurz 10000 mal mehr! Robert L. schrieb: > b) z.b. jeden tag ein neues file > c) für übersichten usw. daten zusammenfassen (tages/stunden > min/max/durchschnitt) und in eigene files.. Wenn du versuchst eine Datenbank selbst zu erfinden bist du praktisch immer schlechter als wenn du einfach eine Datenbank nimmst. Marcus B. schrieb: > Da das alles sehr nach Server klingt, wäre die Frage, ob C++ nicht da > auch schon durch etwas "Besseres" ersetzt werden sollte. > > Ich persönlich hätte das mit einem php-Skript in eine > MySQL/Postgre-Datenbank erledigt, Cronjob minütlich ausführen lassen. > (Mit dem Zend-Framework hat man das in wenigen Zeilen erschlagen). C++ mit was besserem ist echt gut. Scriptsprachen mögen ihre Berechtigung haben aber mit einer richtigen Programmiersprache bist du deutlich leistungsfähiger. Und es ist schneller eine bekannte Programmiersprache zu benutzen als sich in eine Scriptsprache und/oder Framework einarbeiten zu müssen Das ist hier wieder so wie in dem Thread wo einer unbedingt einen 24 Bit Wandler haben will und sich dann herausstellt er will die Vorlauftemperatur seiner Fussbodenheizung regeln. Nicht an Symptomen herumdoktoren, sondern die Ursache bekämpfen, und die heisst: "Jeden Scheiß speichern zu wollen statt sinnvoll zu reduzieren"
>Wenn du versuchst eine Datenbank selbst zu erfinden bist du praktisch >immer schlechter als wenn du einfach eine Datenbank nimmst. so generell ist das SICHER falsch und in diesem fall GANZ SICHER in diesem fall sind es auch nur 3 float werte (datum, ask, bid) (wobei da eigentlich bei ask und bid das volume fehlt) man hat also nicht mal variabel lange daten.. wenn du das als Datenbank speicherst hat du x-fache Datenmenge.. (wegen Indizes usw.) es kommt aber auch auf die aufgabenstellung an, ob die Zeitabstände z.b. immer konstant sind, dann könnte man noch weiter "vereinfachen" (z.b. 5 sekunden sind) usw. und auch WIE man die Daten dann GENAU auswerten will... (man wird ja versuchen "muster" zu finden, ..)
Datum und Uhrzeit sind zusammen 32 Bit, also 4 Bytes. Geldbeträge lassen sich in BCD kodiert besser verwalten, als mit floats, hier reichen also 2 bis 3 bytes. Das mach 8-10 Bytes für einen Datensatz, also etwa 844 KB/Tag oder 300 MB/Jahr, also lächerlich. Ich würde wahrscheinlich auch mit fester Datensatzgröße in einfachen binären Dateien arbeiten, auch wenn sich eine Datenbank hier aufdrängt, und zumindest mal konzeptionell überprüft/getestet werden sollte. So kann man mit fseek(pDatei, ((Tag*60*60*24) + (Stunde*60*60) + (Minute*60) + Sekunde) * 10, 0) jede Sekunde ganz einfach anspringen. Pro Jahr eine Datei sollte reichen.
Ersteinmal Danke für das rege Interesse. >Musst du wirklich jeden Trade der irgendwo irgendwann passiert >speichern? >Der Trick heisst hier sinnvolle Datenreduktion! >Es würde doch wahrscheinlich genügen wenn du alle 1 (10) min den Kurs >jeder Aktie speicherst. Der Witz warum ich mir den Aufwand mache ist gerade der, dass ich die Kurse sekündlich abspeichere. Ich möchte also ungern von dem momentanen Soll abweichen. Das es später Sinn macht für die Verarbeitung den Datenumpfang zu reduzieren steht außer frage. Es macht keinen Sinn mehr Daten zu laden als man anzeigen kann. >Wir reden hier von 200GByte also mal kurz 10000 mal mehr! Wo kommen eigendlich die 200GByte her? Wenn man das ganze etwas sparsam gestaltet sollte man durchaus mit weniger zurecht kommen. Ggf. reicht es aus, den Zeitstempel nur einmal zu speichern. Den braucht man nicht 50 mal. Aber sehr sehr langfristig können dabei natürlich riesige Datenmengen zu stande kommen. Aber wenn das in 10Jahren (wenn mich das dann noch interessiert) ein Problem sein sollte gibt es bis dahin neue Datenspeicher. Zur Auswertung der Daten werde ich wahrscheinlich sowieso zuerst alle Daten von der Datenbank in den Heap schreiben. >c) für übersichten usw. daten zusammenfassen (tages/stunden >min/max/durchschnitt) und in eigene files.. >d) das ganze ist hoffentlich eine "ÜBUNG" und nichts mit dem du Geld >verdienen willst ;-) Ja das ganze ist nicht kommerziell. Zur Auswertung bzw. Visuallisierung werden dann wahrscheinlich neue Datenbanken erstellt. Mit einem Wert pro Tag etc.. Aber genau das ist ja auch die Frage die ich in den Raum stelle. Wenn ich eine Datenbank benutzte und jede Zeile um eine Sekunde nach oben zähle könnte ich doch theroetisch einfach um 86400 Zeilen springen und mir jeden Tag einen Wert rausschreiben. >wenn du das als Datenbank speicherst hat du x-fache Datenmenge.. (wegen >Indizes usw.) Wenn ich jetzt tatsächlich eine Datenbank verwenden würde wäre es dann notwendig, mehrere Dateien zu haben? Ich würde mir das jetzt so vorstellen: Indize Zeitstempel Aktie1 bid/ask Aktie2 bid/ask ... 0 xx xxx xxx xxx xxx 1 yy yyy yyy yyy yyy In einer 2ten Datenbank könnte man dann jeder Spalte ihre Bedeutung zuordnen. Indize Spalte Bedeutung 0 3 Eon BID 1 4 Eon ASK 2 5 RWE BID 3 6 RWE ASK Ich würde mich dem nächst gerne mal mit Datenbanken beschäftigen. So wie ich das momentan verstehe benötige ich hierzu eine Art Server mit welchem ich später über z.B. SQL kommuniziere. Was würdet ihr vorschlagen, was man da am besten verwendet? -Postgre-Datenbank (wurde von Marcus B. (raketenfred) empfohlen) -Microsoft SQL Server 2008 (kann ich kostenlos beziehen) -Oracle (Studentenversion erhätlich ?)
A. R. schrieb: > -Postgre-Datenbank (wurde von Marcus B. (raketenfred) empfohlen) ich habe MySQL oder Postgre im Zusammenhang mit php empfohlen, weil dort die Einbindung sehr einfach ist. (Kriegt man beide kostenlos, ggf. aber Lizenzen bei Weitergabe von Software beachten) Was für ein C++ nimmst du zum Entwickeln?- Wenn du da schon Zugriff aufs Net Framework mit drin hast- dann der Einfachheit halber MS-SQL-Server A. R. schrieb: > Microsoft SQL Server 2008 (kann ich kostenlos beziehen) Die Express Version kriegt jeder kostenlos(auch für kommerzielle Zwecke). Für den Einstieg ist das Management Studio dazu geeignet. Zu Oracle kann ich leider nichts sagen, sieht man aber zwischen durch in Unternehmen
A. R. schrieb: > Der Witz warum ich mir den Aufwand mache ist gerade der, dass ich die > Kurse sekündlich abspeichere. Was spricht dagegen, nur bei einer Änderung den Kurs zu speichern? Die Kurse werden sich ja wohl nicht im Sekundentakt ändern, oder?
A. R. schrieb: > Der Witz warum ich mir den Aufwand mache ist gerade der, dass ich die > Kurse sekündlich abspeichere. Ich möchte also ungern von dem momentanen Dann mach erst mal einen Test, ob Du die 50 Kurse auch ueber eine Woche jede Sekunde zuverlaessig bekommst. Da haette ich schon so meine Zweifel. Wenn das klappt, dann draengt sich ein Vorgehen wie von Rufus vorgeschlagen, geradezu auf. citb
>Was für ein C++ nimmst du zum Entwickeln?- Wenn du da schon Zugriff aufs >Net Framework mit drin hast- dann der Einfachheit halber MS-SQL-Server Benutze Visual Studio 2010 Habe aber bis jetzt nur "Win 32-Konsolenanwendungen" programmiert. >Die Express Version kriegt jeder kostenlos(auch für kommerzielle >Zwecke). Für den Einstieg ist das Management Studio dazu geeignet. Als Student komme ich kostenlos an diese Version herran "Microsoft SQL Server 2008 R2 Enterprise 32/64-bit ia64 (German)" Die Express Version ist glaube auf eine CPU und 10GB oder so begrenzt >Was spricht dagegen, nur bei einer Änderung den Kurs zu speichern? >Die Kurse werden sich ja wohl nicht im Sekundentakt ändern, oder? Ich schrieb am Anfang folgendes: >Ich bekomme dann jede Sekunde, wenn sich ein Wert ändert folgenden Code >zugeschickt: >d(4,12,"10.30","10.30","16:56:23"); >4 --> Information, was ankommt >12 --> Entspricht einer Aktie >"10.30" --> Ask >"10.30" --> Bid >"16:56:23" --> Uhrzeit Habe also fürs erste nur vor die sich ändernden Werte zu speichern. Jedoch kann es maximal jede Sekunde zu einer Änderung kommen. Spart es eigendlich Speicher, wenn eine reservierte Speicherzelle nicht beschrieben wird? Ich gehe nämlich davon aus, dass sich jede Sekunde mindestens ein Wert ändern wird. Also bräuchte ich jede Sekunde einen neuen Eintrag, bei dem ein paar der n Aktien aktuallisiert werden. >Dann mach erst mal einen Test, ob Du die 50 Kurse auch ueber eine Woche >jede Sekunde zuverlaessig bekommst. Da haette ich schon so meine >Zweifel. Genau um das zu Testen ist es ganz schön eine Datenbank zu haben dann sehe ich nämlich, von wann bis wann ich eine Verbindung hatte und wann nicht. Die Verbindun hält meisten ein paar Minuten dann muss ich als Client melden, dass ich noch existiere.
A. R. schrieb: > Habe also fürs erste nur vor die sich ändernden Werte zu speichern. > Jedoch kann es maximal jede Sekunde zu einer Änderung kommen. Spart es > eigendlich Speicher, wenn eine reservierte Speicherzelle nicht > beschrieben wird? Wenn du das so programmierst, kann man natürlich Speicher sparen. ABER: Bei deiner Datensatzgröße ist das ziemlich unrealistisch. Denn du zwirbelst dir eine Monsterverwaltung auf, die selber Speicher verbraucht. Und ehe du fragst: Du musst das selber programmieren. > Indize Zeitstempel Aktie1 bid/ask Aktie2 bid/ask ... > 0 xx xxx xxx xxx xxx > 1 yy yyy yyy yyy yyy > > In einer 2ten Datenbank könnte man dann jeder Spalte ihre Bedeutung > zuordnen. > > Indize Spalte Bedeutung > 0 3 Eon BID > 1 4 Eon ASK > 2 5 RWE BID > 3 6 RWE ASK Schon falsch. Besorg dir wirklich ein Buch über Datenbanken und Datenbankdesign. Nur weil es heute einfacher denn je ist, eine Datenbank in Betrieb zu nehmen bedeutet es nicht, dass man dazu keine Theorie benötigt.
1) Ich würde unbedingt eine "richtige" Datenbank benutzen das ist Stand der Technik, millionenfach erprobt und ohne Not ist alles andere nur Gefrickel 2) Sowohl beim Zeitstempel als auch den Kurswerten könnte man über einen begrenzten Zeitraum (z.B. immer f. 1 Tag, 86.399) nur die Änderungen (Delta) speichern. Man sollte aber in gewissen Abständen auch mal Absoltuwerte zwischenschieben (z.B. jeden 86.400sten) - in Anlehnung zu MPEG-Verfahren. Nur so hat man eine reele Chance "den Faden wiederzufinden", falls es mal einen Ausfall gibt (Inet oder Strom). Allerdings verstößt man damit auch gegen einen Grundsatz guten DB-Designs, wonach die Datensätze hinsichtlich ihrer Reihenfolge nicht voneinander abhängig sein sollen. 3) Viele NAS (z.B. Qnap) haben einen Linux-Controller, dem man auch zusätzliche Programme "unterschieben" kann, dort wäre m.E. der Capturing-Prozess am Besten aufgehoben. Eine Auswertungssoftware auf einem PC könnte dann parallel dazu und unabhängig vom eigentlichen Sammelprozess auf die Daten zugreifen ... 4) Um die Datenbank nicht ins Uferlose wachsen zu lassen, kann man regelmäßig Datensätze ab einem bestimmten Alter exportieren (packen und archivieren) und aus der aktuellen DB löschen.
1) hab ich eh schon weiter oben widersprochen 2) ist ein witz, oder ? (in kombination mit 1) 3) dem kann ich nur zustimmen, (bis auf das wort "Linux-Controller") 4) wozu: entweder braucht er die daten (dann kann er sie nicht aus der datenbank löschen) oder er braucht sie nicht, wozu dann (kompliziet) aufbewahren (fürn "notfall" macht das ja sowieso das tägliche backup)
Rufus Τ. Firefly schrieb: > Und verwende für Floatingpointzahlen ein Dezimalkomma anstelle des > Dezimalpunktes; Excel berücksichtigt die landesspezifischen > Einstellungen. Das macht die Sache nun wirklich nicht universell. Jedes Programm, das nicht gerade mit deutschen Ländereinstellungen arbeitet, wird kläglich an derart verhunzten Daten scheitern. Besser ist ein Integerformat, z.B. der Datentyp Currency oder Preise in Cent.
Robert L. schrieb: > 1) hab ich eh schon weiter oben widersprochen Widersprochen ja, begründet meiner Meinung nach nein. Es ist einfach so, das die Wahrscheinlichkeit (besonders beim Kenntnisstand des TO, ist nicht böse gemein) eher gering ist das man selber alleine es schafft eine Bessere Lösung zu finden, als solche die von vielen Leuten Millionenfach eingesetzt wird. MySQL bietet für solche Zwecke wie sie der TO anspricht sogar eine spezielle Speicherengine: http://dev.mysql.com/doc/refman/5.0/en/archive-storage-engine.html > The ARCHIVE storage engine is used for storing large amounts > of data without indexes in a very small footprint. Und wenn er nun unbedingt CSV haben will: http://dev.mysql.com/doc/refman/5.0/en/csv-storage-engine.html > The CSV storage engine stores data in text files using > comma-separated values format. (allerdings standardmäßig nicht in Windows enthalten) Das alles sind erprobte Lösungen, und ob nachher wirklich Gigabyteweise Daten zusammenkommen sei mal dahingestellt, es spricht aber auch nix dagegen für jede Woche des Jahres eine neue Datenbank anzulegen, wohingegen man sich in den A**** beißen wird wenn die Daten mehrere Woche/Monate Schrott sind weil das ach so geniale eigene Format einen kleinen Programmbug enthielt.
Sehr wahrscheinlich werde ich ersteinmal versuchen die Daten in einer Datenbank zu speichern. Eine CSV-Datei oder ähnliches würde es zwar ggf. ermöglichen Speicherplatz zu sparen erhöht aber den Programmieraufwand und auch den späteren Aufwand die Daten zu rekonstruieren. Habe mittlerweile Microsoft SQL Server 2008 R2 installiert. Wenn ich nun über einen Client auf die Datenbank zugreifen möchte benötige ich noch eine API die dies ermöglicht. Habt ihr vorschläge, was man für C++ verwenden könnte.
A. R. schrieb: > Habt ihr vorschläge, was > man für C++ verwenden könnte Die C++ Lib von Microsoft vielleicht? Da du dich ja unbeirrbar auf C++ festgelegt hast musst du nun auch mit den Hässlichkeiten klarkommen :P Hierbei hast du die Wahl entweder MS DB-Library oder ODBC, etwas "fertiges", gibt es z.B. hier: http://www.sqlapi.com/
@Läubi... begründung: es gibt nix einfacheres als (diese) daten binär in eine datei zu speichern, ... sql hätte zuviel overhead, und keine nutzen.. sql ist jetzt auch grad nicht trivial.. aber egal. lassen wir sie ihn in eine sql datenbank speichern das ist nur einfach nicht "zu ende gedacht" es geht ihm ja sicher darum die daten dann zu analysieren, muster zu erkennen, vergleichen usw. da wird ihm sql in diesem fall nicht helfen (bis auf min/max/avg ist da nicht viel rauszuholen) sondern die daten werden (effizient) im speicher abgelegt werden müssen wenn sein wissen dafür dann nicht ausreicht, hilf die tolle datenbank auch nix.. speichert er die daten binär in einer datei, kann er den jeweiligen bereich (z. b. die jeweilige(n) wochen/tage) die er analysieren will, 1:1 in den speicher kopieren.. will er nur anzeigen (oder vielleit als alternative, wennn man eine "datenbank" haben will, und was erproptes") http://oss.oetiker.ch/rrdtool/index.en.html effizient, das kummuliert auch, und löscht alte daten automatisch usw. usw.
Vorraussichtlich werde ich mich vorerst an lrlrs Rat halten. Nachdem ich mich etwas mit Datenbanken beschäftigt haben und die anfängliche Euphorie verflogen ist musste ich doch ein paar Sachen feststellen. - Bibliotheken bieten nicht so viel Komfort wie erhofft - Bibliotheken haben sehr viel Overhead Wenn ich eine Bibliothek verwenden würde müssten die Daten zum späteren Verarbeiten erst einmal in ein "mathematisches" Format gebracht werden. Dies heißt im worst case Formatierung aus ACII in Zahlenwerte + ggf. Formatänderung beim Datum. Zusätzlich kommt noch, dass beim verwenden von ODBC noch zusätzlicher Overhead entsteht. Beim Einlesen von 8.000.000 Werte oder mehr kann ich darauf verzichten. Zum späteren Visuallisieren werden ich die Ergebnisse einfach in eine csv-Datei schreiben und diese kann ich dann mit diversen Programmen öffnen. Ich werde vorraussichtlich für jede Aktie eine eigene Binärdatei verwenden. Für die Zeit werde ich einfach einen Integer verwenden. Dieser zählt die Sekunden vom 01.01.2000 hoch. Damit lassen sich dann 136 Jahre abbilden. Für den Kurswert sollte ein float bei weitem ausreichend sein. Anschließend folgt noch ein char zum speichern von Daten. Z.B. ob der Wert nun tatsächlich erfasst worden ist oder ob er per Interpollation ermittelt wurde. Das sind dann 32+32+8= 72Bit = 9Byte pro Wert Also 12MB pro Aktie pro Jahr. Wenn jemand noch Einwände bzw. Verbesserungen hat würde ich mich darüber natürlich freuen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.