Mysql grösse problem
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
auslese
beispiel
code
datei
datenbank
datensatz
datum
format
header
http
jahr
monat
platz
programm
speichern
station
tabelle
url
wetterdaten
zeile
-
Hallo
Habe 1000e daten in mysql. jedentag 10'000 mehr.
gibs einen trick die datenbank klein zu halten, mit gleich vielen daten.
Wie gross darf eine Datenbank sein? (lima-city)
wie gross darf eine Datenbank Tabelle sein? (lima-city)
gibts ne alternative zu mysql? (gleiches prinzip)
danke für die hilfe
Beitrag zuletzt geändert: 29.3.2015 15:37:35 von flipswetter -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
flipswetter schrieb:
Habe 1000e daten in mysql. jedentag 10'000 mehr.
Und? Das ist doch fast nichts für MySQL.
gibs einen trick die datenbank klein zu halten, mit gleich vielen daten.
Dazu müsstest du uns den Aufbau deiner Daten genauer erklären.
Wie gross darf eine Datenbank sein? (lima-city)
wie gross darf eine Datenbank Tabelle sein? (lima-city)
So groß, bis sich jemand von Lima bei dir meldet. Es gilt hier ja das Fair-Use-Prinzip. Sonst ist die DB-Größe eigentlich nur an die Festplattengröße gebunden.
gibts ne alternative zu mysql? (gleiches prinzip)
Nicht nötig. -
Hallo
Es sind 20 3 Stellige Nummern pro minute die in meine Datenbank eingetragen werden.
Wie Gross die Datenbank in MB ist weiss ich nicht.
Es ist eine Mysql Datenbank für 1 min. Wetterdaten ah 20 Datensäze ca.
Mit einer Wetterstation mit 8 Jahren Daten und 2 Weitere Wetterstationen mit 3 Jahren Daten, für Archiv Datenbank
Einige Webhosting Anbieter hatten mir in folge zur Kündigung geraten, da die Mysql Datenbank Grösse von den allgemeinen Grössen abwich.
Aktuell habe ich auch wieder das problem.
Suche ein Webhoster der gewillt ist meine Datenbank zu übernehmen (ich schätze 1.7Giga bis heute)
Gruss
Flipswetter.ch -
Kannst du vielleicht mal deine Datenbankstruktur veröffentlichen?
Mit einem GB müsstest du eigentlich locker ein paar Jahre durchhalten.
Interessant wäre auch noch: Was rufst du später wieder ab aus der Datenbank? Reicht es, an die Wetterdaten einer bestimmten Zeit zu kommen? Oder brauchst du auch Abfragen wie "Wann war es dieses Jahr am wärmsten?"
Ein Extrembeispiel (auf Lima-City vermutlich nicht praktizierbar, weil dann die Daten nicht mehr als Text vorliegen)
20*3 = 60 Dezimalziffern ließen sich auf 25 byte zusammenfassen. Und das jede Minute, dann hättest du im Jahr 12,53 MB an Daten. Deine geschätzten 1,7 GB wären dann erst nach 139 Jahren erreicht.
Ziemlich sicher sind diese Daten dann (z.B. mittels gzip) noch mindestens auf die Hälfte komprimierbar. -
Ermittel doch mal die DB-Größe, z.B. wie hier beschrieben im phpmyadmin, dann weißt Du, woran Du bist.
Ansonsten schließe ich mich fuerderer an, allzuviele Bytes kommen da rechnerisch nicht zusammen.
Beitrag zuletzt geändert: 30.3.2015 0:02:42 von sfhdd -
flipswetter schrieb:
Wie Gross die Datenbank in MB ist weiss ich nicht.
Nichts leichter als das:
Mit dem folgenden Script kannst du die Grösse Deiner Datenbank in KB/MB/GB bekommen:
Musst Du nur natürlich noch an Deine Umgebung anpassen<?php $mysqlhost="localhost"; // Servername $mysqluser="root"; // MySQL-Benutzer $mysqlpwd=""; // Passwort $con = mysql_connect($mysqlhost, $mysqluser, $mysqlpwd); function db_size($name) { // Anfrage definieren $sql = "SHOW TABLE STATUS FROM " . $name; // Anfragen und bei Misserfolg abbrechen if($query = @mysql_query($sql)) { // Ergebnis per mysql_fetch_array holen while($result = @mysql_fetch_array($query)) { // Ergebnis in ein Array einlesen $tabledata[] = $result; } // Variabel initialisieren und Größe auf 0 setzen $db_size = 0; // Solange die Größe auffüllen, bis alle Tabellen durch sind for($i=0; $i<count($tabledata); $i++) { $db_size += $tabledata[$i]["Data_length"] + $tabledata[$i]["Index_length"]; } return $db_size; } else {return "MySQL Query fehlgeschlagen!";} } function format_size($size) { if($size >= 1073741824) { return round(($size / 1073741824), 2) . "GB"; } elseif($size >= 1048576) { return round(($size / 1048576), 2) . "MB"; } elseif($size >= 1024) { return round(($size / 1024), 2) . " KB"; } else { return $size . " Byte"; } } $a = db_size('geo'); echo "Grösse der DB (Byte): " . $a; echo "<br>"; $b = format_size($a); echo "Grösse der DB: " . $b; ?>
Gruss Dunkeltuten
-
Hallo
Habe imm momment meine Datenbank nicht ganz befüllt, da dies mein Hoster nicht zu lies, mit 39 Gb Paket.
Momentan sind es 104 Mb sind aber auch nur Daten von 2 Stationen seit Sep.2014, habe aber alles in allem 15-20 Jahre Daten Speicherung vor (mit einer Station gerechnet) -
Möchtest du irgendwann auch noch deine DB-Struktur zeigen? Das raten warum deine paar Zahlen soviel Platz braucht nervt nur.
-
Hallo
Bin nun am hochladen meiner Daten 2015 von einer Station.
Habe mich im Forum erkundigt es git keine einschränkungen grössenmässig.
Nun drotzdem diese meldung wenn ich die Tabelle wieder löschen oder umbennenen will:
#1226 - User 'USER306907' has exceeded the 'max_updates' resource (current value: 35000)
Wenn es noch jemand interesiert hier die Tabellenstruktur
http://flipswetter.lima-city.de/bhjknt.jpg
Beitrag zuletzt geändert: 5.4.2015 22:02:18 von flipswetter -
Ich würde die Datenstruktur total anders angehen, aber fangen wir mal vorne an:
Du gehst davon aus, Daten über 20 Jahre speichern zu wollen. Dafür nimmst du alle 3 Sekunden Werte auf, welche sich potenziell nicht schnell ändern. Trotzdessen, dass sich die Daten nicht schnell ändern werden, speicherst du alle 3 Sekunden einen kompletten Datensatz, unabhängig davon, ob die vorherigen Daten identisch sind. Und da steckt in meinen Augen das Optimierungspotenzial:
Setzt du für jeden Datentyp eine Tabelle der Struktur:
+----------------------------------+-----------------------+-------------+ | timestamp<bigint, primary> | stationid<tinyint> | Wert<int> | +----------------------------------+-----------------------+-------------+
zusammen mit einer einfachen Tabelle für Stationen:
+-------------------------+--------------------------+-----------------------------+-------------------------------------+ | id <tinyint, primary> | name <varchar100> | position <varchar100> | beschreibung <varchar255> | +-------------------------+--------------------------+-----------------------------+-------------------------------------+
und dazu würde ich in den Tabellen für die Datentypen nur Wert-ÄNDERUNGEN speichern. Warum?
So machst du aus 2h gleiche Temperatur = 2 * 60 * 20 = 3600 Datensätzen -> 2 Datensätze. Das sind also nur 0.06% des Platzes, also hast du eine Ersparnis von 99,94% (wennauch das viel zu stark vereinfacht ist, aber das prinzip soll klar werden).
Wenn du also nur Änderungen für eine Datenstation aufnimmst, kann das den Datenbestand schon drastisch reduzieren. Zusätzlich kannst du auch Stationen aufbauen, die weniger Funktionalität haben, ohne Felder mit NULL zu füllen. Es werden wirklich nur erfasste Daten gespeichert. Du kannst eine dritte Tabellenart aufstellen, welche dann zum Beispiel die Features einer Station beschreibt. Und wenn du so nachher die Daten über 20 Tabellen verstreut hast, sind sie dennoch erhalten und da, und sparsamer.
Das beste ist, dadurch, dass du nur Änderungen speicherst, weißt du, du kannst die Werte zwischen den Änderungen super einfach rekonstruieren. Durch diese Rekonstruktion kannst du die Daten vollständig wieder herstellen, in dem Umfang wie du sie jetzt hast (wenn du sie so denn überhaupt brauchst), kannst aber halt auch direkt mit dem reduzierten Satz arbeiten (Graphen lassen sich so zum Beispiel einfacher Zeichnen, da weniger Daten verarbeitet werden müssen).
Die Münze hat allerdings auch eine Kontraseite: Das Arbeiten mit den Daten ist ein bisschen komplizierter. Um die Daten auszulesen brauchst du einen Algorithmus, der die Daten für den entsprechenden Zeitpunkt zusammenbaut, beziehungsweise du solltest dich gut mit SQL und JOINs bekannt machen.
Das sind nur meine Gedanken, und für mich scheint diese Art der Datenhaltung, also nur Änderungen zu speichern, viel effizienter und auch einfacher. Es lassen sich alle Daten wiederherstellen, und du hast absolut keinen Wertverlust, wennauch die Daten halt ein wenig umständlicher zusammenzufassen sind.
Du kannst übrigens zyklische exporte machen, welche du dann GZiped speicherst. Du kannst also zum Beispiel jeden Monat die Werte des Monats als CSV (oder SQL) exportieren, diese Exporte dann GZipen und als Backup wegspeichern. Werte die nach dem exporten älter als 6 Monate sind, kannst du aus der Datenbank entfernen. So hast du die Daten immer vorhanden, müsstest aber auch eine Software schreiben, die diese Daten dann auch wieder in ein verarbeitbares Format bringt.
Der Vorteil ist aber, du kannst auch für andere Datenbanken einen Importer schreiben, und die Daten so alle nach und nach processen und einfügen, sofern nötig. Außerdem glaube ich nicht, dass alle Daten zu jeder Zeit über die Datenbank verfügbar sein müssen, und so könntest du zusätzlich zu einer schlanken Datenbank den Datenbestand in der Datenbank klein halten, und die Daten behalten.
Aber das sind nur meine Gedanken, so würde ich das aufziehen. Dadurch würdest du aber den Datenbestand halt drastisch reduzieren können, und keinen Mehrwert verlieren.
Was hast du denn mit den Daten vor, wenn ich fragen darf?
Liebe Grüße
Beitrag zuletzt geändert: 5.4.2015 23:21:00 von ggamee -
Hier gibt es wohl ein grundlegendes Problem. Wetterdaten sind,vor allem wenn man sie über längere Zeiträume vorhält, recht voluminös. Genau aus diesem Grund wurde aber bereits ein Standard entwickelt, um die Datenflut so platzsparend wie möglich zu speichern. Der erste Ansatz war das KL9-Format, mittlerweile abgelöst durch KL-2000 bzw. KX-2000. Damit ist platzsparende Speicherung und zudem Austauschbarkeit garantiert.
Dezimalwerte in der Datenbank sind damit hinfällig. Gespeichert wird mit Signed Integer (Aus gemessenen 0,9°C wird ein gespeicherter Datenwert von 90) und weitergegeben werden kompakte Datensätze nach festem Format mit einer Zeile pro Meßereignis. Die Definition dieses Formates ist hier nachlesbar: http://www.dwd.de/bvbw/generator/DWDWWW/Content/Oeffentlichkeit/KU/KU2/KU21/klimadaten/english/download__kl2000standardformat__en,templateId=raw,property=publicationFile.pdf/download_kl2000standardformat_en.pdf
Damit läßt sich schon einiges an Platz sparen Die lesbare Darstellung übernehmen später die Programme, die die Daten einlesen und verwerten.
Zu der Zeit, als ich mich noch mit Wetterdaten beschäftigen mußte, gab es diesen Standard noch nicht. Auf jedem Datenband mit historischen Daten fand sich ein Programm, mit dem man die, im proprietären Format abgelegten Daten auslesen konnte. Dumm nur, wenn dieses Programm im eigenen Rechenzentrum nicht lauffähig war. Da war dann detektivische Handarbeit angesagt, um an die Daten heranzukommen und sie auszuwerten.
-
Hallo
So ganz verstehe ich das leider nicht.
in phpmyadmin was auf KX-2000 komprimierung stellen.
mysql eignet sich hervorragend um monate mit zb. nur stunden wertte ausszlesen
ich schaffe es eben nicht, wie man aus einer csv datei jeden 10ten datensatz ausgelesen wird.
gäbe es doch was sympleres... -
gixnetwork schrieb:
So ganz verstehe ich das leider nicht.
in phpmyadmin was auf KX-2000 komprimierung stellen.
Da hast Du wirklich was falsch verstanden.
Das KL-Format (oder auch KX) ist das Austauschformat der Wetterdienste und definiert den Aufbau ganzer Datensätze. (Dokumentation: *click*)
Da das Format aber eben nur Integerwerte enthält, kann man bereits beim Sammeln der Werte in der Datenbank Platz sparen, in dem man die Messwerte dort in Integer-Feldern passender Größe ablegt. Der Platzbedarf eines äquivalenten Dezimalwertes, der keinen Vorteil bringt, wäre größer.
Ein weiterer Vorteil der Integerwerte ist der, daß man Daten anderer Stationen ohne Umwandlung importieren kann.
ich schaffe es eben nicht, wie man aus einer csv datei jeden 10ten datensatz ausgelesen wird.
Vorsicht! KL-2000 ist kein CSV. In der oben verlinkten Doku kannst Du sehen, daß jeder Wert an einer bestimmten Position im Datensatz steht und eine definierte Länge hat. Zu finden in den Tabellenspalten "from", "to" und "L" für die Länge. Aus der Spalte "Unit" kannst Du noch auslesen, wie später umzurechnen ist, um an die Dezimalwerte zu gelangen. Bei fehlenden Werten bleibt das entsprechende Feld nicht leer, sondern es wird ein eindeutiger Wert zur Kennzeichnung eingetragen (siehe letzte Spalte der Tabelle)
Solltest Du CSV-Daten haben gibt es noch etwas zu beachten: Oft enthält die erste Zeile nur einen Header mit Beschreibung der folgenden Datensätze. Willst Du nur jeden 10. Datensatz auslesen,läßt Du beim Auslesen einfach einen Hilfszähler mitlaufen. Durch die Startzeile hast Du allerdings einen Offset, den Du rausrechnen mußt
Das könnte z.B. so aussehen (sicher nicht die schönste Lösung und auch nicht getestet!
):
<?php $handle = @fopen("datei.csv", "r"); $zaehler = 0; $header = 1; //die Anzahl der Zeilen im Header, die nicht eingelesen werden sollen $intervall = 10; // Intervall der einzulesenden Daten. Hier jede 10. Zeile while (($buffer = fgets($handle, 4096)) !== false) { if ($zaehler > $header) { //Header überspringen if(!(($zaehler-$header) % $intervall)){ //prüfen, ob gelesene Zeile verarbeitet werden soll echo $buffer; // Beispielhaft wird hier die gelesene Zeile ausgegeben // Hier kann dein Code stehen, um die Zeile weiter zu verarbeiten } } ++$zaehler; } fclose($handle); ?>
Beitrag zuletzt geändert: 6.4.2015 18:01:33 von fatfreddy -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
