「スケールアウト」ではなく「スケールアップ」する必要があるシステムのタイプは何ですか？
多くの小さなサーバーに分割して「スケールアウト」するのではなく、「スケールアップ」（より強力で高価なサーバーに）する必要のあるシステムがあるかどうか、私は長い間疑問に思っていました。
そのようなシステムは存在しますか？存在する場合、システムをスケールアウトするのではなく、スケールアップする必要が生じる傾向があるものは特にありますか？ （たとえば、ACIDに準拠したデータベーストランザクション、またはその他の強力なデータ整合性要件がこのニーズを生み出している可能性があります。）
スケールアップはスケールアウトよりもハードウェアコストがはるかに高くなるように思われるため、可能であれば避けたいと思われるかもしれませんが、常に回避できるかどうかはわかりません。
では、スケールアウトできず、代わりにスケールアップする必要があるシステムはありますか？これを引き起こす原因は何ですか？また、そのようなシステムをどのように特定しますか？ （それらは一般に、それらをより簡単に識別できるようにする可能性のあるいくつかの共通の特性を共有していますか？）
私は主に zero水平スケーリングの可能性 を持つアプリケーションを使用しています。 Linuxで実行されている場合でも、アプリケーション、データ構造、およびI/O要件により、ユーザーのワークロードの増加に対応するために、徐々に大規模なシステムに「スケールアップ」する必要があります。
多くのレガシー基幹業務およびトランザクションアプリケーションには、これらのタイプの制約があります。業界がクラウドソリューションに焦点を当てており、DevOps主導のWebスケールアーキテクチャがコンピューティングの世界のかなりの割合を無視していることを強調する理由の1つです。
残念ながら、私が説明するスケールアップシステムは本当にセクシーではないので、業界はその価値を無視したり、大規模で重要なシステムに対処するために必要なスキルを軽視したりする傾向があります（例牛とペット）。
開発者の観点から言えば、そこにあるほとんどすべての従来の主流データベースエンジンはスケールアップしかできず、スケールアウトは非常に後から考えたものです。
近年、より高いスケーラビリティと高可用性システムの必要性に伴い、既存のデータベースをスケールアウトするための取り組みが行われています。しかし、設計はレガシーコードによって妨げられているため、設計の基本ではなく、ボルトで固定されているだけです。よく知られているデータベースエンジンのほとんどをスケーリングしようとすると、これが発生します。スレーブサーバーの追加はセットアップが非常に難しい場合があり、重大な制限があり、データベーステーブルの再ジグが必要になる場合があります。
たとえば、それらのほとんどは、マルチマスター設計ではなくマスター/（マルチ）スレーブです。つまり、サーバー全体がそこにあり、クエリを処理できない場合があります。いくつかありますが、制限があります...例：マルチスレーブ設計のみを読み取ります。したがって、書き込みを行う1つのサーバーがあり、他のすべてのサーバーが読み取り専用データを提供する場合があります。これらのシステムをセットアップするとき、それは必ずしも単純なプロセスではなく、うまく機能させるのが難しいことに気付くでしょう。多くの場合、追加のボルトを非常に感じます。
一方で、最初から並行性とマルチマスター設計で開発されている新しいデータベースエンジンがいくつかあります。 [〜＃〜] nosql [〜＃〜] および NewSQL は新しいデザインクラスです。
したがって、従来のSQLサーバーからパフォーマンスを向上させる最善の方法は、スケールアップすることです。 NOSQLとNewSQLを使用すると、スケールアップとスケールアウトの両方が可能になります。
従来のRDBMSシステムが緊密に結合されている理由は、すべてが同じデータの一貫したビューを必要とするためです。異なるクライアントからの同じデータへの更新を受け入れる複数のサーバーがある場合、どれを信頼しますか？ある種のロックメカニズムを通じてデータの一貫性を確保しようとする方法では、他のサーバーからの協力が必要であり、クライアントから読み取られたデータが古くなる可能性があるため、パフォーマンスが低下したり、データ品質に影響を及ぼしたりします。また、サーバーは、同じレコードに書き込むときに、どのデータが最新であるかをサーバー間で決定する必要があります。ご覧のとおり、データへのアクセスがまだ非常に高速なプロセスやスレッド間だけでなく、サーバー全体にワークロードが分散しているため、複雑な問題がさらに複雑になっています。
私の意見では、スケールアップ/アウトの境界は、ワークフローをどの程度並列化できるか、および並列スレッドが互いにどの程度緊密に調整する必要があるかによって決まります。
シングルスレッド
何らかの理由で、このワークフローは単一のスレッドでのみ機能します。
1つのスレッドは、1つのシステムがスケールupを意味し、速度を上げます。
密結合並列処理
これはマルチスレッドシステムであり、スレッドを互いに緊密に結合する必要があります。おそらく、プロセス間通信は非常に高速である必要があります。または、すべてを単一のメモリマネージャで管理する必要があります。ほとんどのRDBMSシステムは、この種の並列コンピューティングです。
ほとんどの場合、これらのシステムは、outよりもupのスケールが優れているシステムです。 ）例外はありますが。たとえば、 シングルシステムイメージ スタイルのクラスター、単一のメモリスペース、スレッド間の待ち時間が長いワークフローで機能すると、スケールアウトが容易になる場合があります。しかし、このようなSSIシステムは操作が非常に難しいため、ほとんどのエンジニアは大きな箱を作るだけです。
疎結合並列処理
これはマルチスレッド/プロセスシステムであり、スレッドは相互に高い待ち時間で問題ありません。または、お互いに話す必要はまったくありません。スケールアウトされたWebサービスとレンダーファームは、この種のシステムの典型的な例です。このようなシステムは、密結合の並列処理よりもはるかに簡単に大きくすることができます。そのため、このスタイルのシステムには多くの興奮があります。
これは、スケールoutがはるかに簡単なスタイルです。