Diskussionsthread EDOMI-Releases/Updates

[gaert]

Ohne Worte:

Bildschirmfoto 2020-02-03 um 11.30.30.png

[gaert]

Es werden aber nur die ersten 10 Befehle angezeigt (bei mehr Befehlen wird ein entsprechender Hinweis angezeigt).

[trollmar]

Mega. Nach dem ganzen visu Kram mal endlich was für mich

[gaert]

Dann wird Dir evtl. auch die neue Ausgangsbox gefallen: Dort kann man einen Vergleichswert einbeziehen und 'ne Sperre ist auch gleich eingebaut

[trollmar]

Ja. Danke!!!

[givemeone]

gaert,
ich habe ein Performance-Problem bei Plots, da ich einfach zu viele Daten habe.
Als Lösung habe ich für mich gefunden, dass es bestens funktioniert, wenn ich
in archivKoData für jedes targetid eine Datenbank-Partition anlege.

(einfach per)

CREATE TABLE `archivKoData` (
`datetime` DATETIME NULL DEFAULT NULL,
`ms` INT(11) NULL DEFAULT NULL,
`targetid` BIGINT(20) UNSIGNED NULL DEFAULT '0',
`gavalue` VARCHAR(10000) NULL DEFAULT NULL,
INDEX `datetime` (`datetime`, `ms`),
INDEX `targetid` (`targetid`)
)
COLLATE='latin1_swedish_ci'
ENGINE=MYISAM
PARTITION BY RANGE (targetid)
(
PARTITION p1 VALUES LESS THAN (1),
PARTITION p2 VALUES LESS THAN (2),
PARTITION p3 VALUES LESS THAN (3),
...
PARTITION p1000 VALUES LESS THAN (1000)
)
;

Die Geschwindigkeit ist genial verbessert!

Spricht aus deiner Sicht etwas dagegen?


sG
Joe

[Lonie]

Ich seh noch nicht ganz warum es die Abfrage beschleunigt. Es teilt ja nur die Daten anhand des zugehörigen Objektes auf. Müsste ich raten würde ich sagen dass kein Index bei der Abfrage genutzt wird, das bekommt man aber relativ einfach mit einem EXPLAIN heraus. Dafür benötigt man aber die Abfrage die Edomi zum holen der Daten absetzt.
Partitionen sind nicht für deinen Anwendungsfall gedacht

[Lonie]

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

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

Vorher:

+------+-------------+--------------+------+-------------------+----------+---------+-------+-------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+--------------+------+-------------------+----------+---------+-------+-------+-------------+
| 1 | SIMPLE | archivKoData | ref | datetime,targetid | targetid | 9 | const | 85932 | Using where |
+------+-------------+--------------+------+-------------------+----------+---------+-------+-------+-------------+

Nachher:

+------+-------------+--------------+-------+------------------------+------+---------+------+-------+-----------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+--------------+-------+------------------------+------+---------+------+-------+-----------------------+
| 1 | SIMPLE | archivKoData | range | datetime,targetid,Test | Test | 18 | NULL | 19545 | Using index condition |
+------+-------------+--------------+-------+------------------------+------+---------+------+-------+-----------------------+

[givemeone]

Hallo Marcel,

Partitionen sind nicht für deinen Anwendungsfall gedacht

für welchen denn dann? (ja, die Bereinigung von Edomi nutzt die Partitionen nicht, ...)
Damit habe ich für jedes Datenarchiv eine eigene Partition (eigene DB), und da abfragen immer nur ein Datenarchiv betreffen, reicht so das Lesen aus dieser Partition.
Wie auch immer, das Anzeigen des Plots wurde damit enorm beschleunigt, besonders für feinrasterige Plots mit mehreren (>6) Datenarchiven.

Danke auch für deinen Index. Habe diesen jetzt einfach mal zusätzlich auch meine partitionierte DB gelegt und messe die Ergebnisse später.
Werde zum Vergleich danach auch noch ohne Partition messen, aber für gerade ist Edomi so für mich wieder sehr performant.

sG
Joe

[Lonie]

Die Basis für deine Partitionierung ist dynamisch. Mit jedem neuen Datenarchiv müsstest du deine Tabellenstruktur anpassen. Das will man so nicht als Algorithmus in ein Produkt integrieren.

[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.

[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?

[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?

[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

[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!