Ressources pour le fragmentage et le partitionnement de bases de données

Question

Je travaille avec un schéma de base de données qui pose des problèmes d’évolutivité. L'une des tables du schéma a atteint environ 10 millions de lignes et j'examine les options de partage et de partitionnement pour permettre à ce schéma de s'adapter à des ensembles de données beaucoup plus volumineux (par exemple, entre 1 et 100 milliards de lignes). Notre application doit également pouvoir être déployée sur plusieurs produits de base de données, notamment Oracle, MS SQL Server et MySQL.

C’est un gros problème en général et j'aimerais savoir quelles sont les options disponibles. Quelles sont les ressources disponibles (livres, livres blancs, sites Web) pour les stratégies de partage de bases de données et de partitionnement?

Answer 1

Je suis d’accord avec les autres réponses pour dire que vous devriez examiner votre schéma et vos index avant de recourir au sharding. 10 millions de lignes sont bien dans les capacités de l’un des principaux moteurs de base de données.

Toutefois, si vous souhaitez des ressources pour en apprendre davantage sur le sujet du sharding, essayez les suivantes:

• Meilleures pratiques d'évolutivité: enseignements tirés d'eBay
• Randy Shoup sur les principes architecturaux d'eBay - Vidéo et présentation
• Site à haute évolutivité
• M. Moore parvient à cogner sur le sharding (quand ne pas le faire)

Answer 2

Je souscris à l'observation de Mike Woodhouse selon laquelle la taille actuelle ne devrait pas être un problème - et l'auteur de la question est d'accord.

La plupart des SGBD commerciaux prennent en charge les tables fragmentées sous une forme ou sous une autre, sous un nom ou sous plusieurs autres. L'une des questions clés est de savoir s'il existe un moyen raisonnable de fractionner les données en fragments. Une méthode courante consiste à le faire en fonction d'une date. Par conséquent, toutes les valeurs de novembre 2008, par exemple, vont d'un fragment à l'autre, celles d'octobre 2008 à un autre, etc. Cela présente des avantages lorsque vient le temps de supprimer les anciennes données. Vous pouvez probablement supprimer le fragment contenant les données d'octobre 2001 (rétention de données sur sept ans) sans affecter les autres fragments. Ce type de fragmentation peut également contribuer à «l'élimination des fragments»; si la requête ne peut clairement pas avoir besoin de lire les données d'un fragment donné, elles seront alors laissées non lues, ce qui peut vous donner un avantage considérable en termes de performances. (Par exemple, si l'optimiseur sait que la requête concerne une date d'octobre 2008, il ignorera tous les fragments, à l'exception de celui contenant les données d'octobre 2008.)

Il existe d'autres techniques de fragmentation - round robin répartit la charge sur plusieurs disques, mais signifie que vous ne pouvez pas tirer parti de l'élimination des fragments.

Answer 3

10 millions de lignes, ce n’est vraiment pas grand en termes de SGBD et je commencerais par examiner mes plans d’indexation et de requête avant de commencer à planifier une distribution physique de données avec des fragments ou des partitions, ce qui ne devrait pas vraiment être nécessaire avant que votre table grandi de quelques ordres de grandeur.

Tous à mon humble avis, bien sûr.

Answer 4

D'après mon expérience, les grandes tables vous frappent toujours du côté des E / S. La solution la moins chère consiste à ajouter suffisamment d'index multicolonnes pour que toutes vos requêtes puissent obtenir les données directement à partir d'index, sans avoir à charger les pages de données principales. Cela rend vos insertions et mises à jour plus intensives en E / S, mais cela peut être correct. La prochaine option facile est de maximiser la RAM sur votre serveur. Aucune raison d'avoir moins de 32 Go si votre base de données est volumineuse. Mais à la fin, vous vous trouverez toujours lié aux E / S, et vous envisagerez d'acheter de nombreux disques durs et de maintenir un schéma de partitionnement complexe, ce qui représente une fortune entre le matériel et la main-d'œuvre. J'espère qu'il existe une meilleure alternative de nos jours - déplacer la base de données de disques durs en rotation vers des disques SSD - cela devrait rendre vos lectures et écritures aléatoires cent fois plus rapides que les disques SAS haut de gamme et supprimer les E / S goulot. Les disques SSD commencent à 10 dollars par gigaoctet, vous allez donc dépenser quelques dollars, mais cela reste beaucoup moins cher que les réseaux de stockage, etc.