Comment puis-je optimiser MySQL pour les insertions batch massives à partir d'une application Java?

Question

Je suis en cours d'exécution des tests sur un Pro Windows 7 64 bits
Il a un i7-6700 et 8 Go de RAM
j'accéder à des fichiers à partir d'un SSD et leur traitement par une application de la console Java qui transforme et charges les dans un serveur mySQL sur la même machine, mais sur un disque dur mécanique séparé.

J'ai désactivé Page Dépôt
J'ai mis innodb_buffer_pool_size ensemble de 8M à 2G
J'ai mis innodb_thread_concurrency ensemble de à
I 'set innodb_buffer_pool_instances jeu de à 16
J'ai mis max_connections ensemble de à
Pour une raison quelconque, quoi que ce soit plus élevé que cela, le serveur crash au démarrage. J'ai vérifié l'installation et MySQL rapporte que c'est une installation AMD64, mais les limitations de mémoire que je rencontre me font me demander s'il s'agit vraiment d'une installation 32 bits.

Je suis particulièrement avoir problème avec celui-objet, structure ci-dessous
CustomObject1
Chaîne custObj1str1
Chaîne custObj1str2
Chaîne custObj1str3
Chaîne custObj1str4
int custObj1int1
int custObj1int2
flotteur [7] custObj1fltArr1
flotter [7] custObj1fltArr2
ArrayList custObj2

CustomObject2
int custObj2int1
flotteur [4] custObj2fltArr1

I fait un HashKey pour custObj1 de custObj1str1, custObj1str2, custObj1str3, custObj1str4, custObj1int1, custObj1int2 et je l'utilise comme une clé primaire. Cet objet va dans 4 tables distinctes.

table1
int hashkey (clé primaire)
varchar custObj1str1
varchar custObj1str2
varchar custObj1str3
varchar custObj1str4
int custObj1int1
int custObj1int2

table2
int hashkey (clé primaire)
custObj1fltArr1 flotteur [0] ... flotteur custObj1fltArr1 [6]

table3
int hashkey (clé primaire)
custObj1fltArr2 flotteur [0] ... flotter custObj1fltArr2 [6]

table4
int hashkey (clé primaire, pt 1)
int custObj2int1 (clé primaire, pt 2)
flotteur custObj1fltArr2 [0] ... flotter custObj2fltArr1 [4]

En Java, je fais préparés instructions SQL avec le traitement par lots
Pour table1 ->"INSERT INTO table1 VALEURS (?,?,?,?,?,?,?,?) SUR DUPLICATE KEY UPDATE" + primaryKey + "=" + primaryKey
Pour table4 ->"INSERT INTO table4 VALEURS (?,?,?,?,?,?) SUR DUPLICATE KEY UPDATE "+ primaryKey +" = "+ primaryKey +" ET "+ foreignKey +" = "+ foreignKey
Je croyais e que pour table4, certaines données sont écrasées parce que c'est beaucoup de données (plus de 30M enregistrements).

Ceci est juste pour une journée de données, je vais potentiellement devoir gérer 4 ans de valeur.

Image of Table Status (sensitive info redacted)
Un conseil serait grandement apprécié.

** Mise à jour **

J'ai essayé d'utiliser mySQL sur mon MacBook Pro (fin 2013 avec Core i7, RAM de 16 Go et SSD). C'était lent, mais toujours sensiblement plus rapide que la machine Windows.

MacBook Metrics
Je mis les méthodes qui font les téléchargements par lots comme synchrone afin de limiter la quantité de données qui sont importées dans la même table. Devrais-je limiter cela par base de données, le laisser tel quel ou l'enlever complètement? J'utilise un pool de threads de 8 points, mais j'aimerais l'augmenter.

Answer 1

Cette valeur de Data_length est étrangement proche de 2^31. Quel système de fichiers réside sur mysql? NTFS devrait être OK, mais je soupçonne que FAT16 et FAT32 ont des limitations. (Les bases de données ont connu une croissance plus rapide que celle de Windoz.

Voyons le journal. Et 32 bits expliquerait le crash (et ce serait dans le journal). Si 32 bits, désactivez les 4 changements que vous mentionnez, mais ayez innodb_buffer_pool_size = 1500M. Même si 64 bits et s'écraser, voir si cela aidera.

Pour déterminer les lots, indiquez SHOW CREATE TABLE et le nombre de rangs que vous souhaitez grouper en même temps.

Limitation du système d'exploitation?

Première mise à niveau vers MySQL 64 bits. Si cela ne suffit pas ...

Voir le système de fichiers concerné et voir s'il existe une solution de rechange. Sinon ...

Si le problème est une limitation du système d'exploitation de la taille du fichier, il peut être une solution de contournement via MySQL.

• ibdata1 peut être en fait un ensemble de fichiers, et vous pourriez limiter chacun à, disons, 1 Go. Voir le manuel. Si vous ne pouvez pas le trouver, je vais le déterrer.

• Une table peut être PARTITIONed est une sorte de telle que chaque partition est suffisamment petite pour tenir dans la limitation du système d'exploitation. Cela nécessite innodb_file_per_table=ON et une conception soignée de la façon de faire le partitionnement. J'ai besoin de voir SHOW CREATE TABLE et avoir une idée de ce que les valeurs sont dans chaque colonne avant de conseiller plus loin. 5.7 permet de spécifier où placer chaque partition - ce qui serait pratique si le lecteur entier avait une limitation. (Par opposition à chaque fichier .)