Infrastructure pour une base de données à écriture très concurrente et élevée

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:

1. MySQL Sharding peut-il gérer les connexions simultanées?
2. 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.

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

• Dans la configuration de la réplication MySQL, ce sera le maître
• Joue un rôle spécial en tant que DM
• Maître des serveurs B, C, D, E
• Toutes les tables utilisent le moteur de stockage BLACKHOLE (/ dev / null)
• Stocke uniquement les journaux binaires
• Machine à métaux nus
• Avantages
  • Écrits très rapides puisque toutes les tables du DM utilisent BLACKHOLE
  • La latence du réseau est moins problématique car les lectures représentent 15 à 30% de l'activité de la base de données
  • Tous les esclaves sont mis à jour strictement à partir du DM

Serveurs B, C, D, E

• Esclave de A
• Servir une base pour les SELECT lourds
• Le serveur peut être virtuel ou nu
• Pour tous les serveurs dont les tables d'utilisateurs utilisent le moteur de stockage InnoDB
  • Il peut servir de serveur DB de secours à chaud
  • Des sauvegardes non intrusives peuvent y être exécutées
• Pour tous les serveurs dont les tables d'utilisateurs utilisent le moteur de stockage MyISAM
  • Configurer avec une lecture seule
  • Les tableaux peuvent avoir leur format de ligne refait pour accélérer les lectures

J'ai déjà écrit des articles à ce sujet

• /server/264374/mysql-in-star-topology/264444#264444
• /programming/5273043/mysql-in-star-topology/5781504#5781504

Pour garder la réplication MySQL en parfait état

• Utilisez MySQL 5.5
• Utiliser la réplication semi-synchrone
• Réglez InnoDB pour engager plus de processeurs

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.

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.

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.

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.