Système de base de données évolutive, Critique demandée

Question

Je souhaite créer une solution de base de données évolutive pour le back-end de mon site Web. Je lisais récemment sur la conception de bases de données et il semble que j'ai développé une idée qui pourrait fonctionner. Je pense que c’est une nouvelle façon de gérer n bases de données avec des données synchronisées, mais je peux me tromper. Je demande donc à SO d'évaluer cette idée et de me dire si c'est fou ou pas. (ou s'il existe déjà et est implémenté)

Dans ce schéma, il existe un groupe de nœuds de serveur. Un nœud exécute un équilibreur de charge de requête (Appelons-le A ) et les autres exécutent un dbms typique. Appelons ces nœuds N collectivement.

Chaque N est déconnecté des autres. En d'autres termes, un nœud dans N n'a pas besoin de communiquer avec les autres. Chaque N a une connexion avec A uniquement.

Le processus fonctionne comme ceci

• Toutes les requêtes de base de données sont transmises via A . (Supposons pour l'instant A un débit et une capacité de traitement infinis)
• A inspecte chaque requête ( Q ) et détermine s'il s'agit d'une opération qui lira dans une base de données ou d'une requête qui écrira dans une base de données. (dans sql, read serait sélectionné et write serait mis à jour)
• Si Q est une opération en lecture , transmettez-la à un des nœuds de N
• si Q est une opération écriture , transmettez-la à tous des noeuds de N

En supposant que son implémentation est correcte, tous les nœuds de N ont alors le contenu synchronisé de la base de données. Les requêtes qui ne lisent que des données doivent être envoyées à un noeud.

Cette idée semble fonctionner particulièrement bien pour moi car dans mon système, il y a très peu d'écritures, moins de 1%.

Donc quelques questions sur cette idée

• Un tel schéma a-t-il un sens d'un point de vue théorique?
• Si cela vous semble logique, existe-t-il une solution déjà mise en œuvre, soit commerciale, soit gratuite?

Answer 1

La configuration typique de nombreuses lectures est de disposer d’une base de données maître en lecture / écriture et de n bases reproduites d’esclaves qui sont en lecture seule. La réplication est gérée par le RBDMS. Les requêtes en lecture seule peuvent être équilibrées entre tous vos n nœuds en lecture seule et si votre maître en lecture / écriture tombe en panne temporairement, au moins votre application sera en mesure de gérer les opérations de lecture. Vous n'avez pas besoin d'un "A" central proxy pour décider si une requête est une lecture ou une écriture. Le client à l'origine de la requête doit être suffisamment intelligent pour savoir s'il lit ou écrit. Ainsi, vous ne serez pas engorgé sur votre " A " serveur.

La configuration que vous proposez présente le défaut suivant: si vous écrivez simultanément sur n nœuds, qu’en est-il si une ou plusieurs de ces écritations échouent?

Answer 2

Votre schéma ne fonctionne qu'avec des nœuds infiniment disponibles. Comment allez-vous gérer le temps d'arrêt des nœuds? Si un nœud est en panne pour n'importe quelle raison et a manqué une mise à jour, il servira la prochaine fois que des données altérées seront demandées.

Answer 3

Ce n’est pas une réponse directe à votre question, mais SQL Server 2008 prend déjà en charge quelque chose d’équivalent à ce que vous décrivez. Elle est appelée Réplication transactionnelle d'égal à égal . Je suis sûr que les autres SGBDR le font aussi. Je pense que MySQL appelle cela la réplication maître-maître.