Ich habe Probleme mit dem Massenimport einer ziemlich großen InnoDB-Tabelle, die aus ungefähr 10 Millionen Zeilen (oder 7 GB) besteht (was für mich die größte Tabelle ist, mit der ich bisher gearbeitet habe).
Ich habe einige Nachforschungen angestellt, wie die Importgeschwindigkeit von Inno verbessert werden kann, und im Moment sieht mein Setup folgendermaßen aus:
/etc/mysql/my.cnf/
[...]
innodb_buffer_pool_size = 7446915072 # ~90% of memory
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_io_capacity = 5000
innodb_thread_concurrency=0
innodb_doublewrite = 0
innodb_log_file_size = 1G
log-bin = ""
innodb_autoinc_lock_mode = 2
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit=2
innodb_buffer_pool_instances=8
import is done via bash script, here is the mysql code:
SET GLOBAL sync_binlog = 1;
SET sql_log_bin = 0;
SET FOREIGN_KEY_CHECKS = 0;
SET UNIQUE_CHECKS = 0;
SET AUTOCOMMIT = 0;
SET SESSION tx_isolation='READ-UNCOMMITTED';
LOAD DATA LOCAL INFILE '$filepath' INTO TABLE monster
COMMIT;
Daten werden in einer CSVDatei bereitgestellt .
Derzeit teste ich meine Einstellungen mit kleineren 'Test-Dumps' mit jeweils 2 Millionen, 3 Millionen, ... Zeilen und time import_script.shvergleiche die Leistung.
Nachteil ist, dass ich nur eine Gesamtlaufzeit bekomme, also muss ich warten, bis der vollständige Import abgeschlossen ist, um ein Ergebnis zu erhalten.
Meine bisherigen Ergebnisse:
- 10 000 Zeilen: <1 Sekunde
- 100 000 Zeilen: 10 Sekunden
- 300 000 Zeilen: 40 Sekunden
- 2 Millionen Zeilen: 18 Minuten
- 3 Millionen Zeilen: 26 Minuten
- 4 Millionen Zeilen: (nach 2 Stunden storniert)
Es scheint, dass es keine "Kochbuch" -Lösung gibt und man die optimale Mischung der Einstellungen selbst herausfinden muss.
Neben Vorschlägen, was in meinem Setup geändert werden soll, würde ich mich auch über weitere Informationen freuen, wie ich den Importprozess besser bewerten / mehr Einblicke gewinnen könnte, was passiert und wo der Engpass liegen könnte.
Ich habe versucht, die Dokumentation zu den Einstellungen zu lesen, die ich ändere, aber andererseits sind mir keine Nebenwirkungen bekannt und ob ich die Leistung mit einem schlecht gewählten Wert sogar verringern könnte.
Im Moment möchte ich einen Vorschlag aus dem Chat ausprobieren, der MyISAMbeim Import verwendet werden soll, und anschließend die Tabellen-Engine ändern.
Ich würde es gerne versuchen, aber im Moment DROP TABLEdauert es auch Stunden, bis meine Abfrage abgeschlossen ist. (Was ein weiterer Indikator zu sein scheint, ist meine Einstellung weniger als optimal).
Zusätzliche Informationen:
Der Computer, den ich derzeit verwende, verfügt über 8 GB RAM und eine Solid State Hybrid-Festplatte mit 5400 U / min.
Während wir auch versuchen, veraltete Daten aus der fraglichen Tabelle zu entfernen, brauche ich noch einen etwas schnellen Import, um
a) automatic data cleanup featurewährend der Entwicklung zu testen und
b) falls unser Server abstürzt, möchten wir unseren 2. Server als Ersatz verwenden (der benötigt wird) - Bisherige Daten, letzter Import dauerte mehr als 24 Stunden)
mysql> SHOW CREATE TABLE monster\G
*************************** 1. row ***************************
Table: monster
Create Table: CREATE TABLE `monster` (
`monster_id` int(11) NOT NULL AUTO_INCREMENT,
`ext_monster_id` int(11) NOT NULL DEFAULT '0',
`some_id` int(11) NOT NULL DEFAULT '0',
`email` varchar(250) NOT NULL,
`name` varchar(100) NOT NULL,
`address` varchar(100) NOT NULL,
`postcode` varchar(20) NOT NULL,
`city` varchar(100) NOT NULL,
`country` int(11) NOT NULL DEFAULT '0',
`address_hash` varchar(250) NOT NULL,
`lon` float(10,6) NOT NULL,
`lat` float(10,6) NOT NULL,
`ip_address` varchar(40) NOT NULL,
`cookie` int(11) NOT NULL DEFAULT '0',
`party_id` int(11) NOT NULL,
`status` int(11) NOT NULL DEFAULT '2',
`creation_date` datetime NOT NULL,
`someflag` tinyint(1) NOT NULL DEFAULT '0',
`someflag2` tinyint(4) NOT NULL,
`upload_id` int(11) NOT NULL DEFAULT '0',
`news1` tinyint(4) NOT NULL DEFAULT '0',
`news2` tinyint(4) NOT NULL,
`someother_id` int(11) NOT NULL DEFAULT '0',
`note` varchar(2500) NOT NULL,
`referer` text NOT NULL,
`subscription` int(11) DEFAULT '0',
`hash` varchar(32) DEFAULT NULL,
`thumbs1` int(11) NOT NULL DEFAULT '0',
`thumbs2` int(11) NOT NULL DEFAULT '0',
`thumbs3` int(11) NOT NULL DEFAULT '0',
`neighbours` tinyint(4) NOT NULL DEFAULT '0',
`relevance` int(11) NOT NULL,
PRIMARY KEY (`monster_id`),
KEY `party_id` (`party_id`),
KEY `creation_date` (`creation_date`),
KEY `email` (`email`(4)),
KEY `hash` (`hash`(8)),
KEY `address_hash` (`address_hash`(8)),
KEY `thumbs3` (`thumbs3`),
KEY `ext_monster_id` (`ext_monster_id`),
KEY `status` (`status`),
KEY `note` (`note`(4)),
KEY `postcode` (`postcode`),
KEY `some_id` (`some_id`),
KEY `cookie` (`cookie`),
KEY `party_id_2` (`party_id`,`status`)
) ENGINE=InnoDB AUTO_INCREMENT=13763891 DEFAULT CHARSET=utf8
SHOW CREATE TABLE yourtable\Guns aus, um uns die Tabellenstruktur dieser 10-Millionen- Zeilentabelle zu zeigen.
innodb_doublewrite = 0) ist Ihre MySQL-Installation nicht absturzsicher: Wenn Sie einen Stromausfall haben (kein MySQL-Absturz), werden Ihre Daten möglicherweise unbemerkt beschädigt.
