データベースの水平方向と垂直方向のスケーリングの違い
私は多くのNoSQLデータベースとSQLデータベースに出会いました。これらのデータベースの長所と短所を測定するためのさまざまなパラメータがあり、スケーラビリティもその1つです。これらのデータベースの水平方向と垂直方向のスケーリングの違いは何ですか？
水平方向の拡大縮小は、より多くのマシンを追加して拡大縮小することを意味しますに対して、垂直方向の拡大縮小は、既存のマシンにより多くの電力（CPU、RAM）を追加して拡大縮小します。
これを覚えておく簡単な方法は、サーバラック上のマシンを考えることです。我々はhorizontal方向にさらにマシンを追加し、vertical方向にさらにリソースを追加します。
データベースの世界では、水平スケーリングはデータの分割に基づいていることが多く、各ノードはデータの一部のみを含んでいます。垂直スケーリングでは、データは単一ノードに存在し、スケーリングはマルチコアを通じて行われます。そのマシンのCPUおよびRAMリソース。
水平方向の拡大縮小では、既存のプールにマシンを追加することで動的な拡大縮小が容易になることがよくあります。垂直方向の拡大縮小は1台のマシンの容量に制限されます。
水平スケーリングの良い例はCassandra、MongoDB、 Google Cloud Spanner ..そして垂直スケーリングの良い例はMySQL - Amazon RDS（MySQLのクラウド版）です。小型から大型の機械に切り替えることで、垂直方向に拡大縮小する簡単な方法を提供します。このプロセスにはしばしばダウンタイムが伴います。
GigaSpaces XAP 、 Coherence etc ..などのインメモリデータグリッドは、ディスクに限定されないという理由で、水平方向と垂直方向の両方のスケーリングに最適化されていることがよくあります。分割による水平方向の拡大縮小とマルチコアサポートによる垂直方向の拡大縮小.
あなたは私の以前の投稿でこの問題についてもっと読むことができます： スケールアウトとスケールアップ および NOSQLの代替物の背後にある共通の原則
簡単に言うと：
水平方向に拡大縮小する===>何千人もの手先が一緒に仕事をしてくれます。
垂直方向に拡大縮小する===>一つの大きなハルクがあなたのためにすべての仕事をします。
システムが以前よりも多くの要求を処理できるように、リソースを増やすスケーリングの必要性から始めましょう。
システムが遅くなり、現在の要求数を処理できないことに気付いたら、システムを拡張する必要があります。
これには2つの選択肢があります。現在使用しているサーバーのリソースを増やすか、RAM、CPU、GPU、その他のリソースを増やします。これは垂直スケーリングとして知られています。
垂直方向の拡大縮小は一般的にコストがかかります。つまり、単一サーバーで動作しているアプリケーションを拡張している場合、そのサーバーが停止してもシステムは停止します。また、垂直方向の拡大縮小でもスレッドの数は変わりません。垂直方向の拡大縮小では、処理が行われるときにしばらくシステムがダウンする必要があります。サーバー上のリソースを増やすには、再起動してシステムを停止する必要があります。
この問題に対する別の解決策は、システム内に存在するサーバーの数を増やすことです。このソリューションは、ハイテク業界で広く使用されています。これにより、最終的に各サーバーの1秒あたりの要求数が減少します。システムを拡張する必要がある場合は、別のサーバーを追加するだけで完了です。システムを再起動する必要はありません。各システムのスレッド数が減少すると、スループットが向上します。各アプリケーションサーバーに均等に要求を分離するには、Webサーバーへのリバースプロキシとして機能するロードバランサを追加する必要があります。このシステム全体を単一のクラスタと呼ぶことができます。あなたのシステムはこのようにもっと多くの量のクラスタを必要とするであろう大量のリクエストを含むかもしれません。
システムにスケーリングを導入するという全体的な概念を理解してください。
言及されていない追加のアーキテクチャがあります - 手動分割の複雑さなしに水平スケーリングを可能にするSQLベースのデータベースサービス。これらのサービスはバックグラウンドで分割を行うため、MongoDBやCouchDBなどのNoSQLエンジンを使用する場合と同様に、従来のSQLデータベースを実行してスケールアウトすることができます。私がよく知っている2つのサービスは EnterpriseDB PostgreSQL用と Xeround MySQL用です。私はXeroundによる詳細な post を見ました。これはなぜSQLデータベース上でのスケールアウトが難しいのか、そしてどうやってそれを変えるのかを説明しています。また、ウィキペディアの Cloud Databaseエントリー をチェックしてください。SQL対NoSQL、サービス対自営業、ベンダーのリスト、各組み合わせのスケーリング・オプションなど、Niceの説明があります。 ;）
水平方向に拡大縮小することは、マシンを追加することを意味しますが、クラスター内でマシンが等しいことも意味します。 MySQLは、レプリカを使用してデータの読み取りに関して水平方向に拡張できますが、サーバーのmem/diskの容量に達すると、サーバー間でデータの分割を開始する必要があります。これはますます複雑になります。データの変更率に追いつくには複製速度が遅すぎることが多いため、レプリカ間でデータの一貫性を保つことがしばしば問題になります。
Couchbaseはまた、NoSQL Horizontal Scalingという素晴らしいデータベースであり、多くの商用高可用性アプリケーションやゲームで使用されており、間違いなくこの分野で最高のパフォーマンスを示しています。それはクラスタ全体で自動的にデータを分割し、ノードを追加するのは簡単です、そしてあなたはコモディティハードウェア、より安い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システムに追加できます。
しかし、そのアプローチが（mongodb、CouchDB、またはIBM Cloudantのような）noSQLデータベースと異なるのは、データ分割が水平スケーリングの一部ではないということです。 noSQLデータベースでは、データは水平方向の拡大縮小中に断片化されます。
他のすべての答えはすでに完全に完成しているように見えますが、水平スケーリングを使用したリレーショナルデータベースの例として、 Google Cloud Spanner は見られませんでした。
多数のロードバランサーを追加すると、余分なオーバーヘッドと待ち時間が発生します。これは、nosqlデータベースを水平方向にスケールアウトする場合の欠点です。 RPCは堅牢ではないため推奨されないと人々が言う理由のようなものです。
実際のシステムでは、今日のシステムのマルチコアとクラウドの両方のコンピューティング機能を利用するために、sqlとnosqlの両方のデータベースを使用するべきです。
一方、OracleなどのSQLデータベースを使用している場合は、複雑なトランザクションクエリのパフォーマンスが高くなります。 NoSqlは分割によってビッグデータと水平方向のスケーラビリティに使用できます。