2

私は最近、ほぼ 200 のテーブルを扱う大学向けにかなり複雑なデータベース アプリケーションを構築しました。一部のテーブル (出版物など) は、30 以上のフィールドを保持し、10 個の 1 対 1 の FK リレーションと最大 2 または 3 個の多対多の FK リレーションを格納できます (相互参照参照テーブルを使用)。全体を通して整数 ID を使用しており、すべての段階で正規化が重要でした。AJAX は最小限であり、ほとんどのページは標準の CRUD フォーム/プロセスです。

Symfony 1.4 と Doctrine ORM 1.2、MySQL、PHP を使用しました。

(MVC と ORM を使用することで) 開発時間と保守の容易さのメリットは非常に大きいのですが、スピードに関しては問題がありました。つまり、一度に複数のユーザーがログインしてアクティブになっていると、アプリケーションの速度が大幅に低下します (レコードの保存または編集に最大 20 秒かかります)。

現在、システム管理者と話し合っていますが、彼らは十分な権限を持っているべきだと言っています。6 人以上のユーザーがアクティビティに従事している場合、メモリ使用量が少ない (ブリードなし) 間、仮想サーバー環境で 4 つの CPU をキューに入れることになります。

もちろん、mySQL アプリケーションをマルチスレッド化し (これが役立つ場合)、コードを改良し (ただし、その多くは MVC によって生成されます)、キャッシュの使用法を改良することを検討しています (これはより良いものになる可能性がありますが、大部分は使用される画面はユーザーログイン固有で動的です); APC をインストールし、メモリを追加し、データベースをデフラグし、すべてのレコードセットの設定を解除してみました (ただし、これは ORM 内で自動化されていることは理解しています)、手動のガベージ リサイクルを開始しています...

しかし、私が尋ねているのは、mySQL、PHP、および Symfony MVC が、そもそもこのサイズのアプリケーションを開発するための適切な選択ではなかったかどうかということです。もしそうなら、人々は通常、この種のサイズ/複雑さの Web ベースのデータベース インターフェイス アプリケーションに何を使用/推奨しますか?

4

2 に答える 2

3

Symfony や Doctrine の経験はありません。ただし、これらのプロジェクトに基づいて構築されたサイトよりも大きなサイトが確かにあります。たとえば、DailyMotion は両方を使用しており、少数の同時ユーザーよりもはるかに多くのサービスを提供しています。

同様に、Wikipedia のような大規模なサイトでは PHP と MySQL が使用されているため、スケーラビリティは問題になりません。(ところで、MySQL はデフォルトでマルチスレッド化されている必要があります。つまり、接続ごとに 1 つのスレッドです。)

もちろん、妥当なパフォーマンスは相対的なものです。クローゼットに置かれたベージュ色の箱から 200 件の同時リクエストを処理するサイトを実行しようとしている場合、独自のデータ センターを持つフォーチュン 500 企業よりもはるかに多くのコードを最適化する必要があるかもしれません。

当然行うべきことは、実際にアプリケーションのプロファイルを作成し、ボトルネックがどこにあるかを確認することです。MySQL クエリのプロファイリングは非常に簡単で、XdebugなどのさまざまなPHP プロファイリング ツールもあります。そこから、フレームワーク、ORM を切り替える (または ORM を完全に捨てる)、データベースを切り替えるか、一部のコードをリファクタリングするか、処理能力を高めるだけに投資するかを判断できます。

于 2012-07-02T14:46:24.473 に答える
1

複雑なデータベース操作を高速化する最良の方法は、それらを呼び出さないことです:)。

したがって、アプリケーションのどの部分をキャッシュできるかを分析します。
Symfonyには、かなりきめ細かく使用できる非常に優れたキャッシングシステム（symfony2ではさらに優れています）があります。

データベース側では、別の方法として、ビューまたはネストされたセットを使用して集約データを格納することもできます。
これが適切な部品を見つけてください。

于 2012-07-03T07:07:13.500 に答える