Gérer des données très volumineuses avec mysql

MySQL peut-il raisonnablement effectuer des requêtes sur des milliards de lignes ? -- MySQL peut 'gérer' des milliards de lignes. "Raisonnablement" dépend des requêtes ; allons les voir.

InnoDB (MySQL 5.5.8) est-il le bon choix pour des lignes de plusieurs milliards ? -- La 5.7 a quelques améliorations, mais la 5.5 est plutôt bonne, bien qu'elle soit près de 6 8 ans, et sur le point de n'est plus pris en charge.

Meilleur magasin de données pour des milliards de lignes -- Si vous voulez dire "Engine", alors InnoDB.

Quelle taille une base de données MySQL peut-elle atteindre avant que les performances ne commencent à se dégrader ? Encore une fois, cela dépend des requêtes. Je peux vous montrer une table de 1 000 lignes qui va s'effondrer ; J'ai travaillé avec des tables d'un milliard de lignes qui bourdonnaient.

Pourquoi MySQL pourrait être lent avec de grandes tables ? -- les balayages de plage conduisent à des E/S, qui sont la partie lente.

Mysql peut-il gérer des tables qui contiendront environ 300 millions d'enregistrements ? - encore une fois, oui. La limite se situe autour d'un billion de lignes.

(pour les tables InnoDB, ce qui est mon cas) en augmentant innodb_buffer_pool_size (par exemple, jusqu'à 80 % de la RAM). De plus, j'ai trouvé d'autres paramètres de réglage des performances MySQL ici dans le blog Percona -- oui

avoir des index appropriés sur la table (en utilisant EXPLAIN sur les requêtes) - eh bien, voyons-les. Il y a beaucoup d'erreurs qui peuvent être commises dans cette critique zone.

partitionner la table -- "Le partitionnement n'est pas une panacée !" J'en parle dans mon blog

MySQL Sharding - Actuellement, c'est du bricolage

Clustering MySQL - Actuellement, la meilleure réponse est une option basée sur Galera (PXC, MariaDB 10, DIY w/Oracle). La "réplication de groupe" d'Oracle est un concurrent viable.

Le partitionnement ne prend pas en charge FOREIGN KEY ou "global" UNIQUE .

Les UUID, à l'échelle dont vous parlez, ne vont pas seulement ralentir le système, mais en fait le tuer. UUID de type 1 peut être une solution de contournement.

Vitesse d'insertion et de création d'index -- Il existe trop de variations pour donner une seule réponse. Voyons votre essai CREATE TABLE et comment vous avez l'intention d'introduire les données.

Beaucoup de jointures -- "Normaliser, mais ne pas trop normaliser." En particulier, ne normalisez pas les datetimes ou les flottants ou autres valeurs "continues".

Construisez tableaux récapitulatifs

2,3 millions de transactions par jour -- Si c'est 2,3 millions d'inserts (30/sec), alors il n'y a pas vraiment de problème de performances. Si plus complexe, alors RAID, SSD, traitement par lots, etc., peuvent être nécessaires.

traiter un tel volume de données - Si la plupart des activités concernent les lignes "récentes", alors le pool de tampons "mettra en cache" l'activité, évitant ainsi les E/S. Si l'activité est "aléatoire", alors MySQL (ou n'importe qui else) aura des problèmes d'E/S.

Réduire les types de données aide dans une table comme la vôtre. Je doute que vous ayez besoin de 4 octets pour spécifier fuel_type . Il existe plusieurs approches à 1 octet.