Mes exigences sont:
- 3000 connexions
- 70-85% écriture vs lecture
Actuellement, nous maximisons une instance extra-large à processeur élevé à 700 connexions. Les 8 cœurs sont au maximum. Nous pensons que c'est le nombre de connexions simultanées car la mémoire est bonne. L'écriture elle-même est très simple (les validations ralentissent les choses). Pour passer à 3000, nous devons aller sur plusieurs serveurs, options actuelles:
- Partage MySQL
- Cluster MongoDB
- Cassandra
- Hadoop et MySQL (caches Hadoop, vidage unique vers MySQL)
- MongoDB & MySQL (au lieu de Hadoop, nous utilisons mongo pour le cache)
Pour gérer ce nombre de connexions, un certain nombre de questions:
- MySQL Sharding peut-il gérer les connexions simultanées?
- Tout maître unique peut-il gérer ces connexions simultanées, ou un multi-tête comme Mongo est-il une meilleure option?
Je m'excuse si je ne décris pas bien mon problème. Veuillez poser des questions.
mysql
replication
mongodb
cassandra
Justin
la source
la source
Réponses:
Si vous utilisez MySQL comme base de données principale, vous pouvez envisager d'utiliser une topologie en étoile via la réplication MySQL.
Maintenant, avant de dire UGHHH, ROFL et OMG à la réplication MySQL, écoutez-moi.
Une topologie en étoile vous permet d'écrire sur un serveur DB (appelé Distribution Mster [DM]) et d'envoyer les commandes SQL à plusieurs serveurs DB. Comment configurez-vous une telle infrastructure DB?
Voici la description
Vous disposez de 5 serveurs DB (serveur A, B, C, D, E)
Serveur A
Serveurs B, C, D, E
J'ai déjà écrit des articles à ce sujet
Pour garder la réplication MySQL en parfait état
la source
Le cluster MySQL pourrait être une autre approche du partage. Consultez le post ici .
Je suis également un grand fan de Cassandra, mais cela dépend beaucoup de votre modèle de données et des requêtes que vous souhaitez effectuer. Cassandra est extrêmement rapide à écrire, car elles sont toujours séquentielles sur le disque.
la source
Si vous allez opter pour plusieurs têtes (ce dont vous avez probablement besoin si vous avez vraiment besoin de connexions actives 3K), je regarderais probablement Riak ou peut-être Cassandra. Cela dépend vraiment de ce que fait votre application quant à leur adéquation, mais d'après ce que vous avez décrit, je pense que cela s'intégrerait à quelque chose comme Riak.
Cela dit, une approche fragmentée semble assez faisable, si vous pouvez trouver un bon moyen de segmenter les données et minimiser tout besoin de trucs croisés. Je resterais à l'écart de tout ce qui est ring / star / mmm dans mysql, et je m'en tenirais juste au sharding droit. En fait, si vous vouliez utiliser Postgres, vous pourriez prototyper assez facilement en utilisant des schémas sur quelque chose comme Heroku, puis dériver et séparer les bases de données au fur et à mesure qu'elles commencent à dépasser les nœuds individuels.
Oh, et même si je pense que vous pouvez essayer de mettre à l'échelle quelque chose comme ça verticalement (un seul nœud gérant tous les connecteurs 3K), je ne pense pas que vous puissiez le faire dans le cloud.
la source
Si c'est une option pour votre application spécifique, vous pouvez peut-être utiliser une méthode asynchrone pour écrire des données dans votre base de données (file d'attente de travail, insertions par lots ...) et / ou déplacer les nombreuses connexions client de votre base de données avec un proxy en face .
Avec le partage, vous pouvez généralement évoluer correctement (2x serveurs db == 2x connexions), mais cela dépend fortement de la nature de votre ensemble de données et de la façon dont vous pouvez le diviser en plusieurs fragments.
la source
Personnellement, je préfère MongoDB pour sa facilité d'administration, son évolutivité et sa facilité d'utilisation générale. De plus, à moins d'avoir réellement besoin d'un SGBDR, je vais utiliser un no-SQL.
Cela dit, choisissez la base de données qui convient le mieux à votre application. Si vous avez besoin de transactions ou si vous ne pouvez pas concevoir votre application sans jointures (ou si cela a plus de sens avec elles), utilisez un SGBDR (MySQL, PostGres, etc.)
Bien que je préfère personnellement MongoDB, l'idée que MySQL n'évolue pas ou ne peut pas gérer un taux élevé de transactions est purement fausse. L'équipe d'ingénierie Facebook (et l'équipe MySQL en son sein) va dans les moindres détails avec elle. Consultez également le blog de l'équipe Etsy Ops; ils aiment aussi MySQL.
Enfin, je n'utiliserais pas MongoDB pour un cache MySQL; utilisez Memcached pour cela.
Redis est également un magasin de valeurs-clés dans la RAM qui est bon pour gérer certains cas d'utilisation. Il y a quelques entrées de blog sur blog.agoragames.com qui décrivent certains cas d'utilisation.
Vous devriez également consulter CouchDB si vous pensez à No-SQL. Sachez simplement qu'il nécessite une maintenance régulière pour réduire l'utilisation du disque. (Il échange la vitesse et la commodité pour l'utilisation du disque ...)
Enfin, la planification des capacités n'est pas facile à prévoir. Vous devez tester dans des conditions aussi réalistes que possible et être prêt à corriger en fonction de ce que vous voyez. Malheureusement, "l'informatique" est autant un art qu'une science.
la source