Why real-world DynamoDB usage scenarios often lead to unexpected expenses dans , J'ai couvert comment des charges de travail imprévisibles entraînent des coûts imprévisibles dans DynamoDB. Mon dernier billet sur DynamoDB Maintenant, allons plus profondément. Une fois que vous avez compris les bases, comme le nutty , ou les coûts excessifs autour de la taille des éléments, de la réplication et de la mise en cache ... vous vous rendrez compte que les coûts de DynamoDB ne concernent pas seulement le volume de lecture / écriture - il est beaucoup plus nuancé dans le monde réel. 7.5x inflation of on-demand compared to reserved Round ‘em up ! Un million d'écrits par seconde à 100 bytes n'est pas dans la même galaxie qu'un million d'écrits à 5KB. Pourquoi? Parce que DynamoDB mesure les coûts en morceaux arrondis de 1KB pour les écrits (et 4KB pour les lectures). Écrire un article de 1.2KB? Vous êtes facturé pour 2KB. Lire un article de 4.5KB avec une forte cohérence? Vous êtes facturé pour 8KB. Vous ne payez pas seulement pour ce que vous utilisez, vous payez pour l'arrondissement. Rappelez-vous ce personnage dans Superman III prenant 1⁄2 centime de chaque paiement? C'est la même affaire (et oui, 85,789,90 $ était beaucoup d'argent en 1983) ... Le gaspillage de capacité est inévitable à l'échelle, mais il devient très réel, très rapide lorsque vous franchissez cette limite à chaque opération. Et n'oubliez pas que la limite dure de 400KB par article. Ce n'est pas un problème de prix directement, mais c'est quelque chose qui a motivé les clients de DynamoDB à chercher des alternatives. notre vous permet de modéliser tout cela. Ce qu'il ne compte pas, ce sont quelques-unes des mines terrestres du monde réel - comme le fait qu'une écriture résolue en conflit (comme des mises à jour simultanées dans plusieurs régions) vous coûte toujours pour chaque tentative, même si seulement la dernière écriture gagne. Ou lorsque vous construisez votre propre logique d'expiration du TTL, peut-être en tirant un tas d'articles dans une analyse, en vérifiant les timestamps dans le code de l'application, ou en émettant des suppressions. que vous pouvez maintenant regarder sur demande. Calculateur de coûts DynamoDB DynamoDB coûte un webinaire Les tables mondiales sont une douleur mondiale Donc, vous voulez une latence faible pour les utilisateurs du monde entier? Les tables globales sont le moyen le plus facile de le faire. Certains pourraient même dire qu'il s'agit de "batteries comprises". Chaque écriture est dupliquée dans des régions supplémentaires. Écrivez un élément de 3.5KB et répliquez-le dans 4 régions? Maintenant, vous payez pour 4 x 4KB (enroulé, bien sûr). N'oubliez pas de prendre en charge le transfert de réseau interrégional. C'est un autre coup à prix premium. Et désolé, vous ne pouvez pas réserver ces écrits répliqués non plus. Vous payez pour cette vitesse, plusieurs fois, et la facture évolue linéairement avec votre croissance régionale. Il devient pire lorsque plusieurs régions écrivent sur le même élément en même temps. DynamoDB résout le conflit (la dernière écriture gagne), mais vous payez toujours pour chaque tentative. Notre calculateur de coûts vous permet de modéliser tout cela. nous utilisons des prix conservateurs pour les États-Unis-Est, mais plus la région est exotique, plus les coûts seront élevés. Donc, pensez à ce que les coûts de réplication des tables globales comprises dans les batteries, et n'oubliez pas, c'est ! par table DAX caching avec un catch Maintenant, voulez-vous une latence de lecture encore plus serrée, en particulier pour votre P99 sensible à la latence? DynamoDB Accelerator (DAX) aide, mais il ajoute un surcoût, à la fois opérationnel et financier. Les clusters doivent être dimensionnés correctement, les rapports de frappe ajustés et les cas de défaillance traités dans votre application. Manquez le cache, payez pour la lecture. Ne pas mettre à jour le cache, risquez de bloquer les données. Les instances DAX sont facturées par heure, à un taux fixe, et encore une fois, sans options d’instance réservées comme vous l’avez peut-être l’habitude. Notre calculateur de coût DynamoDB vous permet de simuler les rapports de succès du cache, les tailles des ensembles de données, les types d'instances et les nœuds. Il ne prévoit pas l'efficacité du cache, mais il vous aidera à attraper ces gotches du cache. Un moteur de recommandation de plusieurs millions de dollars Un grand service de streaming a construit un moteur de recommandation mondial avec DynamoDB. Les postes de lots quotidiens génèrent de nouvelles recommandations et les écrivent sur une table unique de 1 PB, répliquée dans 6 régions. Ils ont optimisé pour la latence et les écrits locaux. Le coût? Chaque écrit à la table de base plus 5 écrits répliqués. Chaque interaction utilisateur a déclenché un écrit (historique, commentaires, préférences). Et grâce à ce cycle de rafraîchissement quotidien, ils ont réécrit la table – que quelque chose ait changé ou non. Ils ont utilisé la capacité de la provision, en augmentant pour les pics de trafic attendus, mais ont toujours lutté avec la latence. La charge de travail de base seule coûte des dizaines de millions par an, et le total a doublé après avoir accueilli des pics dans les pics de trafic et les processus de chargement en lots. Pour de nombreuses équipes, c’est plus que le revenu du produit lui-même! Après avoir passé à notre modèle de tarification basé sur la capacité prévue (pas la facturation par opération), ScyllaDB a été en mesure de compresser considérablement leurs données stockées, tout en améliorant la compression du réseau entre les AZ et les régions. Ils avaient la liberté de le faire sur n'importe quel nuage (ou même sur site). Ils ont réduit leurs coûts, amélioré les performances et éliminé le besoin de surprovisionner pour les pics. Un autre cas de caching pour survivre Une société adtech utilisant DynamoDB est entrée dans la complexité du cache de la manière la plus difficile. Ils ont déployé 48 nœuds DAX dans 4 régions pour atteindre leurs objectifs de latence P99. Chaque nœud est adapté à la charge de travail de cette région (après beaucoup d'essais et d'erreurs). Leurs écrits (246 octets/élément) ont gaspillé 75% de l'unité d'écriture facturée.Leur charge de travail d'analyse a augmenté le trafic en direct pendant les pics.Et peut-être le pire de tout, les déclencheurs d'auto-échelle n'étaient tout simplement pas assez rapides, ce qui a entraîné des échecs de requêtes et d'applications. Le coût total de DynamoDB et DAX était de centaines de milliers par an. ScyllaDB a offert une solution beaucoup plus simple. La mise en cache en ligne intégrée utilisait la mémoire d'instance sans frais supplémentaires sans couche de mise en cache externe à entretenir. Sans toucher à la performance. Priorité de travail Mieux encore, leur expiration de session basée sur TTL a été traitée automatiquement sans logique de lecture / suppression supplémentaire. Voir la vidéo des coûts de DynamoDB Si vous avez manqué le webinaire, assurez-vous de vérifier – en particulier où Guilherme couvre tous ces charges de travail du monde réel en détail. DynamoDB coûte la vidéo Les coûts de DynamoDB sont non linéaires et sont façonnés par des modèles d’utilisation, pas seulement par le débit. Les tables globales, la taille des éléments, la résolution des conflits, le réchauffement du cache et plus encore peuvent transformer une utilisation « raisonnable » en un cauchemar à 7 chiffres. Le DAX et l’auto-escalage ne sont pas magiques ; ils ont besoin d’être ajustés et coûtent encore beaucoup d’argent pour être corrects. Notre calculateur de coûts DynamoDB vous aide à modéliser ces coûts cachés et à comparer les différentes configurations, même si vous n'utilisez pas ScyllaDB. Enfin, si vous êtes une équipe avec des coûts et des performances imprévisibles en utilisant DynamoDB, passez à ScyllaDB et profitez des avantages de la tarification prévisible, de l'efficacité intégrée et d'un plus grand contrôle sur votre architecture de base de données. . Chat avec nous ici À propos de Tim Koopmans Tim a été impliqué dans toutes les formes d'ingénierie au cours des dernières décennies avec une tendance à la fiabilité et à la sécurité.En 2013, il a fondé Flood IO; une plate-forme de test de performance distribuée.Après son acquisition, il a apprécié l'élargissement du produit, de l'entreprise et de l'équipe avant de passer à d'autres efforts liés à la performance.
