Gem qui permet l'accès aux données en utilisant des bases de données mysql partagées tout en maintenant l'utilisation de Activerecord

Question

Ceci est un problème relativement complexe auquel je pense, alors s'il vous plaît suggérer des modifications ou des commentaires sur les parties où vous n'êtes pas clair. Je vais mettre à jour et itérer en fonction de vos commentaires

Je pense à un développement d'une gemme rails qui simplifie l'utilisation des tables partagées, même lorsque la plupart de vos données sont stockées dans des bases de données relationnelles. Je crois que cela est similaire au concept utilisé dans Quora ou Friendfeed quand ils touchent un mur avec mysql traditionnel, avec la plupart des solutions potentielles nécessitant une migration massive (nosql), ou tout simplement être vraiment douloureux (coller complètement relationnel)

• http://bret.appspot.com/entry/how-friendfeed-uses-mysql
• http://www.quora.com/When-Adam-DAngelo-says-partition-your-data-at-the-application-level-what-exactly-does-he-mean?q=application+layer+quora+adam+

Essentiellement, comment pouvons-nous continuer à utiliser MySQL pour beaucoup de choses, il est vraiment bon, tout en permettant des parties du système à l'échelle? Cela permettra à quelqu'un de commencer à utiliser mysql/activerecord, mais d'atteindre une mise à l'échelle du roadblock pour facilement mettre à l'échelle les parties de la base de données qui ont du sens. Pour nous, nous utilisons Ruby on Rails sur une base de données partitionnée, et stockons des blobs JSON dans ceux-ci. Puisque nous ne pouvons pas faire de jointures, nous créons des tables pour les relations entre entités.

Par exemple, nous avons 10 types d'entités différents. Chaque entité peut être liée les unes aux autres à l'aide de grandes tables de relations (partagées).

Les tableaux sont extrêmement simples. Les index sont (Id1, Id2 ..., type) et les données sont stockées dans le blob JSON.

• Id, type, {données JSON}
• Id1, ID2 type {données JSON}
• Id1, ID2 Id3, type {données JSON}

Nous avons mis beaucoup de travail dans la création d'interfaces de plus haut niveau pour stocker une série d'ensembles de données relationnelles

Pour un type donné, vous pouvez définir un type de stockage - (valeur, liste non pondérée, listes pondérées, listes pondérées avec guids)

Nous avons des interfaces de haut niveau pour chacun d'entre eux - l'interrogation, le tri, la comparaison d'horodatage, les intersections, etc.

De cette façon, si quelqu'un se rend compte qu'ils ont besoin à l'échelle d'une partie spécifique de la base de données, ils peuvent garder la plupart de leur infrastructure, et déplacer seulement les tables dont ils ont besoin dans cette base de données partagée

Que pensez-vous? Comme mentionné ci-dessus, j'aimerais savoir ce que vous pensez

Answer 1

L'évolutivité est un écrou difficile à casser. Mon parcours comprend deux années en tant qu'ingénieur commercial pour les systèmes BEA, à l'époque où tout ce qu'ils vendaient était le middleware TUXEDO (TUXEDO == Transactions pour UNIX Extended for Distributed Operations). TUXEDO est toujours le roi du benchmark TPC-C sur les plateformes Unix.

Mise à l'échelle WRT Une base de données ne concerne pas tant la base de données elle-même, mais la manière dont vous accédez à cette base de données.Par exemple, si vous établissez une connexion à une base de données et que vous voulez que cette connexion unique soit mise à l'échelle, faites en sorte que cette connexion accède toujours à la même table dans la base de données. Le problème avec les infrastructures d'aujourd'hui (RoR inclus) est que lorsqu'ils ouvrent des connexions génériques, ces connexions accèdent à de nombreuses tables dans la base de données. Par conséquent, si vous souhaitez créer une échelle de CONNEXION de base de données, faites en sorte que cette connexion se concentre sur le moteur de base de données avec le moins de ressources de base de données possible. Si vous parvenez à créer une connexion «ciblée», cela accède UNIQUEMENT à une table et à un index de table, par exemple, elle sera beaucoup plus performante qu'une connexion accédant à CHAQUE table dans la base de données et à tous les index définis pour toutes ces tables.