l'architecture MongoDB pour l'application de lecture évolutive lourde (écrit constants)

Question

Mon application exécute un travail quotidien qui recueille des données et nourrit à un MongoDB. Ces données sont traitées et ensuite exposées via l'API de repos.

Nécessité d'installer un cluster mongodb dans AWS, les exigences:

• données va croître de la même taille chaque jour (environ 50M enregistrements), afin d'écrire le débit n'a pas besoin d'échelle. écrit serait déclenché par un cron à une certaine heure. Les objets sont immuables (ils ne se développera pas)
• débit Lire dépendra du nombre d'utilisateurs/trafic, il devrait donc être évolutive. le trafic ne sera pas lourd au début.
• Les données sont pour la plupart simples JSON, ont besoin d'un couple d'indices autour de certains champs pour l'interrogation rapide/filtrage.

quel genre d'architecture dois-je utiliser en termes d'ensembles de répliques, des tessons, etc?.

Quels types de volumes de stockage dois-je utiliser pour cette architecture? (EBS, NVMe)? Est-il préférable d'utiliser plus d'instances ou d'utiliser des configurations RAID? ?

Je cherche à passer un peu de ~ 500 par mois.

Merci à l'avance

Answer 1

Pour configurer le cluster MongoDB dans AWS je recommande de consulter la dernière AWS quick start pour MongoDB qui couvrira les aspects architecturaux et fournit également des modèles de CloudFormation.

Pour les volumes de stockage dont vous avez besoin d'utiliser des types d'instances EC2 qui prend en charge EBS au lieu de stockage NVMe depuis NVMe est seulement un stockage d'instance. Si vous arrêtez et démarrez l'EC2, les données dans NVMe sont perdues.

également pour le débit de volume de stockage, vous pouvez commencer avec General Purpose IOPS avec la taille de stockage et resonable si vous trouvez des limites alors considérer que provisionnés IOPS.

Pour la haute disponibilité et la tolérance aux pannes du CloudFormation va créer plusieurs instances (nœuds) dans MongoDB groupe.