Why real-world DynamoDB usage scenarios often lead to unexpected expenses イン , 私は、予測不能なワークロードがDynamoDBで予測不能なコストにつながる方法について説明しました。 DynamoDBコストについての記事一覧 さて、もっと深く行こう! あなたが基本を理解したとき、ナッティのように , または、アイテムのサイズ、複製、キャッシュに関する過剰なコスト...あなたはDynamoDBのコストが単に読み込み/書き込みのボリュームに関係するのではなく、実際の世界ではより多くの色合いがあることに気づくでしょう。 7.5x inflation of on-demand compared to reserved ラウンドアップ! A million writes per second at 100 bytes isn’t in the same galaxy as a million writes at 5KB. Why? Because DynamoDB meters out the costs in rounded-up 1KB chunks for writes (and 4KB for reads). Writing a 1.2KB item? You’re billed for 2KB. Reading a 4.5KB item with strong consistency? You get charged for 8KB. You’re not just paying for what you use, you’re paying for rounding up. Remember this character in Superman III taking ½ a cent from each paycheck? It’s the same deal (and yes, $85,789.90 was a lot of money in 1983) … 無駄な容量は規模では避けられないが、毎回その限界を越えると非常にリアルになり、非常に速くなります。そして、物件あたり400KBのハードマップを忘れないでください。 わたしたち これは、紛争解決した書き込み(複数の地域での同時アップデートなど)が、たとえ最後の書き込みのみが勝ったとしても、毎回費用がかかるという事実のような、現実世界の地雷のいくつかを意味しません。あるいは、あなたが自分のTTL expiration logicを構築するとき、たぶんスキャン中にアイテムの群を引っ張り、アプリコードのタイムスタンプをチェックしたり、削除を発行したりします。 現在、ご要望に応じてご覧いただけます。 DynamoDB cost calculator DynamoDB Webinar のコスト グローバルテーブルはグローバルな痛み 世界中のユーザーのために低い遅延を望みますか?グローバルテーブルはそれを実現するための最も簡単な方法です。 それぞれの書き込みは追加の地域で複製されます。 3.5KB の項目を書き、それを 4 つの地域に複製しますか? 今あなたは 4 x 4KB (ラウンドアップ、もちろん) を支払っています。 地域間のネットワーク転送をタックすることを忘れないでください。 それはプレミアム価格でもう一つのヒットです。 そして、ごめんなさい、それらの複製された書き込みも予約できません。 あなたはそのスピードを何度も何度も支払っているし、あなたの地域の成長とともに口座は線形的にスケールします。 複数のエリアが同時に同じ項目に書き込むと悪化します。DynamoDBは紛争を解決します(最後の書き込みは勝ちます)しかし、あなたは毎回支払いをします。 私たちのコスト計算機は、あなたがこれらすべてをモデルすることができます。我々は米国東部のための保守的な価格を使用しますが、地域がよりエキゾチックであるほど、コストが高くなる可能性があります。 ですから、バッテリーを含むグローバルテーブルの複製コストについて考えてみてください、そして覚えておいてください。 ! テーブルについて DAX キャッシュ with a catch DynamoDB Accelerator (DAX) は役立ちますが、オペレーションと財務の両方にオーバーヘッドを追加します。 クラスターは正しいサイズで調整され、ヒット比が調節され、アプリケーションで処理されるエラーケースです。 キャッシュを逃す、読むために支払う。 キャッシュを更新しないでください、データをストールするリスクがあります。 DAX インスタンスは、1 時間ごとに、固定料金で、また、あなたが慣れているように予約インスタンスオプションなしで請求されます。 DynamoDBコスト計算機では、キャッシュヒット比、データセットサイズ、インスタンスタイプ、ノードをシミュレートできますが、キャッシュ効率を予測することはできません。 数百万ドルの推奨エンジン 大規模なストリーミングサービスがDynamoDBを使用してグローバルな推奨エンジンを構築しました. Daily batch jobs generate fresh recommendations and write them to a 1PB single table, replicated across 6 regions. 彼らは遅延とローカルな書き込みに最適化しました。コストは? すべての書き込みはベーステーブルに加えて5回繰り返された書き込みです。 すべてのユーザーのインタラクションは書き込みを引き起こしました(履歴、フィードバック、好み)。 そして、その毎日のリフレッシュサイクルのおかげで、彼らはテーブルを書き換えました - 何かが変わったかどうか。 彼らは予想されるトラフィックのピークのためにスケールアップするプロビジョン容量を使用しましたが、まだ遅延と闘っていました。 結果? ベースワークロードだけでも年間数千万ドルがかかりますが、トラフィックのピークやバッチロードプロセスでピークを収容した後、合計が倍増しました。 多くのチームにとって、これは製品自体の収入以上です! だから、彼らはScyllaDBに振り向きました。 プロビジョン化された容量に基づく価格設定モデルに切り替えた後(プロビジョン化された容量ではなく)ScyllaDBは、ストレージされたデータを大幅に圧縮し、AZsと地域間のネットワーク圧縮を改善しました。 生き残るためのキャッシュのもう一つのケース DynamoDB を使用する adtech 会社は、ハードな方法でキャッシュの複雑さに突入しました. 彼らは 4 つの地域に 48 つの DAX ノードを展開し、P99 の遅延目標を達成しました. 各ノードはその地域のワークロードに合わせて調整されています (多くの試行とエラーの後)。 彼らの書き込み (246 バイト/アイテム) は請求された書き込みユニットの 75% を浪費していました. 彼らの分析ワークロードはピーク時にライブトラフィックをタンクしました. そして、おそらく最悪なことに、自動スケーリングトリガーは十分に速くなかったので、リクエストのスルーティングとアプリケーションの失敗を引き起こしました. DynamoDBとDAXの合計コストは年間数十万ドルだった。 ScyllaDB はよりシンプルなソリューションを提供しました。インスタンスメモリを追加コストなしで使用し、外部のキャッシュ レイヤーが維持されていません。 パフォーマンスにヒットせず。 仕事の優先順位 さらに良いことに、彼らのTTLベースのセッションの期限が自動的に処理され、追加の読み取り/削除の論理なしでコストと複雑さが低下し、彼らは今幸せな顧客です。 DynamoDBのコストビデオを見る If you missed the webinar, be sure to check out the 特にGuilhermeは、これらのすべての現実世界のワークロードを詳細にカバーしています。 DynamoDBの動画コスト DynamoDBのコストは非線形であり、パターンによって形作られ、経過量だけではありません。 グローバルなテーブル、アイテムサイズ、紛争解決、キャッシュ・ワームアップなどは、「合理的な」使用を7桁の悪夢に変えることができます。 DAXと自動スケーリングは魔法ではありません;それらは調節を必要とし、それでも正しい方法を得るにはかなりの費用がかかります。 DynamoDB コスト計算機は、これらの隠されたコストをモデル化し、ScyllaDB を使用していない場合でも、さまざまなセットアップを比較するのに役立ちます。 最後に、DynamoDB を使用して予測不能なコストとパフォーマンスを持つチームであれば、ScyllaDB に切り替えて、予測可能な価格設定、内蔵効率、データベースアーキテクチャに対するより多くのコントロールの利点をお楽しみください。 . Chat with us こちら About Tim Koopmans ティムは、信頼性とセキュリティのための傾向を持って、過去数十年間、あらゆる形のエンジニアリングに携わってきました。2013年に彼は、分散型パフォーマンステストプラットフォームであるFlood IOを設立しました。
