Stratégie pour traiter les grandes tables db

Question

Je cherche à construire une application Rails qui aura de jolies tables de plus de 500 millions de lignes. Pour garder les choses au top Je suis actuellement en train de regarder comment une grande table peut être divisée en plus de blocs de gérables. Je vois que depuis MySQL 5.1 il y a une option de partitionnement et c'est une option possible mais je n'aime pas la façon dont la colonne qui détermine le partitionnement doit faire partie de la clé primaire sur la table .

Ce que je voudrais vraiment faire est de diviser la table un modèle AR écrit sur la base des valeurs écrites mais pour autant que je sache, il n'y a aucun moyen de le faire - que quelqu'un a des suggestions comment je pourrais mettre en œuvre cette stratégie ou d'autres stratégies?

Merci

Arfon

Answer 1

colonnes de partition dans MySQL ne sont pas limités aux clés primaires. En fait, une colonne de partition ne doit pas forcément être une clé (bien que l'une d'elles soit créée de manière transparente). Vous pouvez partitionner par RANGE, HASH, KEY et LIST (qui est similaire à RANGE seulement que c'est un ensemble de valeurs discrètes). Lisez le manuel MySQL pour an overview des types de partioning.

Il existe des solutions alternatives telles que HScale - un plug-in middleware qui partitionne de façon transparente des tables en fonction de certains critères. HiveDB est un framework open-source pour le partitionnement horizontal pour MySQL.

En plus de partitionner et de partitionner, vous devez utiliser une sorte de clustering. La configuration la plus simple est une configuration basée sur la réplication qui vous aide à répartir la charge sur plusieurs serveurs physiques. Vous devriez également envisager des solutions de clustering plus avancées telles que le cluster MySQL (probablement pas une option en raison de la taille de votre base de données) et le middleware de clustering tel que Sequioa.

En fait, j'ai posé une question pertinente concernant scaling with MySQL ici sur stack-overflow il y a quelque temps, et j'ai fini par me répondre quelques jours plus tard après avoir rassemblé beaucoup d'informations sur le sujet. Cela pourrait aussi être pertinent pour vous.

Answer 2

Si vous souhaitez diviser vos données par temps, la solution suivante peut répondre à vos besoins. Vous pouvez probablement utiliser les tables MERGE;

Supposons que votre table est appelée MyTable et que vous avez besoin d'une table par semaine

1. Votre application se connecte toujours dans la même table
2. Un travail hebdomadaire renomme atomiquement votre table et reconstitue un vide: MyTable est renommé en MyTable-Year-WeekNumber, et une MyTable vide est créée.
3. Les tables de fusion sont supprimées et recréées.

Si vous souhaitez obtenir toutes les données des trois derniers mois, vous créez une table de fusion qui inclura uniquement les tables des 3 derniers mois. Créez autant de tables de fusion que vous avez besoin de périodes différentes.Si vous pouvez pas inclure la table dans laquelle les données sont actuellement insérées (MyTable dans notre exemple), vous serez encore plus heureux, car vous n'aurez pas d'accès en lecture/écriture

Answer 3

Vous pouvez gérer cela entièrement dans Enregistrement actif en utilisant DataFabric.

Il n'est pas si compliqué d'implémenter un comportement similaire si ce n'est pas approprié. Google sharding pour beaucoup de discussion sur le modèle architectural de la gestion du partitionnement de la table dans le niveau de l'application. Il a l'avantage d'éviter les middlewares ou en fonction des fonctionnalités spécifiques au vendeur. D'un autre côté, il y a plus de code dans votre application dont vous êtes responsable.