データベースの水平方向と垂直方向のスケーリングの違い[終了]

私は多くのNoSQLデータベースとSQLデータベースに出くわしました。これらのデータベースの長所と短所を測定するためのさまざまなパラメーターがあり、スケーラビリティーはその1つです。これらのデータベースの水平スケーリングと垂直スケーリングの違いは何ですか？

水平スケーリングとは、リソースのプールにマシンを追加してスケーリングすることを意味し、垂直スケーリングとは、既存のマシンにさらにパワー（CPU、RAM）を追加してスケーリングすることを意味します。

これを覚える簡単な方法は、サーバーラック上のマシンについて考えることです。水平方向にマシンを追加し、垂直方向にマシンにリソースを追加します。

データベースの世界では、水平スケーリングは多くの場合、データの分割に基づいています。つまり、各ノードにはデータの一部しか含まれていません。垂直スケーリングでは、データは単一のノードにあり、スケーリングはマルチコアを介して行われます。そのマシンのCPUおよびRAMリソース。

多くの場合、水平スケーリングを使用すると、既存のプールにマシンを追加することで動的にスケーリングすることが容易になります。垂直スケーリングは、多くの場合1台のマシンの容量に制限されます。その容量を超えるスケーリングは、ダウンタイムを伴うことが多く、上限があります。

水平スケーリングの良い例は、Cassandra、MongoDB、Google Cloud Spannerなどです。垂直スケーリングの良い例は、MySQL-Amazon RDS（MySQLのクラウドバージョン）です。小型から大型のマシンに切り替えることで、垂直方向にスケーリングする簡単な方法を提供します。このプロセスはしばしばダウンタイムを伴います。

GigaSpaces XAPやCoherenceなどのインメモリデータグリッドは、単にディスクにバインドされていないため、水平方向と垂直方向の両方のスケーリングに最適化されることがよくあります。分割による水平スケーリングとマルチコアサポートによる垂直スケーリング。

この問題の詳細については、以前の投稿： スケールアウトとスケールアップ、およびNOSQLの代替の背後にある一般原則を参照してください。

水平方向のスケーリング ===>数千の手先が一緒に作業を行います。

垂直方向のスケーリング ===> 1つの大きなハルクがすべての作業を行います。

システムが以前よりも多くの要求を処理できるように、リソースを増やすスケーリングの必要性から始めましょう。

システムが遅くなり、現在のリクエスト数を処理できないことに気付いた場合は、システムをスケーリングする必要があります。

これには2つのオプションがあります。現在使用しているサーバーのリソースを増やす、つまり、RAM、CPU、GPU、およびその他のリソースの量を増やす。これは垂直スケーリングと呼ばれます。

垂直スケーリングは一般にコストがかかります。システムフォールトトレラントにはなりません。つまり、単一のサーバーで実行されているアプリケーションをスケーリングしている場合、そのサーバーがダウンすると、システムがダウンします。また、垂直スケーリングでもスレッドの量は変わりません。垂直スケーリングでは、プロセスが実行されている間、システムを一時的に停止する必要がある場合があります。サーバー上のリソースを増やすには、再起動してシステムを停止する必要があります。

この問題の別の解決策は、システムに存在するサーバーの数を増やすことです。このソリューションは、テクノロジー業界で非常に使用されています。これにより、各サーバーの1秒あたりの要求レートが最終的に減少します。システムを拡張する必要がある場合は、別のサーバーを追加するだけで完了です。システムを再起動する必要はありません。各システムのスレッド数が減少すると、スループットが高くなります。各アプリケーションサーバーと同様にリクエストを分離するには、Webサーバーへのリバースプロキシとして機能するロードバランサーを追加する必要があります。このシステム全体を単一のクラスターと呼ぶことができます。システムには、このようなより多くのクラスターを必要とする多数のリクエストが含まれている場合があります。

システムにスケーリングを導入するという全体的な概念を理解していただければ幸いです。

言及されなかった追加のアーキテクチャがあります。手動のシャーディングの複雑さなしに水平スケーリングを可能にするSQLベースのデータベースサービスです。これらのサービスはバックグラウンドでシャーディングを行うため、MongoDBやCouchDBなどのNoSQLエンジンを使用する場合と同じように、従来のSQLデータベースを実行してスケールアウトできます。私がよく知っている2つのサービスは、EnterpriseDB for PostgreSQLとXeround for MySQLです。Xeroundによる詳細な投稿を見たところ、SQLデータベースのスケールアウトが難しい理由とそれをどのように異なる方法で行うかが説明されました。これはベンダーの投稿なので、これを塩の粒で扱います。ウィキペディアのクラウドデータベースのエントリも確認してください、SQLとNoSQLの比較、サービスとセルフホストの比較、ベンダーのリスト、各組み合わせのスケーリングオプションがあります。;）

はい、水平スケーリングは、マシンを追加することを意味しますが、マシンがクラスター内で等しいことも意味します。MySQLはレプリカを使用することにより、データの読み取りに関して水平方向にスケーリングできますが、サーバーのメモリ/ディスクの容量に達したら、サーバー間でデータのシャーディングを開始する必要があります。これはますます複雑になります。多くの場合、複製速度がデータ変更速度に追いつくには遅すぎるため、レプリカ間でデータの整合性を保つことは問題です。

Couchbaseはまた、多くの商用高可用性アプリケーションやゲームで使用されている素晴らしいNoSQL水平スケーリングデータベースであり、間違いなくこのカテゴリで最高のパフォーマンスを発揮します。クラスター全体でデータを自動的に分割し、ノードを追加するのは簡単です。また、市販のハードウェア、安価なvmインスタンスを使用できます（たとえば、AWSでHigh Mem、High Diskマシンの代わりにLargeを使用します）。Membase（Memcached）から構築されていますが、永続性が追加されています。また、Couchbaseの場合、すべてのノードが読み取りと書き込みを行うことができ、クラスター内で同等であり、フェイルオーバーレプリケーションのみ（mySQLのようにすべてのサーバー間での完全なデータセットレプリケーションではありません）。

パフォーマンスに関しては、優れたシスコのベンチマークを確認できます。http：//blog.couchbase.com/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server

Couchbase Architectureに関するすばらしいブログ投稿は次のとおりです。http：//horicky.blogspot.com/2012/07/couchbase-architecture.html

従来のリレーショナルデータベースは、クライアント/サーバーデータベースシステムとして設計されました。水平方向にスケーリングできますが、そのためのプロセスは複雑になり、エラーが発生しやすくなります。NuoDBのようなNewSQLデータベースは、従来のRDBMSのSQL / ACIDプロパティを維持しながら水平方向にスケールアウトするように設計された、メモリ中心の分散データベースシステムです。

NuoDBの詳細については、テクニカルホワイトペーパーをご覧ください。

Oracle、db2などのSQLデータベースは、共有ディスククラスターによる水平スケーリングもサポートしています。たとえば、Oracle RAC、IBM DB2 purescale、Sybase ASE Cluster Edition。新しいノードをOracle RACシステムまたはDB2 purescaleシステムに追加して、水平スケーリングを実現できます。

ただし、アプローチは、noSQLデータベース（mongodb、CouchDB、IBM Cloudantなど）とは異なり、データシャーディングは水平スケーリングの一部ではありません。noSQLデータベースでは、データは水平スケーリング中に断片化されます。

会社があり、労働者は1人しかいませんが、そのときに新しいプロジェクトを1つ獲得しました。これは、新しい候補者を採用するものです。これは水平スケーリングです。新しい候補は新しいマシンで、プロジェクトは新しいトラフィック/ APIへの呼び出しです。

IIT / NITの担当者が1つのプロジェクトとして、api / trafficへのすべてのリクエストを処理する場合。APIへのリクエストがいつでも発生した場合は、彼を解雇し、彼を高IQ NIT / IITガイに置き換えます-これは垂直スケーリングです。

多くのロードバランサーを追加すると、余分なオーバーヘッドとレイテンシが発生します。これは、nosqlデータベースで水平方向にスケールアウトする場合の欠点です。RPCは堅牢ではないため、推奨されていないと人々が言う理由に似ています。

実際のシステムでは、今日のシステムのマルチコア機能とクラウドコンピューティング機能の両方を利用するために、sqlデータベースとnosqlデータベースの両方を使用する必要があると思います。

一方、oracleなどのSQLデータベースを使用している場合は、複雑なトランザクションクエリのパフォーマンスが高くなります。NoSqlは、シャーディングによるビッグデータと水平方向のスケーラビリティに使用できます。

受け入れられた答えは、水平方向と垂直方向のスケーリングの基本的な定義にスポットを当てています。しかし、データベースの水平スケーリングはCassandra、MongoDBなどでのみ可能であるという一般的な考えとは異なり、水平スケーリングは従来のRDMSでも非常に可能です。サードパーティのソリューションを使用せずにそれも。

私は多くの企業、特にこれを行うSaaSベースの企業を知っています。これは、単純なアプリケーションロジックを使用して行われます。基本的には、ユーザーのセットを取得して、複数のDBサーバーに分割します。したがって、たとえば、通常、クライアント、DBサーバー/接続文字列などを格納する「メタ」データベース/テーブルと、クライアント/サーバーマッピングを格納するテーブルがあります。

次に、各クライアントからの要求を、それらがマッピングされているDBサーバーに送信するだけです。

これは、これが水平分割に似ていて、「真の」水平スケーリングではないと言う人もいるかもしれませんが、それらはいくつかの点で正しいでしょう。しかし、最終的には、複数のDBサーバーにDBをスケーリングしたことになります。

水平スケーリングに対する2つのアプローチの唯一の違いは、1つのアプローチ（MongoDBなど）でスケーリングがDBソフトウェア自体によって行われることです。その意味では、スケーリングを「購入」しています。他のアプローチ（RDBMS水平スケーリングの場合）では、スケーリングはアプリケーションコード/ロジックによって構築されます。