データベースがボトルネックになっているかどうか。高拡張性の話
私はEBayのスケーラビリティについて話している高スケーラビリティのWebサイトで興味深い記事を見つけました。
"（Ebay戦略）...データベースがボトルネックであるため、データベースからワークアウトをアプリケーションに移動します。Ebayはこれを極端に実行します。他のアーキテクチャでは、キャッシュとファイルシステムを使用していますが、eBayは多くのことを実行しますアプリケーションでの従来のデータベース操作の例（結合など）。」
そして、上記と同じ記事にあるため、間違いはありません。
「CPUを集中的に使用する作業をデータベースレイヤーからアプリケーションアプリケーションレイヤーに移動します。参照整合性、結合、並べ替えはアプリケーションレイヤーで行われます。理由：アプリサーバーは安価であり、データベースはボトルネックです。」
これについて何か説明はありますか？上記が当てはまる場合は、データベースを使用してデータを取得し、プログラミングロジックで他のすべての操作を実行する必要があります。
私はいつも反対のことを言われました：「データベースはデータと複雑な選択の操作のために最適化されているので、それらを使用してください」。
洞察はありますか？
「測定。推測しないでください」。
Ebayのボトルネックが私たちのボトルネックと同じであるとは想定できません。私が取り組んでいる特定のアプリケーションでは、ボトルネックが存在する場合、それがデータベースになることはめったにありません（ある場合、それはクエリの最適化が不十分なためです）。これがわかっているのは、パフォーマンスの低いインスタンスを確認し、アプリケーションの通常のパフォーマンスのパフォーマンスをプロファイルしたためです。
はい、リレーショナルデータベースは、水平方向のスケーラビリティに関してボトルネックになっています。ほとんどの場合、RDBMSサーバーをスケーリングするには、より強力なマシンが必要であり、これにより制限が生じます。これは、ACIDトランザクションをトレードオフすることにより、NoSQLデータベースがRDBMSの代替として登場した主な理由の1つです。アプリケーションロジックをストアドプロシージャの形式でデータベースに配置すると、ボトルネックがさらに大きくなります。
適切に記述されたアプリケーションサーバーを複数のマシンサーバーにデプロイできるため、アプリケーション層で処理能力をシフトすることにより、アプリケーション全体をより簡単にスケールアウトできます。これに代わる方法は、上記のNoSQLデータストアを使用してスケーラビリティを実現することです。 NoSQLデータストアは、複数のノードに簡単にデプロイすることもできます。
質問で指摘したように、これはスケーラビリティの高い話でのみ意味があることに注意してください。ほとんどの場合、データベースを適切に使用すると、データベースは実際のボトルネックを表すものではなく、何十年にもわたって実行してきたように非常にうまく機能します。
メモリは高速で耐久性がありませんが、ドライブは低速で耐久性があります。データベースからデータを取り出してメモリにポップすると、そのアクセスは常に非常に速くなり、サーバーに障害が発生するとデータが失われます。
データベースは、ほとんどのアプリケーションに最適です。ほんの一部のアプリケーションだけがgoogle、Twitterなどのスケールを備えており、それらの企業がどのように課題を克服したかについては常に魅力的ですが、Word goからソリューションを実装しようとするのは初心でしょう。