93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)

[JoeALLb]

Der PK ersetzt "Search_Idx", du solltest "Search_Idx" löschen!

[DS_Starter]

Ja, guter Hinweis !
Ich prüfe in configCheck das Vorhandensein des Standardindex. Wenn der Nutzer einen anderen Index erstellt hat der diesen ersetzt, braucht es den Standardindex natürlich nicht.
Werde den Erläuterungstext dahingehend ändern dass der Nutzer darauf hingewiesen wird.

LG
Heiko

[SusisStrolch]

Anbei die V2.20.0 die ich euch bitte, insbesondere SusisStrolch, zu testen ob bei euch ebenfalls alles wie gewohnt sauber funktioniert.

Die Einträge tauchen nun sauber mit dem Reading "state" auf.
Vielen Dank für die schnelle Korrektur.

Wg. der Performance-Sache bin ich noch immer dran - weiß einfach nicht wo es da noch klemmen kann.
Den doppelten Index schließe ich mal als Ursache für diese extremen Unterschiede aus.

Momentan importiere ich in die MariaDB10, um zu sehen ob sich das System da genau so verhält.

[DS_Starter]

Danke für die Rückmeldung !

Ist sicherlich ein guter Weg nach dem Ausschlußverfahren. Eventuell lohnt es sich ein Ticket bei Syno aufzumachen. Es sind doch erhebliche Unterschiede in Performance feststellbar.

LG
Heiko

[DS_Starter]

Hallo zusammen,

die hier angehängte DbLog-Version 2.21.0 enthält neben den Anpassungen der 2.20.0 noch erweiterte Erläuterungen im configCheck sowie eine Heraufsetzung des Standard-Timeouts im asynchronen Betrieb auf 86400s.
Damit sollen potentielle Fehlermöglichkeiten bei lang laufenden Prozessen großer Datenbanken (z.B. Indexerstellung) vermieden werden.
Wer bereits das Attribut "timeout" auf einen eigenen Wert gesetzt hat und damit zufrieden ist kann es natürlich so lassen.

VG
Heiko

[SusisStrolch]

Kann das sein, dass ihr eure AriaDB mit

Code Auswählen Erweitern

ENGINE=Aria ... ROW_FORMAT=PAGE TRANSACTIONAL=0
angelegt habt?

Ich importiere momentan mit "LOAD DATA INFILE..." in eine Test-DB mit TRANSACTIONAL=0.
Die CPU-Last geht auf ~300% hoch (statt bisher ca. 100%), die Fortschrittsanzeige scheint mir auch deutlich flotter zu sein...

[DS_Starter]

Also bei mir zumindest ist das nicht der Fall. Die beschriebenen Tests habe ich alle noch mit der Engine InnoDb auf MariaDb5 durchgeführt. Das ist meine bisherige "alte" Datenbank. Umzug auf MariaDB 10 mit Aria-Engine kommt erst noch.

[SusisStrolch]

Ok... dann werde ich mal mit InnoDB ausprobieren...

[SusisStrolch]

So - hier mal mein "Abschlussbericht"...
Das Performance-Problem kommt tatsächlich daher, dass ich "Aria" als Engine verwende.
Die Operationen mit InnoDB sind min. Faktor 10 schneller, d.h. der Index war mit meinen Daten innerhalb eine Stunde aufgebaut.
Anlegen der InnoDB (READ INTO...), ohne Keys / Index,  dauerte knappe 2 Std.

Wenn ich die beiden so vergleiche, finde ich das Verhältnis Daten zu Index bei der InnoDB etwas heftig:

	Datensätze	Daten	Index
Aria	103.856.256	8,6 GiB	5,7 GiB
InnoDB	99.833.927	9,7 GiB	11,8 GiB

Die InnoDB wurde mit

Code Auswählen Erweitern

  PRIMARY KEY (`DEVICE`,`READING`,`TIMESTAMP`),
  KEY `Report_Idx` (`TIMESTAMP`,`READING`) USING BTREE,
  KEY `Reading_Time_Idx` (`READING`,`TIMESTAMP`) USING BTREE,
  KEY `Search_Idx` (`DEVICE`,`READING`,`TIMESTAMP`) USING BTREE

Aria (durch meine Spielereinen) mit

Code Auswählen Erweitern

  PRIMARY KEY (`DEVICE`,`READING`,`TIMESTAMP`),
  KEY `DbLog_Group` (`TIMESTAMP`,`DEVICE`,`READING`),
  KEY `Search_Idx` (`DEVICE`,`READING`,`TIMESTAMP`),
  KEY `Reading_Time_Idx` (`READING`,`TIMESTAMP`) USING BTREE,
  KEY `Test_Idx` (`DEVICE`,`READING`,`TIMESTAMP`)

erstellt.

So - hier noch ein Code-Snippet, mit dem man "auf die Schnelle" alle Einträge aus der Datenbank werfen kann, die in der Kombination "DEVICE,READING" nicht häufiger als 10x auftauchen...

Code Auswählen Erweitern

CREATE TEMPORARY TABLE tmptable
    SELECT `TIMESTAMP`, COUNT(*) as Nr, `DEVICE`, `READING`
    FROM `fhem`.`historyNew`
    GROUP BY  `DEVICE`,`READING`;
DELETE `h` FROM `fhem`.`historyNew` AS h
  INNER JOIN `tmptable` AS t
  ON `t`.Nr < '10' AND `h`.`TIMESTAMP` = `t`.`TIMESTAMP` AND `h`.`DEVICE` = `t`.`DEVICE` AND `h`.`READING` = `t`.`READING`;

Query OK, 1822 rows affected (7.68 sec)


und - als Vergleich - auf der Aria:

Code Auswählen Erweitern


Query OK, 2231 rows affected (45.53 sec)


[DS_Starter]

Hi,

Danke für die Info !
Dieser Unterschied ist tatsächlich unglaublich !

Dann muss ich auch noch einmal meinen Ansatz überdenken beim Switch zu Maria 10 ebenfalls zu Aria zu wechseln.
Interessant wäre noch die Erfahrung von Joe, denn er hat Aria im Einsatz und kommt auf ähnliche Performance wie ich mit InnoDb.

Schönes Snippet 

VG
Heiko

[SusisStrolch]

Interessant wäre noch die Erfahrung von Joe, denn er hat Aria im Einsatz und kommt auf ähnliche Performance wie ich mit InnoDb.

Da wären natürlich Konfiguration und Plattform des SQL-Servers interessant...

[SusisStrolch]

Hab' jetzt noch mal ein wenig auf die Read-Performance geschaut.

Code Auswählen Erweitern

Test: MariaDB10, query: count(TYPE) from history
Aria: 3 min 35.80 sec
InnoDB: 6 min 28.39 sec

Aus Sicht der Datenmenge und der Lese-Performance ist die Aria nicht schlecht. Und so häufig werden wohl auch keine Idx neu aufgebaut.
Evtl. sollte man die Notwendigkeit der TRANSACTIONAL-Option noch einmal überdenken (die ist per default aktiviert).

[DS_Starter]

Dasselbe Testscenario habe ich jetzt bei meiner MariaDB10 ausgeführt und bekomme eine genau gegensätzliche Read-Performance.
In meinem Test ist InnoDB etwas schneller als Aria.

Maria10 (Größe Daten ca. 600MB)

Aria-Engine:

select count(TYPE) from history  -> 6199328 insgesamt, Die Abfrage dauerte 16.1305 Sekunden.

InnoDB-Engine:

select count(TYPE) from test -> 5780060 insgesamt, Die Abfrage dauerte 14.2124 Sekunden.

Wenn ich etwas mehr Zeit habe, versuche ich das Ganze nochmal mit größeren Datenmengen.

EDIT:

Bei größeren Tabellen drehen sich die Verhältnisse offensichtlich zu Gunsten von Aria:

MariaDB 5 (Größe ca. 5,5 GB)

Aria-Engine:

select count(TYPE) from test  -> 55649759 insgesamt, Die Abfrage dauerte 87.3970 Sekunden.

InnoDB-Engine:

select count(TYPE) from history -> 52078133 insgesamt, Die Abfrage dauerte 154.3552 Sekunden.

[SusisStrolch]

Bei größeren Tabellen drehen sich die Verhältnisse offensichtlich zu Gunsten von Aria:

Das wäre jetzt meine Frage gewesen -  500MB vs. >> nGB

Kannst Du mal deine 5GB Datenbank in ne Aria importieren?

Mich würde da der Durchsatz beim Import interessieren...
Ich komme bei den ~8GB auf ca 1GB/Stunde.
Die Platten der Syno schlafen hierbei - da geht max. 1MB/s rüber - ziemlich konstant.
Wenn ich die InnoDB in der Größe anlege, kommen häufiger Peaks von >20MB/s.

[DS_Starter]

Kann ich machen. Mit SQL-Export / Import ? Sonst nehme ich nämlich Export to / Import from File.