-1

新しいプロジェクトについて考え始めたところ、速度の問題がいくつか見つかりました。それをコーディングするための適切でエレガントな方法を選択するのを手伝ってくれることを願っています.

各ユーザーは、訪れた「場所」のデータベース レコードを持っています。各場所には「学校」があります。この特定の場所にある多くの学校です。各学校にはクラスがあります。各クラスは異なる時期に「学習年」を終了する可能性があるため、日付が学習年の終わり >= である場合、数字は増加する必要があります。

したがって、次のようなデータベースがあります。

「場所」テーブル:

place | user_id | 
----------------- 
1     |   4     |
2     |   4     |

ユーザー番号 4 は場所番号 1 と 2 を訪れました

「学校」テーブル:

school | place |
----------------
5      |   2   |
6      |   2   |

Place 2 には 2 つの学校があり、id は 5 と 6 です。

「クラス」テーブル:

class | school | end_learning | class_number
---------------------------------------------
20    |   5    | 01.01.2013   |   2
21    |   5    | 03.01.2013   |   3
22    |   5    | 05.01.2013   |   4

学校 5 には、ID が 20、21、22 の 3 つのクラスがあります。日付が 2013 年 1 月 1 日より大きい場合、クラス 20 のクラス番号を 3 に増やし、学習終了日を 2014 年 1 月 1 日に変更する必要があります。等々。

ここで、問題に取り掛かりました。1000 の場所があり、それぞれに 100 の学校があり、それぞれに 10 のクラスがある場合、1000000 のレコードが得られます。それは多い。私が提示したのは単純な例にすぎないため、ユーザーがページを更新するたびにデータベース全体を更新することを検討する必要があるため、その量のレコードで遅延が発生する可能性がある.

クラスを school テーブルの 1 つのフィールドにシリアル化することもできます。

school | place | classes
-------------------------------------------------------------------------
5      |   2   | serialized class 20, 21, 22 with end_learning field and class number
6      |   2   | other serialized classes from school 6

その場合、取得するレコードは 10 分の 1 になりますが、データを逆シリアル化し、日付を確認し、現在よりも少ない場合はシリアル化し、データベースに保存する必要があります。2 番目の問題は、すべてのレコードを変更する必要があるだけでなく、データベースからすべてのレコードを選択して操作する必要があることです。

また、2 つのデータベースを用意することも考えています。1 つは将来変更が必要になる可能性のあるレコード、もう 1 つは今後 24 時間以内 (近い将来) に変更が必要になる可能性があるレコードです。24 時間ごとに、次の 24 時間で学習を終了するすべてのクラスが「近い将来」のデータベースに移動されるため、ページを更新するたびに、数十万や数百万ではなく、数千のレコードが処理されます。その代わりに、1 日に 1 回だけ「近い将来」のテーブルを作成するために、何百万ものレコード (さらに将来) を処理します。

これらすべてのデータベース スキーマについてどう思いますか? 多分あなたはより良い考えを持っていますか？

4

1 に答える 1

2

あなたが概説しているビジネス ロジックやデータ モデルをよく理解していませんが、これについてはよく考えていると思います。

まず、MySQL のような RDBMS ソリューションは、扱うデータがリレーショナルである限り、大量のレコードの管理に非常に優れています。私が知る限り、多くのレコードを検索しますが、更新するのはごく一部です (ユーザーは限られた数のクラスにのみ登録されます)。これは大きな問題だとは思いません。

第二に、ほとんどの場合、最初から「エキゾチックな」ソリューションを使用するよりも、パフォーマンスのニーズを満たしていないことが証明されるまで「標準」のリレーショナル モデルを使用する方が良いです (私はシリアライゼーションとパーティショニングのソリューションを「エキゾチックな」と分類します)。 "この回答の目的のために）。SQL のパフォーマンスを最適化するために多くの時間と労力が費やされました。単純な代替案があれば、それは標準ソリューションの一部になります。もちろん、標準のリレーショナル モデルがスケーリングできないポイント (たとえば、Facebook サイズのトラフィック) や、リレーショナル モデルが実際には適合しないビジネス ドメイン (ドキュメント、グラフ) があります。ただし、すべての代替手段には、「標準」の MySQL と同様に利点と欠点があります。

第三に、考えられるパフォーマンスの問題に対処する最善の方法は、問題に対処することです。コードで。テスト リグを構築し、リレーショナル モデルに従ってスキーマを作成し、テスト データを入力し (例: DbMonsterを使用)、それに負荷をかけ (例: JMeterを使用)、スキーマとクエリを調整して、状況が適切でないことを証明します。標準溶液。標準的なリレーショナル データベースをうまく扱えないことを本当に証明できる場合にのみ、エキゾチックなものを選んでください。

于 2013-03-10T17:13:12.973 に答える