Merci ache pour ton commentaire :) (enfin une personne constructive).
S3 Express est bien plus cher sur le stockage mais 50% moins cher sur les requêtes.
Prenons pour exemple le cas d’une entreprise ayant un datalake de 500 Go de données avec un volume de 100 Millions de requêtesGET et SELECT mensuel et 100 Millions de requêtesPOST, PUT et LIST mensuel.
Avec les tarifs fournis par AWS pour le stockage S3 dans la région US East (N. Virginia) on constate rapidement que le prix du stockage est mutiplié par x7 alors que le coût pour 1,000 requêtes est seulement divisé par /2.
Approfondissons maintenant notre scénario de départ, nous obtenons les calculs suivants :
Avec S3 Standard, la facture mensuelle de stockage s’élève à $11,5, auxquels s’ajoutent $540 pour les requêtes, totalisant $551,5.
Pour S3 Express One Zone, le coût mensuel de stockage atteint $80, et les frais de requêtes se montent à $270, donnant un total de $350.
Dans ce scénario l’intérêt financier est uniquement pour des applications gourmandes en données — accès fréquent. Toutefois, pour les usages moins centrés sur les accès fréquent aux données, le supplément lié au stockage pourrait s’avérer contre-productif. Dans ce cas, s’orienter vers une solution comme S3 Standard, voire Standard - Infrequent Access serait plus judicieux.
En faisant cette réponse, j’en ai profité pour éditer l’article pour ajouter cet exemple et clarifier ce point qui en avait besoin.
Je te remercie …
Mon enthousiasme pour ce produit est réel, rien d’artificiel. Il est souvent facile de critiquer AWS, mais je suis curieux de découvrir quelles autres entreprises offrent une technologie similaire. Avez-vous des suggestions?
De mon point de vue, AWS est une fois de plus en train de poser les jalons pour ce qui deviendra probablement un standard que d’autres s’empresseront de suivre/imiter.
Non moi non plus je ne suis pas convaincu. J’ai le même sentiment que toi, mais je crache pas encore dessus car il pourrait devenir aussi bien que go.mod.
Non, tu confonds écriture inclusive et point médian. Le point médian a effectivement des problèmes, à étudier s’ils sont sérieux où hypothétiques.
Personnellement, je suis pour un retour à l’accord de proximité plus naturel pour moi et plus beau à entendre.
Je ne comprends pas vraiment le besoin d’un point médian si ce n’est pour simplifier un langage pompeux. (ex: Toutes et tous, Les bourgeoises et bourgeois, …).
Je suis pour également que la prononciation « Travailleur et travailleuse » quand les gens utilisent le point médian. Car oui, c’est dégueulasse de prononcer « Travailleur·e ». comme ça: Travailleur RE en insistant sur le RE.
C’est pas un tutoriel mais un mémorandum. En plus, le contenu n’est pas centré sur le sujet. Aucune optimisation réelle mais un rappel plutôt superficiel et tellement bref des fondamentaux en administration système.
Désactiver l’IPv6 sur Ubuntu
Les opérateurs réseaux terminent leur transition vers l’IPv6 au bout de deux décennies. Mieux vaut donc avoir la tête tournée vers le passé en se débarrassant de l’IPv6. Très judicieux au vu de la pénurie d’adresse IP.
Et donc sur un article qui parle d’un langage de programmation et de sa syntaxe, tu t’attaques à l’usage de l’écriture inclusive et non sur la syntaxe du langage en question alors qu’ils sont “aussi lisibles” l’un que l’autre ?
Merci ache pour ton commentaire :) (enfin une personne constructive).
S3 Express est bien plus cher sur le stockage mais 50% moins cher sur les requêtes.
Prenons pour exemple le cas d’une entreprise ayant un datalake de 500 Go de données avec un volume de 100 Millions de requêtes
GETetSELECTmensuel et 100 Millions de requêtesPOST,PUTetLISTmensuel.Avec les tarifs fournis par AWS pour le stockage S3 dans la région US East (N. Virginia) on constate rapidement que le prix du stockage est mutiplié par
x7alors que le coût pour 1,000 requêtes est seulement divisé par/2.Approfondissons maintenant notre scénario de départ, nous obtenons les calculs suivants :
Dans ce scénario l’intérêt financier est uniquement pour des applications gourmandes en données — accès fréquent. Toutefois, pour les usages moins centrés sur les accès fréquent aux données, le supplément lié au stockage pourrait s’avérer contre-productif. Dans ce cas, s’orienter vers une solution comme S3 Standard, voire Standard - Infrequent Access serait plus judicieux.
En faisant cette réponse, j’en ai profité pour éditer l’article pour ajouter cet exemple et clarifier ce point qui en avait besoin.
Comment vous avez fait pour ne pas parler du coût du stockage qui rend ainsi toutes vos affirmations types
totalement caduques ?
Cela me rappelle le discours des thuriféraires d’Apple. Mot pour mot.
Comme tout le site… ;) Étrange cette boîte apparue depuis quelques mois et qui ne semble proposer que du vent. Des trentenaires désœuvrés ?
Je te remercie … Mon enthousiasme pour ce produit est réel, rien d’artificiel. Il est souvent facile de critiquer AWS, mais je suis curieux de découvrir quelles autres entreprises offrent une technologie similaire. Avez-vous des suggestions?
De mon point de vue, AWS est une fois de plus en train de poser les jalons pour ce qui deviendra probablement un standard que d’autres s’empresseront de suivre/imiter.
On croirait une pub écrite par une IA…
Si si ça se trouve ici
Bon billet, vivement la suite !
ps : il n’y a pas de flux rss, sur ce blog ?
Salut Lionel ! Je relève juste le ton d’injonction. On a tous droit à l’erreur ou simplement à changer d’avis. Même Ploum !
Article dur à lire. Par sa structure, ses anglicismes / franglais, sa technicité.
Mais il reste intéressant même s’il traite principalement du B.A-BA.
Bon des le début, cron au démarrage. De nombreuses distributions n’ont plus de service cron qui tournent (remplacé par Systemd rimer).
Ne prenez pas cela a la lettre … Et oui désactivé ipv6, qu’elle hérésie.
Y’a quand même 10 ans entre les 2 jours que tu cites ;-)
Merci !!
Use After Free: https://beta.hackndo.com/use-after-free/
Non moi non plus je ne suis pas convaincu. J’ai le même sentiment que toi, mais je crache pas encore dessus car il pourrait devenir aussi bien que go.mod.
Non, tu confonds écriture inclusive et point médian. Le point médian a effectivement des problèmes, à étudier s’ils sont sérieux où hypothétiques.
Personnellement, je suis pour un retour à l’accord de proximité plus naturel pour moi et plus beau à entendre. Je ne comprends pas vraiment le besoin d’un point médian si ce n’est pour simplifier un langage pompeux. (ex: Toutes et tous, Les bourgeoises et bourgeois, …).
Je suis pour également que la prononciation « Travailleur et travailleuse » quand les gens utilisent le point médian. Car oui, c’est dégueulasse de prononcer « Travailleur·e ». comme ça: Travailleur RE en insistant sur le RE.
C’est pas un tutoriel mais un mémorandum. En plus, le contenu n’est pas centré sur le sujet. Aucune optimisation réelle mais un rappel plutôt superficiel et tellement bref des fondamentaux en administration système.
Les opérateurs réseaux terminent leur transition vers l’IPv6 au bout de deux décennies. Mieux vaut donc avoir la tête tournée vers le passé en se débarrassant de l’IPv6. Très judicieux au vu de la pénurie d’adresse IP.
Et donc sur un article qui parle d’un langage de programmation et de sa syntaxe, tu t’attaques à l’usage de l’écriture inclusive et non sur la syntaxe du langage en question alors qu’ils sont “aussi lisibles” l’un que l’autre ?
Qu’est-ce qu’une UAF ?
Merci pour l’info sur les dépendances. Ça semble tout récent (janvier 2023!).
Pas vraiment convaincu que build.zig soit vraiment plus pratique que go.mod. J’attends de voir.
Un jour ploum vous dit d’aller sur twitter. Un autre ils vous dit que vous avez le “devoir” de supprimer votre compte.
Bon exemple. Le point médian rends le français aussi lisible que ça.