Tout en utilisant AMPQ ou XMPP (rabbbitmq ou ejabbered qui pourrait avoir Couchdb comme backends) semble être un bon ajustement de fournir des mises à jour en temps réel sur l'état d'ami dans une plate-forme de jeu social où les mises à jour sont petites mais fréquentes, je ne peux pas m'empêcher de Pensez pourquoi Cochdb ne serait-il pas une bonne plate-forme pour délivrer de telles mises à jour?
L'avantage principal que j'aurais pu penser est sa capacité à filtrer les mises à jour basées sur des amis et la disponibilité des changements API, ce qui permet de développer une telle demande et de la gérer (y compris la réplication) assez facile par rapport à AMPQ ou XMPP où vous devez penser sur la façon de gérer les nœuds pubsub et qui leur sont souscrits à tout moment.
Cependant, je ne peux pas m'empêcher de penser que c'est trop beau pour être vrai, je ne trouve pas d'informations sur les lacunes de Couchdb. D'une manière ou d'une autre, on a l'impression d'utiliser MySQL pour passer un message qui est pourquoi je suis hésitant à l'utiliser.
Quelqu'un a-t-il une expérience d'utilisation de CouchDB pour de telles applications? Recommanderiez-vous une autre plate-forme à utiliser?
3 Réponses :
Voici quelques problèmes avec les mises à jour "petites mais fréquentes" et cochdb.
Couchdb possède un excellent système MVCC pour les mises à jour des documents. Chaque mise à jour change la révision et vous ne pouvez pas mettre à jour un document sans passer la révision que vous souhaitez mettre à jour. Cela signifie également que si vous avez de multiples clients à mettre à jour le même document incroyablement fréquemment, cette fonctionnalité sera de la manière que même avec les modifications alimentaires, il existe un petit délai réseau après des mises à jour.
Un autre problème que vous ayez peut-être utiliser les modifications filtrées est que la fonction de filtrage obtient l'objet de la demande, ce qui signifie qu'il s'agit d'un appel distinct sur le serveur d'affichage pour chaque document multiplié par le nombre de connexions. Vous pouvez plutôt vouloir utiliser un serveur nœud.js ou Erlang pour mettre en œuvre une approche "Canaux" pour modifier le filtrage et qu'il est assis sur un seul flux de modifications non filtrées.
Résumer, ce que vous voulez faire fonctionnera bien si vous n'avez pas de clients multiples essayant de mettre à jour les mêmes documents à haute fréquence et si vous n'utilisez pas de filtrage de modifications sur un très grand nombre de clients simultanés avec une fréquence de mise à jour de la base de données élevée. Autre que ça, ça va travailler très bien. @jchris a fait une tonne d'application en temps réel utilisant simplement les changements négatifs et ils fonctionnent bien.
Donc, si je devais regrouper les mises à jour à l'aide de nœud.js et de mettre à jour CouchDB périodiquement (toutes les quelques minutes) avec des mises à jour en vrac utilisant uniquement cette instance unique de nœud.js, la mise à jour ne serait pas mon plus gros problème. Mon inquiétude serait alors la filtration des mises à jour en utilisant des vues pour les nombreux clients qui se connectent à Couchdb. Cela pourrait être atténué en quelque sorte si je crée une base de données par utilisateur au détriment de l'espace disque et publier simplement ses mises à jour de cette base de données, de sorte que chaque client obtienne des mises à jour non filtrées, où le filtrage est effectué en réalité, le filtrage est effectué par des messages de routage à DBS.
Oui, c'est une façon. Vous pourriez également simplement avoir un processus de nœud écouter toutes les modifications et fournir le filtrage sur les modifications qui supprimeraient toute cette latence d'IO supplémentaire sur l'appel du serveur d'affichage par écrasement. Il existe également des façons de "fausses" mises à jour atomiques avec Couchdb qui peuvent atténuer les problèmes de révision MikeArogers.com/archives/ 737
Je pense qu'il y a une certaine confusion ici sur le terme «mise à jour». Cela me semble que le questionneur parle davantage de la création de nombreux messages, pas nécessairement à la mise à jour de chacun. Donc, l'objection sur "chaque mise à jour change la révision" pourrait ne pas s'appliquer ici. Vraisemblablement, chaque message créerait un nouveau "document" et toute "vues" ultérieure rendrait ces informations au besoin.
Je ne sais pas ce que tu veux dire. Chaque nouveau document ou modification d'un document apparaîtra dans _changes et vous pouvez appliquer un filtre JavaScript pour ne pas obtenir de messages sur les modifications que vous ne vous souciez pas. "Vues" sont quelque chose d'autre, des index secondaires générés à la date de lecture et ne disposent pas d'une alimentation _changnes.
Je peux penser à une raison très simple ... car les bases de données n'ont pas été conçues pour le faire!
Une file d'attente de message est exactement ce que ce type de flux de travail a besoin. Avez-vous examiné certains des produits ou services basés sur l'AMQP? Ceux-ci comprennent la Rabbitmq (installée localement) et StormMQ (service basé sur le cloud). Plus ici: http://www.amqp.org
Cependant, je ne peux pas m'empêcher de penser que c'est trop beau pour être vrai, je ne peux pas Trouvez des informations sur les lacunes de Couchdb. En quelque sorte, ça fait comme utiliser MySQL pour passer un message qui est pourquoi je suis hésitant à en utilisant.
Essayez de regarder pourquoi Bases de données Suck pour la messagerie Présentation . Bien que cela soit principalement destiné à des bases de données telles que MySQL, elle peut vous donner un picturage plus important sur ce sujet.
Je ne suis pas certain que cela s'applique. Il ne parle pas de l'interrogation de la base de données. CouchDB a une API spécifique pour les notifications continues en temps réel.