Diskussionsthread EDOMI-Releases/Updates

[ThomasCologne]

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.

[rdeckard]

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)

[vento66]

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.

[mfd]

Das dürfte schwer abzuschätzen sein. Anzahl der Downloads der Software/Updates?
Oder eher anhand der Nutzer, die in diesem Unterforum unterwegs sind... ?

[ThomasCologne]

Ein wenig OT, aber weißt du gaert in etwa wie viele edomi Nutzer es mittlerweile gibt?

Gruß

[EinAnfaenger]

Ich habe das mit dem Index bei mal ausprobiert. Ich musste aber SQL-Statement anpassen:

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:

[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

[SvenA]

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!

[Lonie]

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

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.

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)

[SvenA]

Das kann eigentlich nicht nur am Index liegen. Hast Du auch die Partitionierung da mit drin?

[Lonie]

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.

[SvenA]

Man erkauft sich das mit ca. 50% mehr Speicherplatz für diese Tabelle.

Wieso 50%? Das sind doch nur drei 64-Bit Werte je Eintrag plus ein wenig Overhead für die B-Tree Struktur.
Also nicht so dramatisch...
Daher bin ich auch für das Hinzufügen es sinnvollen Index!

[Lonie]

Abfragen welche das Datum eingrenzen werden dadurch beschleunigt. Davor konnte der Index auf datetime nicht genutzt werden. Man erkauft sich das mit ca. 50% mehr Speicherplatz für diese Tabelle

[starwarsfan]

Hallo miteinander

Ich habe mal etwas gespielt. Du könntest einfach einen passenden Index hinzufügen.

ALTER TABLE `archivKoData` ADD INDEX `Test` (`targetid`, `datetime`);

Das hört sich interessant an! Ich habe auch das Problem, dass gewisse Diagramme sehr lange Ladezeiten habe. Wie allgemeingültig ist denn dieser Schnipsel da oben? Kann man das direkt so ausführen? Wenn ja, vielleicht wäre das ja sogar eine Verbesserung, welche per Default in Edomi integriert werden könnte?

[saegefisch]

Und: Beim Lang-Klick auf dem iPad kommt das Kontextmenü ("Bild kopieren")...

Habe ich das überlesen oder hat jemand eine Lösung dafür? Jetzt haben wir den schönen Lang-Klick und das ipad kommt in die Quere.
Kann man den Langklick in edomi verkürzen oder im ipad verlängern oder einschränken? Oder ganz anderes?

[givemeone]

Ja, und nein. Als letzte Partition habe ich eine Art catch-all, also tatsächlich keine Notwendigkeit, das immer anzupassen.

Genau genommen muss ich es erst dann anpassen, wenn ich viel zu viele Datenarchive und dort wieder Performance-Probleme bekomme.