Scénario d'affiche pour le Big Data :vous devez passer au crible une grande quantité de données pour en extraire une minuscule " pépite » d'informations. De plus, cela doit être fait dans les plus brefs délais, votre entreprise en dépend. Historiquement, utilisant la technologie traditionnelle des systèmes de gestion de bases de données relationnelles (RDBMS), ce type de scénario nécessitait une grande équipe et un investissement en temps et en argent. La plupart des SGBDR traditionnels évoluent uniquement verticalement, vous devez donc continuer à acheter des machines de plus en plus grandes pour réduire votre délai d'exécution. L'avènement des clouds publics et des bases de données NoSQL comme MongoDB a complètement bouleversé la façon dont les équipes envisagent ce scénario.
L'un de nos clients est récemment venu nous voir avec un problème intéressant. Ils devaient périodiquement exécuter une requête très complexe qui analysait l'intégralité de leur ensemble de données. Cette requête était à peu près une analyse de collection qui touchait tous les documents de la collection et incluait ces détails :
- Le total des données était d'environ 100 Go.
- La sécurité des données n'était pas un problème puisque la copie principale des données se trouvait ailleurs.
- La vitesse des requêtes était extrêmement importante. L'objectif était de pouvoir exécuter l'intégralité de la requête en 10 à 15 minutes.
- Le système ne devait être opérationnel que lorsque la requête était en cours d'exécution (réduction des coûts).
En raison de la dernière exigence, il était logique d'exécuter l'intégralité du système sur un cloud public. Les machines ne sont allumées que quelques heures par semaine pour que les données soient mises à jour et que la requête soit exécutée. Le client était déjà à l'aise avec Amazon EC2, la décision a donc été prise de prototyper le système dans AWS.
La meilleure configuration pour atteindre cet objectif était un déploiement MongoDB "partagé". Voici la configuration que nous avons choisie :
- 3 partitions :chaque partition possède une instance autonome (r3.xlarge) avec 30 Go de RAM
- 1 serveur de configuration
- 1 routeur de partition (m3.xlarge) avec 15 Go de RAM
Quelques choses à souligner concernant nos choix :
-
Ensemble autonome ou réplique
La sécurité des données n'est pas une exigence importante ici puisque les données de base sont stockées dans un système séparé. Par conséquent, nous avons opté pour des serveurs autonomes au lieu d'un ensemble de répliques pour réduire les coûts.
-
3 serveurs de configuration contre 1 serveur de configuration
même raison que ci-dessus. La sécurité des données n'est pas un problème important. Dans un environnement de production typique, nous aurions opté pour trois serveurs de configuration.
La vraie beauté de cette configuration est qu'en raison de la configuration fragmentée, la quasi-totalité des 100 Go de données est entièrement stockée en mémoire. Donc, essentiellement, ce que vous exécutez est une analyse "en mémoire". Cela a considérablement réduit le temps d'exécution de la requête de quelques heures à moins de 10 minutes. L'utilisation du cloud public a également considérablement réduit l'investissement en capital puisque vous ne payez les machines que lorsqu'elles fonctionnent.
Il s'agit d'un changement assez radical dans la façon dont les équipes ont géré ce scénario au cours de la dernière décennie. Donc, si vous cherchez une aiguille dans une botte de foin, pensez Cloud + NoSQL !
Comme toujours, si vous avez des questions, vous pouvez nous contacter à [email protected].
