Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Empirisch ermittelt durch Vorher/Nachher Vergleich. von 5xMB ist es auf 79MB angewachsen.
Da man eigentlich immer das Datum für die Abfragen einbezieht finde ich den Index auch sinnvoll.
Warum nicht? Ich habe keine Partitionen angelegt, nur den Index hinzugefügt. Es hängt natürlich stark davon ab welche Sorte Daten in gavalue stehen, bei mir Hauptsächlich Temperaturwerte.
Mit Index
Code:
MariaDB [(none)]> SELECT
-> table_schema as `DB`,
-> table_name AS `Table`,
-> round(((data_length + index_length) / 1024 / 1024), 2) `Size MB`,
-> round(((data_length) / 1024 / 1024), 2) `data MB`,
-> round(((index_length) / 1024 / 1024), 2) `index MB`
-> FROM information_schema.TABLES
-> WHERE information_schema.TABLES.TABLE_NAME = 'archivKoData';
+-----------+--------------+---------+---------+----------+
| DB | Table | Size MB | data MB | index MB |
+-----------+--------------+---------+---------+----------+
| edomiLive | archivKoData | 79.43 | 26.66 | 52.77 |
+-----------+--------------+---------+---------+----------+
1 row in set (0.00 sec)
ohne zusätzlichen Index.
Code:
MariaDB [(none)]> SELECT
-> table_schema as `DB`,
-> table_name AS `Table`,
-> round(((data_length + index_length) / 1024 / 1024), 2) `Size MB`,
-> round(((data_length) / 1024 / 1024), 2) `data MB`,
-> round(((index_length) / 1024 / 1024), 2) `index MB`
-> FROM information_schema.TABLES
-> WHERE information_schema.TABLES.TABLE_NAME = 'archivKoData';
+-----------+--------------+---------+---------+----------+
| DB | Table | Size MB | data MB | index MB |
+-----------+--------------+---------+---------+----------+
| edomiLive | archivKoData | 57.48 | 26.66 | 30.82 |
+-----------+--------------+---------+---------+----------+
1 row in set (0.00 sec)
Ok, jetzt verstehe ich was Du mit den Größen meinst. Ich vermute mal Du hast sehr viele kleine Einträge in der Tabelle (mit 26.66 MB)und daher ist der Index mit 21.95 MB fast genauso groß wie die Datentabelle selbst. Dann macht das jetzt Sinn!
Ich habe das mit dem Index bei mal ausprobiert. Ich musste aber SQL-Statement anpassen:
Code:
mysql> create index Idx_1 on archivKoData(targetid, datetime);
Query OK, 6322455 rows affected (4 min 39.73 sec)
Records: 6322455 Duplicates: 0 Warnings: 0
Die Größe ist deutlich gewachsen:
Code:
[root@edomi edomiLive]# ls -lh archivKoData.*
-rw-rw---- 1 mysql mysql 17K Nov 1 2017 archivKoData.frm
-rw-rw---- 1 mysql mysql 202M Feb 9 17:49 archivKoData.MYD
-rw-rw---- 1 mysql mysql 218M Feb 9 17:49 archivKoData.MYI
[root@edomi edomiLive]# ls -lh archivKoData.*
-rw-rw---- 1 mysql mysql 17K Feb 9 17:49 archivKoData.frm
-rw-rw---- 1 mysql mysql 202M Feb 9 17:54 archivKoData.MYD
-rw-rw---- 1 mysql mysql 369M Feb 9 17:54 archivKoData.MYI
Die (komplexen) Diagramme kommen jetzt aber deutlich schneller, i.d.R. sind die nach 2 Sekunden da (welche vorher sehr viel länger gebraucht haben).
Lieber mehr Platz als Zeit verbrauchen
Das dürfte schwer abzuschätzen sein. Anzahl der Downloads der Software/Updates?
Oder eher anhand der Nutzer, die in diesem Unterforum unterwegs sind... ?
Anzahl der Downloads wird schwierig. Schon um meinen Installer zu testen hab ich EDOMI bestimmt 100 Mal runtergeladen Früher gab es mal eine Statistik auf der HP, die aber nach eine Hack? abgeschafft wurde. Damals wurden die Statistikdaten, die EDOMI standardmäßig sendet ausgewertet. Das ist aber auch nur grob geschätzt, da man das in den Basiseinstellungen abschalten kann.
Da Edomi ja regelmässig prüft, ob ein Update vorhanden ist, kann Christian das natürlich auf seinem Server auswerten. (Aber auch das ist nur eine Annäherung, weil ja nicht jede produktive Edomi-Installation Verbindung ins Internet hat oder die Funktion deaktiviert wurde. OK, eigentlich habe ich mehr oder weniger den Beitrag von vento66 wiederholt...sorry)
Die Anzahl der Nutzer muss ja irgendwo zwischen user hier im Forum und einem Mittelwert der Downloads aus den vergangenen updates sein.
Ich denke schon, dass mittlerweile 90-95% auf der Version 2.0 sein werden.
Ebenso hoch schätze ich den Anteil ein, der Daten über die Basis-Einstellung sendet.
Hm ich kenne einige Installationen, wo die Kiste nicht mal am Internet hängt, und teilweise auch auf einen Stand < 1.6x ist. repräsentativ ist das auch nicht wirklich.Auf der anderen Seite sind hier gerade 4 Instanzen am laufen....
ich halte die Annahme mit 90-95% auf 2.xx auch für verwegen. Mein Produktivsystem ist noch auf 1.64 und wird das auch noch eine Weile bleiben. Die Minor-Releases habe ich stets zeitnah gemacht, aber das Major-Release auf 2.xx machen sicher einige nicht "einfach so" - nicht zuletzt, weil es die Frage nach CentOS 6.5 -> 7.x mitbringt. Dafür laufen hier auch 3 weitere VM-Instanzen auf 2.xx - eine davon ist der komplette Neuaufbau meiner kommenden Prod-Umgebung - bei mir wird es also ein schleichender Umstieg. Aber ich nehme an, das machen eher weniger Nutzer.
Ich denke schon, dass Christian die Anzahl der Installationen grob abschätzen kann - mit einer Dunkelziffer zu niedrig wie schon oben beschrieben. Aber darauf auf die Haushalte/Nutzer schließen zu können ist in Zeiten von VM + Docker eher schwer.
Soweit ich weiß bekommt jede EDOMI Instanz bei der Installation eine eindeutige ID zugewiesen (clientid.edomi).
Diese (und die Version) wird beim Auto-Update check dann mit übertragen. Wenn Christian jetzt IDs, welche von derselben IP kommen herausfiltert, dann müsste er eine ziemlich genaue Vorstellung von der Anzahl haben. Nicht erfasst werden dann zwar die Produktivsysteme, welche nicht ins Internet kommen oder bei denen der Check ausgestellt ist, aber meist laufen bei den Personen ja noch Testsysteme und diese würden dann stattdessen erfasst werden.
aber das Major-Release auf 2.xx machen sicher einige nicht "einfach so" - nicht zuletzt, weil es die Frage nach CentOS 6.5 -> 7.x mitbringt.
Den Zusammenhang verstehe ich nicht. Was hat das Update auf die 2.x mit dem Wechsel von CentOS 6 auf CentOS 7 zu tun? Der grosse Unterschied von der Benutzung her ist nur, dass es mit der 2.x offiziell möglich wurde, Edomi auf CentOS 7 zu betreiben. Die Frage nach dem Upgrade des OS bei bestehenden Installationen stellt sich da eigentlich nicht.
die Option dazu bringt die Frage mit, wie man es denn für sich weiter machen möchte. Für die Frage der Anzahl Installationen ist es sicher nicht relevant. Aber ich nehme an, dass jeder Upgrader darüber nachdenkt auf welchem COS er weiter macht.
Wo Du sicher recht hast, dass das COS nicht von zentraler Bedeutung ist: Der Schritt edomi 1.64 auf 2.xx ist erheblich größer als von COS6.5 auf COS7.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar