J'ai déjà travaillé avec une très grande base de données MySQL (Terabyte +). La plus grande table que nous avions comptait littéralement plus d'un milliard de lignes.
Ça a marché. MySQL a traité les données correctement la plupart du temps. C'était quand même extrêmement peu maniable.
Le simple fait de sauvegarder et de stocker les données était un défi. Il faudrait des jours pour restaurer la table si nous en avions besoin.
Nous avions de nombreuses tables dans la plage de 10 à 100 millions de lignes. Toute jointure importante aux tables prenait trop de temps et prenait une éternité. Nous avons donc écrit des procédures stockées pour « parcourir » les tables et traiter les jointures par rapport à des plages d'ID. De cette façon, nous traiterions les données de 10 à 100 000 lignes à la fois (joindre contre les identifiants 1-100 000 puis 100 001-200 000, etc.). C'était beaucoup plus rapide que de rejoindre toute la table.
L'utilisation d'index sur de très grandes tables qui ne sont pas basées sur la clé primaire est également beaucoup plus difficile. Mysql stocke les index en deux parties -- il stocke les index (autres que l'index primaire) en tant qu'index des valeurs de clé primaire. Ainsi, les recherches indexées sont effectuées en deux parties :d'abord MySQL va à un index et en extrait les valeurs de clé primaire qu'il doit trouver, puis il effectue une seconde recherche sur l'index de clé primaire pour trouver où se trouvent ces valeurs.
Le résultat est que pour les très grandes tables (plus de 1 à 200 millions de lignes), l'indexation par rapport aux tables est plus restrictive. Vous avez besoin d'index moins nombreux et plus simples. Et faire même de simples instructions de sélection qui ne sont pas directement sur un index peut ne jamais revenir. Les clauses Where doivent appuyez sur les index ou oubliez-le.
Mais tout cela étant dit, les choses ont réellement fonctionné. Nous avons pu utiliser MySQL avec ces très grandes tables, faire des calculs et obtenir des réponses correctes.
