Amazonのような会社は、データベースレイヤーへのアクセスのボトルネックをどのように回避しますか？

29

Amazon（または他の大規模なeコマースWebアプリケーション）のような大規模なオンラインストアを運営しており、倉庫内の物理的なアイテムの量が限られている会社を想像すると、どのように最適化できますか？単一のボトルネック？もちろん、レプリケーションを備えた多数のデータベースと、負荷を個別に処理している多くのサーバーが必要です。ただし、複数のユーザーが別々のサーバーでサービスを提供しており、両方が同じアイテムをカートに追加しようとする場合、残りのアイテムは1つだけであるため、そのアイテムの数量には「真実の源」が必要です。これは、少なくとも、単一のアイテムの製品情報にアクセスするすべてのユーザーが、同じデータベースにシリアルでクエリを実行する必要があるという意味ではないでしょうか？

分散コンピューティングを使用して大規模なストアを運営し、インベントリ情報を含む単一のDBに大きなボトルネックを作成しない方法を理解したいと思います。

web-applications scalability distributed-computing

— mattgmg1990
ソース

2000年代半ばのAmazonアーキテクチャ（まだあなたの質問に関連しています）：highscalability.com/amazon-architecture

— Joeri Sebrechts

これは、飛行機の座席でも発生します（または、ショッピングカート内の1つのアイテムがフライト、レンタカー、ホテル宿泊、フライトバックを表すパッケージ休日など）。多くの異なる代理店がそれぞれのサイトで同じ座席を販売しています。。ソリューションは無数にありますが、それらはすべて、どこかで各部分の実際のステータスを含む1つの最終的な真実データベースを持つことになります。

— RemcoGerlich

1

@RemcoGerlich：「1つの最終的な真実のデータベース」という言い方をすると、大きな神聖なデータベースが置かれた1台のマシンを思い浮かべます。実際には、重要なデータに対して行われるのは、すべてのトランザクションが一度に複数のサーバーに到達し、それらすべてのデータベースが常に同期していることです。

— Arseni Mourzenko

27

ただし、複数のユーザーが別々のサーバーでサービスを提供しており、両方が同じアイテムをカートに追加しようとする場合、残りのアイテムは1つだけであるため、そのアイテムの数量には「真実の源」が必要です。

あんまり。どちらのエラーケースにもそれほど高価ではないビジネスソリューションがあるため、これは100％完璧な技術的ソリューションを必要とする問題ではありません。

アイテムが売り切れたことをユーザーに誤って伝えると、売り上げを失います。毎日何百万ものアイテムを販売していて、これが1日に1〜2回行われると、ノイズに埋もれてしまいます。
注文を受理し、処理中にアイテムがなくなったことがわかった場合は、顧客にその旨を伝え、補充できるまで待つか、注文をキャンセルするかを選択するだけです。少しイライラしている顧客がいます。ここでも、注文の99.99％が正常に機能する場合、大きな問題ではありません。

実際、私は最近自分自身で2番目のケースを経験したため、仮説ではありません。

理論的に解決するのが非常に難しい問題（パフォーマンス、最適化など）がある場合に頻繁に適用される概念です。多くの場合、本当にうまく機能するソリューションで生きることができ、時にはそれを受け入れることができます。障害が発生したときにそれを検出して処理できる限り、失敗します。

— マイケル・ボルグワード
ソース

2

クイックサンドの構築と補償取引で説明されているPat Hellandの思い出、推測、および謝罪は、ここで関連するアイデアです。

— デレクエルキンス

1

あなたは「そうではない」と言いましたが、私が提案したことに同意しているように感じます。あなたが言っていることは、ユーザーがブラウジングしているとき、残りの在庫のキャッシュされた近似値を与えるようですが、実際に購入を完了しようとするときのみ、残りの在庫を減らすために書き込みを行います。その値を含むDBは各トランザクションをアトミックに実行します。2人のユーザーが同時に試行すると、2番目のユーザーに対してエラーメッセージが表示されます。したがって、最終的には、「真実」を含む1つのマシン上に1つの整数があります。

— mattgmg1990 16

2

@ mattgmg1990：正しい、最終的にはもちろんどこかで「真実」を知る必要がありますが、重要な違いは注文の処理をキューで実行できるため、同時アトミック書き込みアクセスがまったく必要ないことです。私の場合、Amazon Webサイトで注文を完了してから数時間後に「エラーメッセージ」が表示されました。そのアイテムの供給に問題があり、注文をキャンセルするか何もせずに待つことを選択できるメールを受け取りました彼らがそれを満たすために。私はすぐにアイテムを必要としなかったので、私は後者を行いました、そして彼らは実際に数週間後にそれを配達しました。

— マイケルボルグワード

@DerekElkinsは素晴らしい記事です。特に、デジタルデータは現実が常に不完全であるため、現実にはシステムが自動的に認識できない変更が常に存在するため、現実の表現であるという点が重要です。

— マイケルボルグワード

6

の組み合わせ

ハッシング
シャーディング
複製
分布
高いフェイルオーバー
キーバリューストア

魔法はなく、ますます複雑な状況になります。DNSと同じように、拡張性があります。

「真実の単一バージョン」はそのようなシステムの一部です。新しいキーの生成は、シーケンス内の次の番号を生成するだけでなく、より複雑な操作になります。たとえば、他のシーケンスが存在します。これは、分散データベースシステムが処理できる複雑さの一種であり、新しいオブジェクトを作成するときにコンポーネントとの間で複数の操作を行い、他のユーザーがそれらを使用できるようにし、必要に応じてシーケンスが一意になるようにし、複合キーなどを作成します。

— マイケル・デュラント
ソース

これらの概念のそれぞれについて読みましたが、行き詰まっているのは、在庫が残っている特定のシナリオです。残り5冊の書籍があり、ユーザーが複数のサーバーでリクエストを行っている場合、残りの在庫を照会して2人のユーザーが最後の書籍を同時に取得できないようにするときに、常に単一のデータベーステーブルに解決しますか？上記の特定の用途は、システム全体の速度を低下させず、複数のDBインスタンスでレプリケーションが引き続き有用になるようにすることです。

— mattgmg1990 16

もう少し追加しました。残念ながら、この形式に含まれる複雑さをすべて説明することはできません。

— マイケルデュラント

1

特定の本に興味があるのは一部の人だけです。つまり、比較的小さな負荷で破片で本を扱うことができます。

— バシレフス16

6

システムを説明しているシナリオでは、他の誰かが最後のコピーを購入したことをユーザーに謝罪するだけでよいと思います。これは時々起こると思います。

— マシュージェームスブリッグス

1

コンピューティングが少なく、マーケティングが多いという指標が残っているのは5冊だけだと思います。

— mouviciel 16

5

「在庫の最後のアイテム」の問題は、次の方法で解決されました。

すべての在庫レベルを毎日更新し、しきい値レベルに応じて、製品を高、低、注文中、または在庫切れカテゴリとしてフラグを立てます。

問題のある「在庫不足」のアイテムは明らかに

在庫レベルの高いアイテム

在庫レベルを気にしないでください。注文するだけ

在庫レベルが低いアイテム

「最後の数が残っています！」を参照するときにユーザーに警告します。彼らが支払いに行くとき、在庫レベルをチェックし、デクリメントします。在庫がない場合は、アイテムのステータスを更新します。

この方法では、「在庫の少ない」アイテムのデータベースにアクセスするだけで、顧客が購入プロセスをかなり下回っているときにのみそれを行います。コストは、一部の顧客が購入を完了できないことです。

ただし、ほとんどの場合、「在庫なし」とは、実際には別の配送を待っていることを意味するため、注文を受け入れ、警告を表示したり、配送オプションを制限したりします。そのため、これらの顧客は失われました。

販売などの高負荷時に、在庫チェックをオフにして、後で顧客にメールするだけで、「申し訳ありませんが、Xを使い果たしました。Yをご希望ですか」

基本的に、eコマースプラットフォームの目的はデータベースから読み取られることはありません。キャッシュされたページを常に提供し、クライアント側のすべてを行います。

— ユアン
ソース

2

このビデオでは、Martin FowlerがNoSQLデータベースについて説明しています。

https://www.youtube.com/watch?v=qI_g07C_Q5I

ポイントの1つ（どこかにあります）は、Amazonのような場所では、実際に利用できるかどうかを「確実」に確認することなく、注文を受け入れることで99％の人々を幸せに保ち、「ごめんなさい、誰かがあなたにそれをbeatったように見えます。」

つまり、説明するシナリオには実際の処理はありません。Amazonが最後に成功したインベントリ読み取りに基づいて疑いの恩恵を享受し、同時トランザクションが間に入れば-oopsie。

（ところで、NoSQLに興味があるなら、それは素晴らしいビデオです）

— 浸出
ソース