Partage de base de données et Rails

Question

Quelle est la meilleure façon de gérer une base de données partitionnée dans Rails ?Le partitionnement doit-il être géré au niveau de la couche application, de la couche d'enregistrement actif, de la couche pilote de base de données, d'une couche proxy ou de tout autre chose ?Quels sont les avantages et les inconvénients de chacun?

Answer 1

FiveRuns a un joyau nommé Tissu de données qui effectue le partitionnement au niveau de l'application et la réplication maître/esclave.Cela vaut peut-être la peine d'être vérifié.

Answer 2

Je suppose qu'avec les fragments, nous parlons de partitionnement horizontal et non de partitionnement vertical (voici les différences sur Wikipédia).

Tout d'abord, cloison verticale tendue aussi loin que vous le pouvez avant d'envisager un cloisonnement horizontal.Il est facile dans Rails de faire pointer différents modèles vers différentes machines et pour la plupart des sites Rails, cela vous mènera assez loin.

Pour le cloisonnement horizontal, dans un monde idéal, cela serait géré au niveau couche d'application dans Rails.Mais même si ce n'est pas difficile, ce n'est pas anodin dans Rails, et au moment où vous en avez besoin, votre application a généralement grandi au-delà du point où cela est réalisable puisque vous avez des appels ActiveRecord disséminés partout.Et personne, développeurs ou direction, n'aime travailler dessus avant que vous en ayez besoin, car tout le monde préfère travailler sur les fonctionnalités que les utilisateurs utiliseront maintenant plutôt que sur un partitionnement qui n'entrera peut-être pas en jeu avant des années après l'explosion de votre trafic.

Couche ActiveRecord...pas facile d'après ce que je peux voir.Cela nécessiterait beaucoup de correctifs singe dans les composants internes de Rails.

À Spock nous avons fini par gérer cela en utilisant un proxy MySQL personnalisé et l'a ouvert sur SourceForge en tant que Mandataire Spock.ActiveRecord pense qu'il parle à une machine de base de données MySQL alors qu'en réalité, il parle au proxy, qui parle ensuite à une ou plusieurs bases de données MySQL, fusionne/trie les résultats et les renvoie à ActiveRecord.Ne nécessite que quelques modifications de votre code Rails.Jetez un œil à la page Spock Proxy SourceForge pour plus de détails et pour les raisons pour lesquelles nous avons choisi cette voie.

Answer 3

Pour ceux d'entre vous qui, comme moi, n'ont jamais entendu parler du sharding :

http://highscalability.com/unorthodox-approach-database-design-coming-shard

Answer 4

Connecter Rails à plusieurs bases de données n'est pas un gros problème : vous disposez simplement d'une sous-classe ActiveRecord pour chaque fragment qui remplace la propriété de connexion.Cela rend les choses assez simples si vous devez effectuer des appels entre fragments.Il vous suffit alors d'écrire un peu de code lorsque vous devez effectuer des appels entre les fragments.

Je n'aime pas l'idée de Hank de diviser les instances de rails, car il semble difficile d'appeler le code entre les instances à moins que vous n'ayez une grande bibliothèque partagée.

Vous devriez également envisager de faire quelque chose comme Masochisme avant de commencer le partitionnement.

Answer 5

Pour que les rails fonctionnent avec un environnement répliqué, je suggère d'utiliser le plugin my_replication qui permet de basculer la connexion à la base de données vers l'un des esclaves au moment de l'exécution.

https://github.com/minhnghivn/my_replication

Answer 6

À mon avis, le moyen le plus simple est de maintenir un rapport 1:1 entre les instances Rails et les fragments DB.