Partitionnement / Sharding / Fractionnement MySQL - quelle voie suivre ?
https://stackoverflow.com/questions/45879
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Nous disposons d'une base de données InnoDB d'environ 70 Go et nous prévoyons qu'elle atteindra plusieurs centaines de Go au cours des 2 à 3 prochaines années.Environ 60 % des données appartiennent à une seule table.Actuellement, la base de données fonctionne plutôt bien car nous disposons d’un serveur avec 64 Go de RAM, donc presque toute la base de données tient en mémoire, mais nous sommes préoccupés par l’avenir lorsque la quantité de données sera considérablement plus importante.Nous réfléchissons actuellement à un moyen de diviser les tableaux (en particulier celui qui représente la plus grande partie des données) et je me demande maintenant quelle serait la meilleure façon de le faire.
Les options que je connais actuellement sont
- Utilisation du partitionnement MySQL fourni avec la version 5.1
- Utiliser une sorte de bibliothèque tierce qui encapsule le partitionnement des données (comme les fragments de mise en veille prolongée)
- L'implémenter nous-mêmes dans notre application
Notre application est construite sur J2EE et EJB 2.1 (j'espère que nous passerons un jour à EJB 3).
Que suggérerais-tu?
MODIFIER (2011-02-11) :
Juste une mise à jour :Actuellement, la taille de la base de données est de 380 Go, la taille des données de notre « grande » table est de 220 Go et la taille de son index est de 36 Go.Ainsi, même si la table entière ne tient plus en mémoire, l'index le fait.
Le système fonctionne toujours correctement (toujours sur le même matériel) et nous réfléchissons toujours au partitionnement des données.
MODIFIER (04/06/2014) :Encore une mise à jour :La taille de l'ensemble de la base de données est de 1,5 To, la taille de notre "grande" table est de 1,1 To.Nous avons mis à niveau notre serveur vers une machine à 4 processeurs (Intel Xeon E7450) avec 128 Go de RAM.Le système fonctionne toujours bien.Ce que nous prévoyons de faire ensuite, c'est de placer notre grande table sur un serveur de base de données distinct (nous avons déjà apporté les modifications nécessaires à notre logiciel) tout en effectuant simultanément une mise à niveau vers un nouveau matériel doté de 256 Go de RAM.
Cette configuration est censée durer deux ans.Ensuite, nous devrons soit enfin commencer à mettre en œuvre une solution de sharding, soit simplement acheter des serveurs avec 1 To de RAM, ce qui devrait nous permettre de tenir pendant un certain temps.
MODIFIER (2016-01-18) :
Depuis, nous avons placé notre grande table dans sa propre base de données sur un serveur séparé.Actuellement, la taille de cette base de données est d'environ 1,9 To, la taille de l'autre base de données (avec toutes les tables sauf la "grande") est de 1,1 To.
Configuration matérielle actuelle :
- HP ProLiant DL580
- 4 processeurs Intel(R) Xeon(R) E7-4830
- 256 Go de RAM
Les performances sont bonnes avec cette configuration.
La solution
Si vous pensez que vous allez être limité aux E/S/mémoire, je ne pense pas que le partitionnement sera utile.Comme d’habitude, une analyse comparative vous aidera d’abord à déterminer la meilleure direction.Si vous ne disposez pas de serveurs de rechange dotés de 64 Go de mémoire, vous pouvez toujours demander à votre fournisseur une « unité de démonstration ».
Je pencherais pour le partitionnement si vous ne vous attendez pas à un rapport global sur une seule requête.Je suppose que vous partageriez toute la base de données et pas seulement votre grande table :il est préférable de garder des entités entières ensemble.Eh bien, si votre modèle se divise bien, de toute façon.
Autres conseils
Vous commencerez certainement à rencontrer des problèmes sur cette table de 42 Go une fois qu'elle ne rentrera plus dans la mémoire.En effet, dès qu’il ne rentre plus en mémoire, les performances se dégradent extrêmement rapidement.Une façon de tester consiste à placer cette table sur une autre machine avec moins de RAM et à voir à quel point ses performances sont médiocres.
Tout d'abord, le fractionnement des tables n'a pas autant d'importance que si vous déplacez également certaines tables vers un volume physique distinct.
Ceci est une erreur.Le partitionnement (soit via la fonctionnalité de MySQL 5.1, soit via la même chose en utilisant les tables MERGE) peut offrir des avantages significatifs en termes de performances même si les tables se trouvent sur le même lecteur.
À titre d'exemple, disons que vous exécutez des requêtes SELECT sur votre grande table en utilisant une plage de dates.Si la table est entière, la requête sera obligée de parcourir la table entière (et à cette taille, même l'utilisation d'index peut être lente).L'avantage du partitionnement est que vos requêtes ne s'exécuteront que sur les partitions où cela est absolument nécessaire.Si chaque partition a une taille de 1 Go et que votre requête n'a besoin d'accéder qu'à 5 partitions pour se réaliser, la table combinée de 5 Go est beaucoup plus facile à gérer pour MySQL qu'une version monstre de 42 Go.
Une chose que vous devez vous demander est de savoir comment vous interrogez les données.S'il est possible que vos requêtes n'aient besoin d'accéder qu'à certaines parties de données (par ex.une plage de dates ou une plage d'ID), un partitionnement quelconque s'avérera bénéfique.
J'ai entendu dire qu'il y avait encore des bugs avec le partitionnement MySQL 5.1, notamment liés au choix de la bonne clé par MySQL.Les tables MERGE peuvent fournir les mêmes fonctionnalités, bien qu'elles nécessitent un peu plus de temps système.
J'espère que cela aide... bonne chance !
Ceci est un excellent exemple de ce que le partitionnement MySql peut faire dans un exemple réel de flux de données énormes :
En espérant que cela sera utile pour votre cas.
Il y a quelque temps, lors d'un événement Microsoft ArcReady, j'ai vu une présentation sur les modèles de mise à l'échelle qui pourraient vous être utiles.Tu peux voir les diapositives pour cela en ligne.
J'opterais pour MariaDB InnoDB + Partitions (soit par clé, soit par date, selon vos requêtes).
Je l'ai fait et maintenant je n'ai plus de problèmes de base de données.
MySQL peut être remplacé par MariaDB en quelques secondes... tous les fichiers de base de données restent les mêmes.
Tout d'abord, le fractionnement des tables n'a pas autant d'importance que si vous déplacez également certaines tables vers un volume physique distinct.
Deuxièmement, ce n'est pas nécessairement la table ayant la plus grande taille physique que vous souhaitez déplacer.Vous pouvez avoir une table beaucoup plus petite qui génère plus d'activité, tandis que votre grande table reste assez constante ou ajoute uniquement des données.
Quoi que vous fassiez, ne le mettez pas en œuvre vous-mêmes.Laissez le système de base de données s’en occuper.
A quoi sert la grande table.
Si vous souhaitez le diviser, vous avez plusieurs options :
- Divisez-le en utilisant le système de base de données (je n'en sais pas grand chose)
- Divisez-le par ligne.
- divisez-le par colonne.
Le diviser par ligne ne serait possible que si vos données pouvaient être facilement séparées en morceaux.par exemple.Quelque chose comme Camp de base possède plusieurs comptes complètement séparés.Vous pouvez conserver 50 % des comptes dans une table et 50 % dans une autre table sur une autre machine.
La division par colonne est adaptée aux situations où la taille de la ligne contient de grands champs de texte ou BLOBS.Si vous avez un tableau avec (par exemple) une image utilisateur et un énorme bloc de texte, vous pouvez regrouper l'image dans un tableau complètement différent.(sur une autre machine)
Vous rompez la normalisation ici, mais je ne pense pas que cela poserait trop de problèmes.
Comme d’habitude, une analyse comparative vous aidera d’abord à déterminer la meilleure direction.
C'est ce que la plupart des gens me disent, alors je pense que je vais enfin devoir prendre cette pilule...
Vous voudriez probablement éventuellement diviser cette grande table.Vous souhaiterez probablement le placer sur un disque dur séparé, avant de penser à un deuxième serveur.Le faire avec MySQL est l'option la plus pratique.S’il en est capable, alors foncez.
MAIS
En réalité, tout dépend de la manière dont votre base de données est utilisée.Statistiques.
