In 2021-01-08 16_44_39-Datenbank.png sehe ich, dass ENGINE=Aria im Einsatz ist. Würde ENGINE=InnoDB schneller funktionieren? Um welche genaue Version von MariaDB 10.5 geht es?

Bei schreibintensivem Einsatz möchte ich auf MDEV-24537 hinweisen.

Maria DB 10.5.6 ist im Einsatz.

Deswegen Aria oder hat sich das geändert?
PERFORMANCE RESULTS
InnoDB Aria MyISAM
SQL 1 2.389 0.580 0.634
SQL 2 2.169 0.530 0.598

Es kommt auf die Tabellenstruktur und die Art der Anfragen an. Ohne SHOW CREATE TABLE oder EXPLAIN SELECT kann man nicht viel sagen.

Aber ja, seit 10.5.6 wurde die Schreibleistungsfähigkeit von InnoDB in MDEV-23399 und MDEV-23855 verbessert. Möglicherweise könnte auch MDEV-20487 eine Rolle spielen.

was bedeuten die Werte in PERFORMANCE RESULTS ?
Innodb is 4-5 mal schneller als Aria oder wie soll man es interpretieren?

Umgekehrt Aria ist schneller als innodb

Tobias.Beissmann@egoproducts.com, können Sie uns mehr Daten geben? Ideal wäre eine Skript, die das Problem mit automatisch erzeugten Daten demonstriert. Könnten Sie uns mindestens folgendes teilen (in Textformat):

• SHOW CREATE TABLE von der beteiligten Tabelle
• EXPLAIN SELECT für die langsamen Abfragen

Die Tabellen- und Spaltennamen können Sie ändern, falls sie geheim sind.

CREATE TABLE `qs_master` (
`BLOCK_KEY` varchar(25) COLLATE latin1_german1_ci NOT NULL,
`START` datetime DEFAULT NULL,
`END` datetime DEFAULT NULL,
`SN` int(10) DEFAULT NULL,
`PLACE_ID` int(10) DEFAULT NULL,
`RESULT` varchar(10) COLLATE latin1_german1_ci DEFAULT NULL,
`PRODUCT_ID` varchar(35) COLLATE latin1_german1_ci DEFAULT NULL,
`POS_ID` int(10) DEFAULT NULL,
`BOARD_ID` varchar(18) COLLATE latin1_german1_ci DEFAULT NULL,
`SOFTWARE` varchar(20) COLLATE latin1_german1_ci DEFAULT NULL,
UNIQUE KEY `RESULT` (`BLOCK_KEY`,`RESULT`,`PRODUCT_ID`) USING BTREE,
KEY `block_key` (`BLOCK_KEY`) USING BTREE,
KEY `START` (`START`) USING BTREE,
KEY `SN` (`SN`) USING BTREE,
KEY `qs_master_idx_block_key_start` (`BLOCK_KEY`,`START`) USING BTREE
) ENGINE=Aria DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci PAGE_CHECKSUM=1

EXPLAIN SELECT
qs_master.START,
qs_master.SN As TRACE_NO,
qs_master.RESULT As RESULT_MAIN,
qs_master.PRODUCT_ID As TYPE,
qs_master.POS_ID,
qs_master.BOARD_ID,
qs_master.SOFTWARE
From
qs_master
Where
qs_master.START Between (Now() - Interval 91 Day) And (Now() - Interval 85 Day)

---------------------------------------------------------------------------------------+

Ich merke, dass die Tabelle keinen Primärschlüssel enthält. Das dürfte aber bei ENGINE=Aria keinen großen Unterschied machen; bei InnoDB vielleicht schon. Würde die Abfrage tatsächlich 706.872 Zeilen liefern?

Ich befürchte, dass wir ohne eine ausführbare Skript nicht weitermachen können. Unsere Support könnte Sie vielleicht schon helfen.

Ja das stimmt mit der Menge.

Was meinen sie mit ausführbarem Skript?

MariaDB habe ich mittlerweile auf 10.5.8 upgedatet.

Tobias.Beissmann@egoproducts.com, am einfachsten wäre uns ein Programm, dass die Tabelle anlegt und die Datenmenge erzeugt, so dass das Ergebnis beobachtet werden kann. Das Programm könnte SQL erzeugen, irgendwie so wie

programm | mysql -uroot test

Am einfachsten wäre das z.B. eine Perl-Skript, die sich beim Bedarf einfach ändern läßt.

Wenn Ich weiß wie, kann ich das gerne tun.
Was soll mit dem Schreiben festgestellt werden?

Tobias.Beissmann@egoproducts.com, screenshot-1.png ist eine Schritt in eine Richtung wo wir etwas ausführen könnten. Wir würden jedoch Text statt Bilder bevorzugen. Und das dort enthaltene Beispiel weicht wesentlich von Ihrem ursprünglichen CREATE TABLE ab, indem weder KEY noch WHERE vorhanden sind.

"Using index condition" soll nur möglich sein, wenn ein Index angewendet wird (wie KEY(START) und WHERE START… in der ursprünglichen Tabelle).

Ich hoffe, dass ich mich verständlich gemacht habe. Deutsch ist meine dritte Fremdsprache.

Ich habe den Benchmark Test von der MariaDB Seite (https://mariadb.com/kb/en/benchmarking-aria/) ausgeführt, weil ich dachte man kann hier etwas feststellen, woran das Problem liegt.

Ich habe noch mehrere Einstellungen an der my.ini vorgenommen, jedoch hat keine Änderung die Bandbreite erhöht, so dass ich mehr Daten übertragen kann.

Ich habe die qs_master Tabelle in InnoDB geändert und die Geschwindigkeit beim Auslesen, hat sich nicht verändert. ~9k Datensätze / Zyklus zu PowerBi

Wenn der Server nicht vom Disk liest (die Daten alle im Innodb Bufferpool), wäre es schon ein Erfolg.
Wie groß dabei innodb-buffer-pool-size sein soll ist die frage, und es ist sicherlich mehr als .ibd file. 1.5x der 2x mehr sollte langen. Falls vom Disk nicht mehr gelesen wird (was sogar im task manager angezeigt wird), ist der Server vorerst optimiert.

Sonst kann es natürlich liegt es auch an dem Klienten, wie schnell die daten rausgelesen werden, und an der menge der rausgelesenen Daten. Es kann sein, daß ODBC, oder welche Klienttechnologie auch immer sich unter diesem PowerBI verbirgt, das diese Komponente am Ende die Applikation ausbremst.

Hallo,
ich habe mittlerweile alle Tabellen auf InnoDB umgestellt, jedoch komme ich nicht über 4k-9k Datensätze/Zyklus.
Aktuelle my.ini

[mysqld]
port=3306
datadir=E:/data
tmpdir=E:/tmp

innodb_log_file_size=80M
innodb_file_per_table=1
innodb_buffer_pool_size=24G
join_buffer_size=1M
net_buffer_length=16M
innodb_io_capacity=1000
key_buffer_size=10M
thread_handling=pool-of-threads
skip-name-resolve

Tobias.Beissmann@egoproducts.com, es tut mir leid, ich hatte Ihre Antwort übersehen. Der Parameter innodb_log_file_size=80M ist sehr gering im Vergleich zu innodb_buffer_pool_size=24G. Ich habe eine Empfehlung gesehen, dass die Pufferpool-Größe etwa 60% bis 80% des Hauptspeichers betragen sollte, je nach dem, was für andere Puffer für die Arbeitslast nötig sind, oder was für andere Dienste auf dem System laufen.

Wenn es um die Log-Größe geht, habe ich eine Empfehlung gelesen, dass die Größe etwa dem Wachstum von LSN in einer Stunde entsprechen sollte. Eine zu kleine Logdatei wird häufige Log-Checkpoints und dadurch Schreiben der veränderten Datenseiten verursachen. So weit ich verstehe, ist die Log-Größe von Aria nicht begrenzt: neue Dateien können beim Bedarf angelegt werden. In InnoDB wird die Logdatei zyklisch beschrieben.

Vor MDEV-21351, MDEV-29911 und anderen Verbesserungen könnte ein Neustart der Datenbank nach einem Crash wegen Speichermangel fehlschlagen oder sehr langsam sein, bei einem großen innodb_log_file_size.

In MariaDB Server 10.6 wurde die Leistungsfähigkeit von InnoDB weiter verbessert.