Pourquoi NE PAS partitionner?

Quand ne voudrait-on PAS partitionner une base de données? (en pensant au partitionnement MySQL )

Dans mon cas

Je vais commencer par quelques millions de lignes, il devrait augmenter à partir de là.
Clé primaire sur un champ de caractère qui sert de contrainte de requête la plus fréquente (et les recherches sont fréquentes - au moins quelques-unes par seconde).
La clé primaire serait hachée pour servir de clé de partition
Des mises à jour seront apportées à chaque ligne extraite dans les requêtes fréquentes mentionnées ci-dessus
Les recherches moins fréquentes (par rapport aux colonnes de date ou autres) devront frapper toutes les partitions

Même pour le dernier point, la recherche ne s'exécute-t-elle pas en parallèle, donc dans tous les cas, est-ce une victoire ? Quels sont les inconvénients du partitionnement? Pourquoi n'est-ce pas quelque chose que TOUT LE MONDE utilise par défaut, au moins lorsque vous regardez un million + d'enregistrements?

MISE À JOUR - J'ai sélectionné la réponse de zgguy mais notez que j'ai ajouté ma propre réponse avec les résultats de ma propre recherche, y compris un lien vers une très bonne réponse à une question similaire qui m'a été très utile.

mysql database-design partitioning

— chell
source

Réponses:

Il n'y a pas de solution miracle pour les problèmes de performances, et le partitionnement n'en est pas un non plus.

Chaque partition est essentiellement une table pour elle-même. Par conséquent, les requêtes qui sont écrites d'une manière qui permet à la base de données de rechercher des lignes dans une seule partition deviennent plus rapides. La différence peut être énorme pour les requêtes qui devraient analyser toute la grande table, mais peuvent se limiter à analyser une seule partition de la table partitionnée. Pour les recherches de clés uniques, la différence est beaucoup plus petite.

Cependant, les requêtes qui utilisent des recherches d'index d'une manière qui oblige la base de données à visiter toutes ou la plupart des partitions de table (index) s'exécuteront considérablement plus lentement.

L'exécution parallèle est un sujet en soi. Si vous exécutez de grands lots pendant la nuit et que toute la machine effectue ce travail, sa parallélisation est une bonne chose. Cependant, dans un système OLTP où la base de données sert constamment des requêtes de nombreux utilisateurs simultanés, vous ne voulez pas qu'un seul utilisateur utilise toutes les ressources.

— zgguy
source

Les recherches de clés primaires / uniques ne verront donc pas vraiment d'amélioration (le cas échéant?) Car l'index PK est plus rapide? Est-ce général: y a-t-il des moments où un index PK est plus lent? Que se passe-t-il si les recherches sont faussées vers des PK ajoutés récemment? Est-ce qu'une partition basée sur le PK (je pense que l'algo de la clé de partition devrait être un module ou similaire et NON un hachage, non?) Qui fait que la plupart des activités ne frappent qu'une seule partition serait utile?

— chell

Les recherches de clés primaires / uniques verront au mieux une amélioration mineure des performances. D'un autre côté, si votre objectif est de réduire les conflits d'instructions DML, vous devez partitionner de manière à ce que DML soit réparti également sur toutes les partitions au lieu de se concentrer sur quelques-unes d'entre elles.

— zgguy

désolé de revenir 10 jours plus tard, mais vous soulevez un point clé - Vous avez fourni une bonne raison de considérer que le partitionnement n'est peut-être pas nécessaire, cependant , mon scénario comprend la mise à jour de chaque enregistrement après sa lecture (plusieurs par seconde). La nécessité de tant d'écritures rend-elle les arguments plus convaincants pour les partitions (avec une distribution uniforme), de sorte que la charge d'écriture est répartie?

— chell

J'essaie également de comprendre votre commentaire sur les requêtes qui ont touché de nombreuses partitions (qui sont plus lentes). Si les requêtes concernent le PK qui est également utilisé (haché) comme clé de partition, la base de données ne sait-elle pas immédiatement vers quelle partition se baser en fonction du hachage de la recherche? Merci pour l'aide!

— chell

Désolé, je n'ai pas pu visiter l'échange de pile récemment. La réponse à laquelle vous avez lié est excellente. Je crois que cela répond à vos deux questions.

— zgguy

La réponse ici est bien écrite et fait des arguments similaires à la réponse de zgguy , que le partitionnement ne vous rapporte pas beaucoup, le cas échéant, un scénario à une seule machine où les recherches les plus fréquentes sont basées sur la clé primaire ou quelque chose de similaire (parce que les recherches indexées devraient être tout aussi rapides).

En fait, un fil conducteur commun semble être que la principale raison de la partition est tangentielle et principalement liée à la gestion: par exemple, séparez vos données en fonction de la date si vous devez purger les anciens enregistrements de temps en temps. Bien qu'il ait été noté que cela peut également améliorer vos performances de recherche si vos données sont telles que la plupart des requêtes ne toucheront que les enregistrements récemment ajoutés.

J'ai également vu mentionner que MySQL ne fait jamais rien en parallèle (ce serait bien de voir des liens ou plus d'explications à ce sujet).

Personne n'a vu si l'activité d'écriture ajoute ou non des considérations différentes.

— chell
source

Je ne pense pas que les écritures changent votre réponse. Vous avez mentionné 2 des 4 cas d'utilisation que j'ai trouvés. Toujours pas de parallélisme, même en 8.0.

— Rick James

La première chose qui me vient à l'esprit est l' élagage des partitions ; si ce n'est pas quelque chose que vos requêtes peuvent utiliser.

Allez-vous avoir besoin de purger une grande quantité de données de la table car le partitionnement vous aiderait. Bien que vieux mais ce post de Peter a peu de points à considérer.

et une autre chose à laquelle on peut penser est la facilité d'utilisation pour les tables simples ... le partitionnement nécessite un travail et une maintenance supplémentaires.

— mysql_user
source

Les versions plus récentes ont une syntaxe pour limiter explicitement la requête à une partition. Je ne peux pas penser à une raison valable pour jamais utiliser un tel.

— Rick James