データベースのパフォーマンスは真剣なビジネスですが、なぜその課題や複雑さを探索することを楽しむことができないのですか? 😉 ここでは、私たちが第1章で紹介した、かなり素晴らしいストーリーです。 . Database Performance at Scale、無料のオープンアクセスブック データベース スケール パフォーマンス データベース スケール パフォーマンス テクニカルなトピックは、本書全体で拡張されていますが、これは私たちが貧しいパトリックについて話す唯一の機会です。彼の闘いはあなたにいくつかの貴重なレッスン、あなた自身のデータベースのパフォーマンスの予測に慰めをもたらします...そして、おそらくいくつかのチャックルも。 ♪♪♪ FAANG MAANG(MANGA)の会社で仕事を失った後、パトリックは独自にストライキを決め、ヘッドウェア、グリーンフェドラの間で彼の絶対的な好みを取引するニッチオンラインショップを設立しました。 オファーの無料レベルでのいくつかの実験の後、Patrickは、NoSQLデータベースとしてのサービスとしてのオファーの大幅な割引を得るために、主要なクラウドプロバイダーとの1年間の契約に署名することにしました。毎秒1000人の顧客にサービスを提供するためのプロビジョンされたパブリットで、テクノロジースタックは準備ができ、店舗は顧客に仮想ドアを開きました。Patrickの失望に、10人未満の顧客が毎日サイトを訪れました。同時に、輝かしい新しいデータベースクラスターは、彼のクレジットカードからの資金の安定した流入によって動き続け、その可能性を活用するのを待っていました。 Patrick’s Diary of Lessons Learned, Part I パトリックの教訓日記 Part I レッスンはすぐに始まりました: いくつかのデータベースは、普遍的であると宣伝しますが、ほとんどのデータベースは特定の種類のワークロードに最適です。 予測可能で安定したリクエストの流れ(たとえば、定期的に他のシステムからアップデートを受け取る)がある可能性がありますか。 差は高く、システムが潜在的に長期にわたって無職であることによって予測しにくいことがありますか? データベースとしてのサービスのオファーは、しばしば提供されたパウドプットとリクエスト購入の間を選択することを可能にします。 前者はよりコスト効率的ですが、データベースが実際にどれほど忙しいかに関係なく一定のコストが発生します。 設定が持続可能な方法であなたのために働くことを確認する前に、選択を評価し、長期契約にコミットすることを避けるために時間を与えましょう(割引で誘惑されても)。 最初のスパイク 3月17日は非常にラッキーな日だったように思われました。パトリックは朝早くから多くの新しい注文に気付いたことを嬉しく思いましたが、アクティブな顧客の数が昼過ぎに急激に増加したため、パトリックの気分は悪化し始めました。 彼自身とウェブ検索エンジンとの短いブレインストーミングセッションの後、パトリックは、彼の驚いたことに、彼は彼の貴重な(そしてかなり高価な)データベースクラスターで観察可能なツールが欠けていたことに気付きました。 パトリックは自分自身に怒鳴りながら、午前11時ごろに現れ始めた数千件の「通過量を超えた」エラーメッセージをスローアップした。 Patrick’s Diary of Lessons Learned, Part II パトリックの教訓日記 Part II パトリックが学んだこと: あなたのワークロードがピークに敏感である場合は、それに備えてクラスターを構築して、一時的に高いロードに耐えられるようにしてください. Database-as-a-service solutions tend to allow configuring the provisioned throughput in a dynamic way, which means that the threshold of accepted requests can occasionally be raised temporarily to a previously configured level. または, respectively, they allow it to be temporarily reduced to make the solution slightly more cost-efficient.データベース-as-a-service solutions tend to allow configuring the provisioned throughput in a dynamic way, which means that the threshold of accepted requests can occasionally be raised temporarily to a previously configured level. または, respectively, they allow it to be temporarily reduced to make the あなたのワークロードが絶対に安定している場合でも、一時的なハードウェアの故障や突然のDDoS攻撃は、入力されたリクエストの急増を引き起こす可能性があります。 観察性は、分散型システムにおいて重要な要素です. 開発者が失敗を追跡的に調査することを可能にします. それはまた、可能性のある失敗シナリオが検出されるときにリアルタイムの警告を提供し、人々が迅速に反応し、より大きな失敗を防止するか、または少なくともクラスターへのネガティブな影響を最小限に抑えることを可能にします。 初の損失 パトリックは、書簡が届いたとき、グリーンフェドラスが何らかの需要を経験した1年間の唯一の日に、彼の潜在的な収入のほとんどを失うというトラウマから回復することはできなかった。 パトリックはそのデータベースを再度閲覧し、驚いたことに、オーダーの痕跡も見つかりませんでした。完全性のために、パトリックはまた、バックアップスナップショットディレクトリを閲覧することによって意欲的な考え方を実践しました。 すべての人々がどのようにしてデータを失ったのか? 彼の選択したデータベースの一貫性モデルを研究した後、パトリックは、一貫性保証、パフォーマンス、および可用性の間で合意があることに気付きました。 クエリを構成することで、LinearizabilityFootnote7を減少したパフォーマンスのコストで要求するか、または一貫性保証を削減し、パフォーマンスを相応に増やすことができます。 より高いパフォーマンスの能力は数日前にパトリックにとって不思議だったが、最終的に顧客データはシステム内でリプリカが配布されていない一つのサーバーに着陸しました。 Patrick’s Diary of Lessons Learned, Part III パトリックの教訓日記 Part III その他のレッスンには: バックアップは分散環境で不可欠であり、バックアップルーチンを「早すぎる」と設定するようなものは存在しません。 すべてのデータベースシステムには一定の一貫性モデルがあり、プロジェクトを設計する際にそれを考慮することが重要です. 妥協があるかもしれません. いくつかの使用例(金融システムを考える)では、一貫性が鍵です。 スパイクが再びストライキ 数ヶ月が経ち、パトリックの睡眠スケジュールは安定化の兆候を示し始めたが、定期的なバックアップ、再設計された一貫性モデル、および3月16日のスケジュールでクラスターを拡大し、高騰したトラフィックを管理するためのメモリで、彼は穏やかに安全を感じた。 もし彼が知っていたら、マレーシアでレプレッシャウンの衣装を着た猫の10秒間のビデオが、タイムゾーンを考慮すると、パトリックの時間の2時ごろに起こり、上記の睡眠安定化努力を台無しにしました。 一方で、観測可能なスイートは仕事を果たし、早期に警告を開始し、迅速な対応を可能にしました。他方で、パトリックが時間に応じて反応したにもかかわらず、データベースはしばしば瞬時にスケールすることができず、彼の選択のシステムはその点で例外ではありませんでした。競合のピークは非常に高く、集中し、マレーシアの十代の若者が、常に変化するインターネットのトレンドを追求して、大量で緑色の帽子を購入するために急いでいました。 L = λW という美しく簡潔な公式で、法則は、共通性が通過時間の遅延に等しいという事実に簡素化することができる。 リトルの法則 コンクールは単位でしかありませんが、遅延は秒で測定できますが、経過量は通常、 1/s で表現されます。 タイプ: タイプ: デフォルトはハードウェアに依存し、自然に限界があります(例えば、2023年に購入したNVMeドライブは、この仮定が近い将来無効になるために私たちの指を横断しているにもかかわらず、秒あたりテラバイトであなたのためにデータを提供することを期待することはできません!)限界が打たれたら、あなたはそれを公式で常時として扱うことができます。それから、コンコレクションが上昇するにつれて、遅延が同じであることは明らかです。このシナリオのマレーシアのティーンユーザーにとって、これは、遅延が最終的に数秒の平均的な人間の感覚のための魔法の障壁を横断することを意味します。これが起こると、ユーザーはあまりにも落ち込んでおり、システムが修理を超えて破損していると仮定して Patrick’s Diary of Lessons Learned, Part IV パトリックの教訓日記 Part IV レッスンは続く: 予期せぬピークは避けられ、クラスターの拡張は過度のコンコレクションの悪影響を軽減するのに十分なスピードでない可能性があります。データベースが適切に処理することを期待することは無駄ではありませんが、すべてのデータベースがその能力を持っているわけではありません。 可能であれば、できるだけ早くシステム内のコンコレクションを制限してください。 たとえば、データベースが顧客によって直接触れることがない場合(複数の理由で非常に良いアイデアです)が、代わりにあなたのコントロール下のマイクロサービスのセットを通じてアクセスされる場合、マイクロサービスもコンコレクションの限界を知っており、それに従うことを確認してください。 リトルの法則が存在することを覚えておいてください - 分散システムに興味のある誰にとっても基本的な知識です。 バックアップストライキ 予想外の同期の変動を考慮するためにプロジェクトを再設計した後、パトリックは、彼のフェドラビジネスがついにラメンで利益を得るのを楽しみにしていた。 残念なことに、次の3月17日も予想通りに順調に進まなかった。パトリックは一日の大半をグラファナのダッシュボードを楽しんで過ごし、トラフィックがコントロールされ、健康な安全なマージンで顧客の負荷を処理できることを彼に保証し続けた。しかし、ダッシュボードは停止し、ディスクが重度に過剰に使用されたと丁寧に言及した。これは観察された共通点から見て完全に不適切に見えた。この異常の可能性の源を探している間、パトリックは、彼の恐怖に、予定されたバックアップ手順が年間ピーク負荷と一致したことに気付いた... Patrick’s Diary of Lessons Learned, Part V パトリックの教訓日記 Part V 結論の思考: データベースシステムは、ユーザーのリクエストなしでさえ、ほとんど無職ではありません。メンテナンス操作はしばしば起こり、彼らは共通貨とリソース消費の内部の源であるため、それらを考慮する必要があります。 可能な限り、システムに予想される低圧の時間帯にメンテナンスオプションをスケジュールしてください。 データベース管理システムがサービス品質の構成をサポートしている場合、そのような機能を調査するのが良い考えです. たとえば、通常のメンテナンス操作よりもユーザーのリクエストを優先的に設定することができ、特にピーク時間の間です. したがって、低いユーザー誘発活動の期間は、バックグラウンド活動を加速するために使用できます. データベースの世界では、データのストレージに基づくLSMの木の変数を使用するシステムは、読み書き性能を予測し、安定させることができるように、かなり多くの圧縮(データのメンテナンス操作の一種)を実行する必要があります。 結末です。 Piotr Sarnaについて オープンソースプロジェクトやRustとC++言語に興味を持ったソフトウェアエンジニアで、以前はオープンソース分散ファイルシステムを開発し、サムスン・エレクトロニクスでの学習期間中にLinuxカーネルとの短い冒険を経験しました。彼はまた、ScyllaDBの長期貢献者であり、LibSQLを維持しています。Piotrはワルシャワ大学でコンピュータサイエンスの修士号を取得しました。彼は「Database Performance at Scale」と「Writing for Developers: Blogs that Get Read」の共著者です。 ペトロ
