Architecture de base de données Master + Slave vs. Master + Memcache

Question

Supposons que nous ayons un serveur avec une base de données et N serveurs qui peuvent être utilisés pour la mise en mémoire cache des données avec Memcache. Chaque enregistrement dans la base de données peut avoir plusieurs (mais sensiblement moins de N) représentations dans un cache. Par exemple, l'entité avec l'identifiant 108 peut être mise en cache par les clés entity_108_1, entity_108_2, ..., entity_108_10. Lorsqu'un enregistrement dans une base de données est modifié, les enregistrements correspondants dans le cache sont remplacés par de nouvelles données.

Pourquoi cette architecture n'est-elle pas meilleure que la configuration de la base de données maître/esclave? Il semble qu'il a les mêmes avantages tout en ne souffrant pas de retards de réplication.

Answer 1

Je pense qu'il est préférable d'aller avec memcache. Non seulement les retards lors de la réplication posent des problèmes, mais vos serveurs N n'ont pas besoin d'un espace disque important (si nous supposons que vous avez une énorme base de données). D'un autre côté, vous n'obtiendrez pas de redondance. Si votre serveur de base de données maître meurt, vous n'aurez personne à prendre sa place. Donc, les serveurs esclaves sont nécessaires à ces fins, mais vous n'avez probablement pas besoin de N, et si vous pouvez atteindre l'évolutivité en utilisant memcache, il n'y a aucune raison de ne pas le faire (je veux dire, si vous avez développé des applications savoir comment l'utiliser). D'après mon expérience, il est toujours plus facile de maintenir une instance memcached qu'un serveur MySQL esclave (et c'est probablement la même chose avec d'autres moteurs de base de données).

Bien sûr, tout cela est logique si vous avez développé des applications qui savent comment utiliser memcache. Il est toujours plus simple d'ajouter une chaîne de connexion supplémentaire dans votre configuration et de l'utiliser à des fins de lecture seule à partir de certains serveurs de base de données de la même manière que vous l'utilisez avec master. L'utilisation de données provenant d'une autre source de données (telle que memcache) suppose que vous modifiez votre application de cette manière.

Answer 2

en supposant que vous aurez toujours un maître/esclave de réglage pour db, même si vous avez N noeuds pour la solution memcache

est livré avec les inconvénients et avantages

ce n'est pas mieux que maître/esclave si nous parlons dans un scénario lourd d'écriture. Le processus d'écriture doit expirer tous les objets mis en cache sur tous les nœuds memcache et doit attendre les réponses "réussies" puisque vous voulez éviter l'accès à toute copie des anciennes données. Dans ce cas, en fonction du nombre de copies d'objets mises en cache et de la vitesse du réseau, vous risquez de subir de mauvaises performances. cela dit, puisque vous ne savez pas quel noeud a une copie, vous allez devoir envoyer la demande d'expiration à tous les nœuds ...... :(