2

djangoを使ったオンライン学校日記アプリを開発しています。プロトタイプの準備ができており、プロジェクトは来年、約 500 人の学生を対象に実施される予定です。最初は sqlite を使用し、最初の実装ではこれで十分に機能することを期待していました。データ テーブルは、学校の 1 日の詳細 (期間、クラス、教師、教室など) を取得するためのものであり、多くのテーブルが使用され、データベースへのアクセスにはかなり高速な PC で 67 ミリ秒かかります。教室への小さな変更. テーブルの結合が不要になるように、学期ごとに各学生の時間割を抽出することを考えました. このデータを 1 人の学生のテキスト ファイルに入れました. ファイルのサイズは 100K です. 読むのにかかる時間このデータを処理し、1 日のタイムテーブルで約 8 ミリ秒処理します。ログイン時にデータをプリロードしてセッションに保存すると、ログイン時に 7 ミリ秒、クエリごとに 2 ミリ秒かかります。500 人の学生の場合、このアプローチを使用した場合の Web サーバーへの影響と、他にどのようなオプションがありますか (たとえば、セッションではなく、一種のメモリ キャッシュに学生のテキスト ファイルを配置するなど)。大量のデータ入力はありません。 、生徒はメモを追加し、教師も同様に、時間割のステータスをチェックし、その日または週にどのようなイベントがあるかを調べます。

4

4 に答える 4

4

予想される応答時間と、1分あたりの予想されるリクエスト数はどれくらいですか。リクエストのデータベースアクセス(遅い部分である可能性が高い)の20分の1秒は、私には問題のようには思えません。SQLiteは、このようなほとんどの読み取り状況で正常に動作するはずです。ですから、パフォーマンスの問題さえあるとは思いません。

より高速な応答が必要な場合は、次のことを検討できます。

  1. まず、インデックスをチェックし、個々の取得をプロファイリングしてパフォーマンスのボトルネックを探すことにより、最高の応答時間を確保します。
  2. システムの静的部分を事前に計算し、HTMLを保存します。HTMLをデータベースに戻すことも、ディスクファイルとして保存することもできます。
  3. データベースをバッキングストアとしてのみ使用し(サーバーがダウンしたときにシステムの状態を保持するため)、システムの起動時にすべてをメモリ内の構造に読み込みます。これにより、データへのディスクアクセスが排除されますが、物理サーバーは1つに制限されます。
于 2012-10-31T02:03:16.360 に答える
3

これは時期尚早の最適化のように思えます。67ms は、私たち人間が遅延があったことを観察できる ~50ms よりもほとんど長くありません。

SQLite によるデータの表現は、テキスト形式よりも効率的であり、解析する必要があるテキスト ファイルとは異なり、オペレーティング システムは、RAM で実際に使用しているデータベースの部分だけを効率的にキャッシュできます。

最大 50 MB の RAM をロックダウンして、すべての学生のデータの解析済み表現をキャッシュできますが、その RAM を OS ディスク キャッシュなどの別の用途に使用すると、パフォーマンスが向上する可能性があります。

于 2012-10-31T02:04:21.253 に答える
1

SQLiteの代わりにMySQLまたはPostgreSQLを使用することを提案する他の回答のいくつかに同意します。本番データベースとして使用するようには設計されていません。モバイル アプリやデスクトップ アプリケーションなどの 1 ユーザー アプリケーションのデータを格納するのには最適ですが、サーバー アプリケーションではすぐに不足します。Django を使用すると、他の完全保証データベース バックエンドに簡単に切り替えることができます。

select_relatedこれらのいずれかに切り替えた場合、特におよびを使用して必要なすべての結合を行う場合は、実際にはパフォーマンスの問題は発生しないはずですprefetch_related

「ほとんどのデータが静的である」ことを考慮して、さらにパフォーマンスが必要な場合は、実際には Django サイトを静的サイト (html ファイルのコレクション) に変換し、nginx またはそれに類似したものを使用してそれらを提供することをお勧めします。私が考えることができる最も簡単な方法は、必要なすべての url-config をループする cron ジョブを作成し、Django からページを要求して、それを html ファイルとして保存することです。その方向に進みたい場合は、Python の静的サイト ジェネレーターであるHydePelicanも参照してください。

このアプローチは確かにキャッシュ システムよりもはるかに高速に動作しますが、サイトの動的コンポーネントが失われます。それらが必要な場合は、キャッシングが最善かつ最速のソリューションのようです。

于 2012-10-31T02:13:06.193 に答える
0

本番データベースには MySQL または PostgreSQL を使用する必要があります。sqlite3 は良い考えではありません。

また、ログイン時にデータを事前にロードすることも避ける必要があります。レコードは事前に挿入できるため、django 管理コマンドを作成し、選択したデータベースへのインポートを事前に実行し、ユーザーがログインしたときに、ユーザーがアクセスして表示/編集できるようにモデルを設計します。関連データ (アプリケーションが稼働する前に事前に挿入されます)。ログイン時のデータ操作のハードコーディングは、アプリケーション設計の観点からはまったく適切ではありません。

https://docs.djangoproject.com/en/dev/howto/custom-management-commands/

django モデルを設計し、カスタム管理コマンドを使用してアプリケーションがライブになる前にレコードを挿入する利点は、django orm を使用してユーザーとそのレコードの間に適切な関係を作成できることを意味します。

上記で必要なものの説明に基づいて、このアプリケーションを作成しているアプローチを再検討する必要があると思います。

500 人の生徒がいるので、キャッシングについて話す必要さえありません。応答速度が必要な場合は、次の問題を優先して対処する必要があります。

  1. 生産品質データベースを使用する
  2. アプリケーションのユース ケースを正しく設計し、アプリケーション モデルを正しく設計する
  3. 必要なデータを本番データベースに事前にロードします
  4. フロントエンドの最適化が最優先 (css/js 圧縮など)
  5. djangoデバッグツールバーを使用して、SQLのいずれかが遅いかどうかを判断し、特にそれらを最適化します
  6. 必要に応じてキャッシング (memcached など) を実装する

一般的なガイドラインとして。

于 2012-10-31T02:04:14.583 に答える