Dans mon dernier article de blog, nous nous sommes concentrés sur les améliorations de performance associées à Google BigQuery Snaps dans la version 4.11. Cette semaine, dans le cadre de la poursuite de l‘examen des détails des nouveautés de la version d‘automne 2017, nous nous concentrons sur les gains de performance supplémentaires de la version 4.11. Nous ne parlons pas seulement des mises à jour habituelles, mais de la vitesse.
Deux de nos Snaps de transformation, Sort et In-Memory Lookup, ont bénéficié d‘améliorations significatives des performances dans la version 4.11. L‘équipe de développement de SnapLogic avait pour mission d‘éliminer les latences inutiles qui peuvent passer inaperçues sous des charges légères, mais qui sont plus évidentes avec des volumes de données plus importants. L‘amélioration de l‘efficacité du traitement et l‘augmentation de la taille des ensembles de données pouvant être traités en mémoire constituaient une priorité majeure.
Le résultat est un traitement beaucoup plus rapide avec une plus grande résilience pour des volumes de données plus importants. Au cas où vous penseriez que ce billet n‘est qu‘une métaphore, examinons les chiffres (attachez vos ceintures !):
Vos résultats varieront, bien sûr, en fonction du profil matériel du nœud Snaplex, des éléments de données, de la taille des données, etc., mais le graphique ci-dessus montre une amélioration très cohérente et significative des performances de tri. L‘instantané de tri est dans les 10 % des instantanés les plus utilisés (sur plus de 400), il y a donc de fortes chances que vous ayez déjà ressenti les avantages de cette amélioration particulière de la performance.
De plus, si vous avez des Snaps de transformation en aval comme Join, Aggregate, In-Memory Lookup, etc. dans votre pipeline, le fait de trier vos données en premier se traduira par de meilleures performances globales.
Quant à l‘instantané de recherche en mémoire, il a lui aussi bénéficié d‘une amélioration des performances. Non seulement l‘instantané de recherche en mémoire est plus rapide, mais il peut traiter davantage de données en mémoire. Prenons l‘exemple suivant :
Encore une fois, les mêmes petits caractères que ci-dessus s‘appliquent* (*vos résultats varieront en fonction de la configuration matérielle et des données), mais les tests SnapLogic présentés dans le tableau ci-dessus montrent clairement une amélioration cohérente et significative des performances, par rapport à la même configuration matérielle et au même ensemble de données. Résultat ? La possibilité de traiter des ensembles de données beaucoup plus importants avec le Snap Lookup In-Memory.
Nous continuerons à nous concentrer sur l‘amélioration des performances, petites et grandes, aujourd‘hui et dans les prochaines versions. Après tout, chaque milliseconde compte à grande échelle.
Alors, faites un tour avec votre nouveau supercharger et dites-nous ce que vous en pensez.
