postgresqlのロードバランシングと水平スケーリングについて混乱
私が間違っている場合は修正してください。ただし、マシンを追加したり、複数のサーバー間で負荷を分散したりすることで、より多くのリクエストと負荷を処理できると思います。では、サーバーを追加した場合、どのようにデータベースを分散すればよいですか？複数のサーバーでユーザーレコードを保持するために1つのデータベースを作成しますか？または、データベースも分割しますか？データベースの整合性はどうですか？同期する方法は？それとも私は何をしますか？私は初心者で、本当に混乱していますが、学びたいと思っています。私のプロジェクトではpostgresを使用し、開始する前にいくつかの基本的なことを知りたいと思います。 2つの小さなec2インスタンスを使用することを考えていました。しかし、私はデータベースについて混乱しました。データベースを作成するにはどうすればよいですか。このためにシャーディングを行う必要がありますか？ postgresによる水平スケーリングの最良のアプローチは何でしょうか。ご説明いただければ幸いです。ありがとうございました！
編集：
複数のマシンを使用して負荷を分散し、データベースを管理するにはどうすればよいですか？
ユーザーが動画をアップロードできるアプリを持っています。ElasticTranscoderを使用してmp4に変換します。ユーザー約10k。では、複数のマシンを使用して負荷を分散し、データベースを管理するにはどうすればよいですか？私がやりたいのは、パフォーマンスのための負荷分散です。そして、私は多くの投稿を読んで、より多くのマシンを追加することでそれを活用できると述べました。だから私は水平スケーリングについてです。しかし、水平方向のスケーリングは怖いので、データベースの負荷を分散して管理するにはどうすればよいですか？
データベースの水平スケーリングの最初のルールは、それを回避することです。すべてのコストで。購入できる可能性のあるサーバーがデータを処理できない場合にのみ、それを検討する必要があります。そして今日、膨大な量のデータを処理できるサーバーがあります。
データベースの水平スケーリングにより、次のことが可能になります。
少なくとも一桁複雑なシステム：
- シャーディングの最も単純なケースでも、より多くのサーバーを管理し、負荷を均等に分散し、スキーマの更新とすべてのノードの共有テーブルを管理し、フロントエンドを適切なサーバーに接続する必要があります。
- 代わりにレプリケーションを使用する場合は、レプリケーションの遅延、スレーブでのクエリの失敗、マスターとスレーブ間でのデータの安全な転送、スレーブの同期外れ、マスターに対して更新を実行する必要があるなどを管理する必要があります。
少なくとも1桁以上のバグ、上記の合併症の直接的な結果。
バグのデバッグが少なくとも1桁難しい、上記の複雑さの直接的な影響。
ハードウェア障害の確率が少なくとも2倍-サーバーが少なくとも2つある場合、それらのいずれかが失敗する確率は、特定の1つの障害よりも高くなります。
バッテリーバックアップのドライブコントローラーやSSDなどの優れたストレージオプション、データのパーティション分割、WALファイルのスマートな配置などは、別の低速サーバーを購入するよりもはるかに重要であるため、おそらく同じ価格で単一サーバーよりもパフォーマンスが1桁ほど悪い;データベースは主にストレージによってボトルネックになっていることに注意してください。
データベースに接続しているクライアントを水平方向にスケーリングできます（フロントエンドはほとんどがプロセッサによってボトルネックになっているため、これは理にかなっています）。フェイルオーバー（いわゆるウォームスタンバイサーバー）にはレプリケーションを使用する必要があります。同じデータベース内でデータを分割できます（これにより、シャーディングの利点のほとんどは、はるかに少ない欠点です）。 Google、Twitter、Facebookに匹敵するサイズになるまでは、水平スケーリングを行わないでください。したがって、2つの小さなEC2インスタンスはありません。