この記事では、アプリケーションの速度低下の基本的な理由について説明し、将来のプログラムのアーキテクチャを選択するためのサポートとなる参考図を提供します。
最新のアプリケーションの典型的なスキームを検討してください
アプリケーションの全体的な速度は、次の2つのカテゴリによって決まります。
1）アプリケーション内の各リンクの速度。
2）アプリケーションのリンク間の相互作用の速度。
最初のポイントによると、データベースだけが弱いリンクになります。常に別のサーバーを近くに置いて、アプリケーションサーバーとWebサーバーを並列化できるからです。
2番目のポイントを分析しましょう。 アプリケーションのさまざまな部分は、少なくともオペレーティングシステムのさまざまなプロセスで機能するため、オペレーティングシステム間での2つのリンクの相互作用のために、オペレーティングシステムはプロセスを少なくとも2回切り替える必要があります。 つまり、アプリケーションサーバーとデータベースが同じコンピューター上にある場合でも、時間のオーバーヘッドのために、1秒あたり8,000を超えるSQLクエリを当てにすることはできません。 ネットワークにはそれぞれさらに多くのプロセスが含まれ、リクエストの数はほぼ1000に減少します。通常、Webサーバー、Webクライアント、およびアプリケーションサーバー間のやり取りは、アプリケーションサーバーとデータベース間のやり取りよりもはるかに少なくなります。 ユーザーとWebサーバー間の唯一の接続は、特に衛星チャネルでの応答時間が比較的長いことを特徴としています。 そのため、Ajaxリクエストのクラウドを配置する価値もありません（これは、多くの場合、最初にAjaxアプリケーションが罪を犯したものです）。 しかし、データベースに戻ります。
通常の操作では、1秒あたり数千のリクエストで十分です。 問題は、あらゆる種類の大量のデータ処理から始まります。 ただし、この制限は、1Cシステムと同じくらい人気のあるオブジェクトアドインを使用する場合に特に重要になります。 OOPを使用する特徴は、データベースへの小さな呼び出しを大量に生成することです。 そして今、この状況から抜け出す2つの方法があります：
a）データベース内にアプリケーションロジックを配置します。
b）アプリケーションサーバー内のデータをキャッシュします。
オプション「a」を選択すると、速度を約2桁上げることができます。1秒あたり最大100,000リクエストです。 不便なことに、この場合、組み込みのデータベース言語でロジックを実装する必要があります。 C＃またはJavaプロシージャを持つバリアントは適切ではありません。 このような手順は仮想マシンで実行されますが、これは実際には別のプロセスであり、実際には外部アプリケーションサーバーとの対話時間に違いはありません。 また、組み込みのプログラミング言語はアプリケーションロジックの実装にはあまり適していませんが、多くの銀行はこのアプローチを使用しています。 基本的に、この場合、もちろん、Oracleは組み込みのPL / SQLとともに使用されます。
さらにオプション「b」を検討してください。 「指で」の場合、このオプションを使用したロジックの実装は次のとおりです。メモリ内の配列に必要なすべてのデータを大きなブロックでロードします。 処理します。 処理結果をデータベースにアップロードします。 行はデータベースから非常に高速にロードされます（1秒あたり約100万個）。 データも非常に迅速に処理されます。 問題は、データベースにデータをロードしていることです。 ここでも、毎秒1000行があります。 非標準の手法では、1秒あたり最大100,000行をロードできます。 非常に大企業の場合、この方法は適切ではありません。 データボリュームは、RAMに収まらないほどです。 同時に、この方法は1C最適化に最も適しています。RAMでも線形検索が非常に遅く、インデックスを独自に実装する必要があることを忘れないでください。
1秒あたり100,000行という境界はどこから来たのでしょうか。データベースを使用しても、これを克服することはできません。 答えは簡単です。これは、データベースでインデックスを構築するおおよその平均速度です。 はい、最新のプロセッサは0.5秒で1億行を整理できますが、Oracleは約20秒かけて100万要素のインデックスを作成します。 これは、アプリケーションの開発時に留意する必要があります。 また、これらの1秒あたり10万行でさえ、組み込み言語の手順を使用するか、ファイルからデータを大量にロードすることによってのみ達成できます。 SQLコマンドを使用すると、1秒あたり最大10,000件のクエリを取得できます。 クラスタリングによって全体的な速度を上げることができますが、応答時間を増やすことは非常に困難です。
たとえば、1か月または1年の締め切りなど、大量のデータ処理について話していることを思い出してください。 日常モードでは、通常の速度で十分です。
次に、見通しについて話しましょう。 今、コンピューター技術の真の革命が静かに、そして静かに起こっています-64ビットへの移行。 また、これは4ギガバイト以上のメモリをインストールするだけの機会ではありません。そのような機会は、高度なプロセッサモードを使用することにより、Pentium IIでもまだありました。 64ビット。これは、プロセッサのアドレス空間に任意の量のデータを含める機能です。 本質的には従来のハードドライブよりもRAMに近いソリッドステートドライブの開発とともに、これは将来のデータ処理システムの外観を劇的に変えます。 どうやら、近い将来、アプリケーションサーバーとデータベースの統合が見られるようです。 最初のステップ：OracleはJavaテクノロジーを購入し、MicrosoftはすでにC＃にSQLクエリを組み込んでいます。 つまり DBMS内にロジックを貼り付けようとします。 このアプローチの欠点は、OOPの原理に基づくロジックがリレーショナルデータモデルにあまり適合しないことです。ただし、データベースへのクエリの数は桁違いに増加します。 ただし、このアプローチを使用する大規模銀行は、新しい開発技術にまったく切り替えない余裕があります。 したがって、SberbankのIT部門の数は、総従業員数に匹敵します。 製造業の企業では、プログラマーははるかに小さく、奇妙なことに、ここでの新しい技術の需要が高まっています。
別のアプローチは反対です-アプリケーションサーバー内にデータベースを埋め込みます。 既存のテクノロジーのうち、最も近いのはNoSQLデータベースです。 このアプローチにより、最新のプロセッサのすべてのパワーを使用できます。 アプリケーションのパフォーマンスはすぐに1,000倍、100万倍上昇します。 しかし、このアプローチでは、OOPが使用されます。その主な機能は、データベースのランダムな領域にすばやくアクセスする必要があることです。 これは、データベースファイルをアプリケーションサーバーのアドレス空間にマッピングすることにより、最も効率的に実装できます。 C＃、1C、Javaなどの一般的なプログラミング言語には、メモリを直接操作するためのツールがないため、こうした作業を有効にするには、安全でないコードの追加レイヤーを作成する必要があることに注意してください。
必要なRAMの量を見積もります。 マルチメディアテクノロジーの普及により、情報が占有するメモリの量が少し間違った考え方になります。 今では予想外のように聞こえるかもしれませんが、1メガバイトはそれ自体で大量の戦争と平和に適合することができます。 これは、本のページ数、ワーカーのテキストの行数、および行の文字数を掛けることで簡単に確認できます。 約100万文字を取得します。 タッチタイピングのスキルを持たないすべてのユーザーが毎年トルストイのいくつかのボリュームを「ドライブ」するわけではありません。 店内の製品を常にスキャンしているセールスウーマンでさえ、年間約10メガバイトの情報しか生成しません。 オフィスユーザーの場合、1人あたり年間1メガバイトを安全に配置できます。 はい、Wordファイル、ドキュメント、写真、音楽、映画のスキャンされたコピーがありますが、これらの種類の情報はすべて「そのまま」データベースにあり、処理されません（フルテキストインデックス作成を除く）。したがって、これらもメインメモリにあります。必要ありません。
結論 OOPは、30年以上にわたってその存在と効果を証明してきましたが、完全に使用することはできません。 リレーショナルデータベースとの互換性が不十分です。 このトピックには、OOPの実装の最適な深さを選択し、将来のアプリケーションの可能性の境界を知ることができる近似図が含まれています。