Partition MySQL avec ActiveRecord

Question

Je veux profiter du nouveau partitionnement de MySQL 5.1 mais en utilisant un modèle ActiveRecord standard. Le problème que j'ai rencontré est que pour utiliser le partitionnement, la clé primaire sur la table doit inclure les colonnes utilisées dans la fonction de partitionnement. (http://dev.mysql.com/doc/refman/5.1/en/partitioning-limitations-partitioning-keys-unique-keys.html)

Maintenant, je veux avoir un champ 'id' auto-incrémentant (qui est habituellement utilisé comme clé primaire dans Rails) mais je veux partitionner en utilisant une autre colonne, dans ce cas 'task_id'. Fondamentalement, je ne veux pas utiliser les clés primaires composites dans mon application Rails. Ma question est la suivante:

Si je mets la table comme suit:

"CREATE TABLE `annotations` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `task_id` int(11) DEFAULT NULL, 
    `user_id` int(11) DEFAULT NULL, 
    `value` text, 
    `created_at` datetime DEFAULT NULL, 
    `updated_at` datetime DEFAULT NULL, 
    PRIMARY KEY (`id`, `task_id`), 
    KEY `index_annotations_on_task_id` (`task_id`), 
    KEY `index_annotations_on_user_id` (`user_id`) 
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 
PARTITION BY RANGE(task_id)(
PARTITION 1_to_5 VALUES LESS THAN (6), 
PARTITION 6_to_10 VALUES LESS THAN (11), 
PARTITION 11_to_15 VALUES LESS THAN (16))" 

où j'ai la clé primaire composée de colonnes « id » et « task_id », et je ne fais rien spécial avec le modèle ActiveRecord, est-ce que je me prépare à des maux de tête dans le futur? Fondamentalement, je crée une table avec une clé primaire basée sur deux colonnes mais ne pas dire à ActiveRecord sur la deuxième colonne car j'ai toujours un champ d'identification auto-incrémentant - quelqu'un peut-il voir des problèmes avec cette approche?

Answer 1

Je crois que ce que vous décrivez, créez le modèle ActiveRecord puis modifiez-le directement dans MySQL fonctionnera. L'inconvénient possible est que Rails ne connaîtra pas 'task_id' et bien sûr ne l'inclura pas dans les requêtes. Le problème étant que le principal avantage du partitionnement est que l'optimiseur de requêtes verrait que la requête incluait "task_id = 7" et que la requête ne devait être exécutée que dans la seconde partition.

Vous devriez toujours voir certains avantages car les jointures (en particulier à partir de la table des tâches) incluraient cette clé et l'optimiseur de requêtes pourrait faire ce qu'il fallait. Rails/Active Record a également l'habitude de mettre à jour chaque colonne, qu'elle ait été modifiée ou non. MySQL notait généralement que vous étiez en train de mettre à jour une colonne avec la valeur qu'elle avait déjà, mais regardez ceci car si MySQL pense qu'il doit déplacer un enregistrement d'une partition vers une autre, vos mises à jour prendraient un coup.

Answer 2

Bien que ce ne soit pas exactement ce que vous cherchez, vous avez déjà vu DataFabric? Il s'agit d'un moyen au niveau de l'application de partitionner vos données sur plusieurs bases de données. Cela vous permet également d'utiliser la réplication maître-> esclave. Comme je l'ai dit, pas exactement le même que le partitionnement au niveau de la base de données, mais il semble que ce serait plus facile à mettre en œuvre.

Answer 3

OK, merci pour vos commentaires. Oui, j'ai regardé DataFabric et cela semble avoir quelques fonctionnalités très utiles pour partager et répliquer des bases de données. Quoi qu'il en soit, merci pour la contribution, je vais devoir lire un peu plus avant de prendre une décision.