Est-ce qu'il n'y a pas d'évolutivité horizontale quand il s'agit d'écrire un défaut SGBDR? ou cela arrive-t-il à tous les SGBD?

Question

Lorsque vous atteignez un toit lors de la lecture d'une base de données, vous avez le choix entre deux options: redimensionner verticalement en ajoutant du matériel au serveur ou mettre à l'échelle horizontalement un second serveur pour décharger les lectures. Le déchargement lit sur un deuxième serveur, ce qui signifie que toutes les écritures vont toucher les deux serveurs, tandis que la lecture n'en touche qu'une seule.

Le problème est lorsque vous frappez un toit avec l'écriture, puisque l'écriture doit arriver à tous les serveurs, cela signifie que tous les serveurs seront surchargés avec des demandes d'écriture, et le serveur est inutilisable. Ajouter plus de serveurs au problème n'aide pas, puisqu'il ajoute seulement plus de serveurs qui seront surchargés. Vous devez donc évoluer verticalement.

Est-ce quelque chose de spécifique au SGBDR? ou est-ce quelque chose qui arrive avec tous les SGBD?

Je sais que vous pouvez faire des choses du côté du logiciel, et diviser la base de données en deux, par exemple. toutes les entrées commençant par 0-m dans un db tandis que n-z dans un autre, mais à mon humble avis c'est plus une solution de contournement qu'une solution au problème.

Answer 1

Je ne vois pas que ce serait spécifique au modèle relationnel. Toutes les bases de données qui doivent lire et écrire (et c'est la plupart d'entre elles) auront un problème similaire.

Pour ce que ça vaut, la plupart des bases de données sont lues beaucoup plus que écrites donc le toit d'écriture se produit moins souvent que vous ne le pensez. En outre, les bases de données d'équilibrage de charge selon votre méthode tend à être une écriture immédiate au primaire avec des écritures en file d'attente à tous les secondaires (au moins dans mon expérience).

Dans ce cas, vous n'attendez pas plusieurs écritures en tant qu'utilisateur, attendez simplement la première. Le SGBD gère lui-même la synchronisation entre les instances. Cela signifie bien sûr que les bases de données secondaires peuvent ne pas être totalement à jour, mais cela peut être contrôlé. Techniquement, cela brise les propriétés ACID du système dans son ensemble, mais cela peut être architecturé autour.

Answer 2

Je pense que c'est le cas de tous les SGBD, bien que certains le gèrent mieux que d'autres. Comme vous le mentionnez, le partitionnement de la base de données dans un logiciel semble être la solution la plus courante.

Cependant, dans de nombreuses applications, le partitionnement de la base de données a tout de même un sens si vous êtes à une telle échelle que cela devient nécessaire. Par exemple, si vous aviez une application de réseau social, il serait probablement logique de partitionner votre base de données par pays ou d'autres régions géographiques. Cela vous permettrait d'avoir vos serveurs géographiquement proches des régions qu'ils desservent. Cela aiderait également à atténuer les problèmes avec un «graphe social» inter-base de données puisque les amis du peuple ont tendance à vivre à proximité.

Answer 3

Tu peine va « frapper un toit avec l'écriture, puisque l'écriture doit arriver à tous les serveurs », car dans la plupart des installations de SGBDR:

1) Les lectures sont accablantes plus fréquentes que l'écriture

2) Les RDBM modernes ont un contrôle de simultanéité multi-version capable de réduire le blocage lors de la lecture/écriture