怒られるのが怖くて書きたくなかった記事です。長い間迷った末、ついに書くことにしました。この記事が、データベース インデックスの正しい設計の重要性を理解する友人に役立つことを願っています。
私は怠け者なので、簡単に言葉で説明しますが、写真を切り取って証明するのは面倒なので、テクノロジーに詳しい友人が自分でテストして、私のテスト結果が正しいかどうかを確認できます。技術的な知識に詳しくない友人がそれを信じるかどうかは関係ありません。
テスト プログラム:
CMS プログラム: Empirecms dedecms phpcms
フォーラム プログラム: discuz phpwind xiuno
load Test結果:
xiuno > discuz > phpcms >?(?empire cms?? dedecms)
データベース設計の観点からview ):
xiuno >?(discuz?, phpwind, phpcms)?>?(empire cms, dedecms)
dedecms と Empire cms はどちらも古い CMS です。データベース設計から考えると、データベース設計者は mysql インデックスの本当の意味をまったく理解していないのでしょうか、それとも高負荷要件を持つユーザーのためにそれを改善することは可能でしょうか? (テクノロジーを理解していない友人が私を批判しないことを願っています。mysql インデックスを本当に理解している友人は、自分でインデックスの設計を見てみることができます。とはいえ、dedecms と Empirecms の作者にとって、私は単なる後輩にすぎません。あなたと同じように、私は 10 年以上の経験があり、開発経験のある人々を尊敬していますが、現在の dedecms および Imperial cms データベースの設計者には、mysql インデックスをもう一度勉強することをお勧めします。私の言うことを信じる必要はありませんが、少し時間をかけても構いません。 discuz と phpwind のデータベース設計を確認するには、Indeed の方があなたのものよりも優れています)。
Empire CMS の作成者が幸運にもこの記事を読んだなら、Empire CMS アーキテクチャを再設計していただければ幸いです。何年にもわたって、Empire CMS の負荷容量は改善されてきました。サブテーブル テクノロジでは、実際には、最適化にインデックスを使用することはできません。適切なインデックスを使用すると、パフォーマンスが大幅に向上します。
私は dedecms の創設者を知っていますが、現在 dedecms は彼のものではありません。現在の dedecms はここ数年あまり変わっておらず、パッチが当てられているのが残念です。これが起こったら本当に悲劇的です。続けます。
私のテスト環境:
i3CPU 4G メモリ 1T ハードドライブ win7 システム?? Apache 2.2 mysql 5.0 (通常の環境は最適化されていません)
テスト方法:
簡単なアクセステスト用に100万から1億までのデータをインポートします
私のインポート方法:
各プログラムのデータ構造に従って作成プログラム、
1. まず PHP プログラムを作成し、データをファイル e:/insert1.sql、
2 に書き込みます。次に、LOAD DATA ローカル INFILE 'e:/insert1 .sql を渡します。 ' INTO TABLE `データ テーブル名` 文字セット エンコーディング;? この方法でインポートすると、数千の W データをインポートするのに数分しかかかりません。
1. Empire CMS
テスト バージョン: EmpireCMS_7.0_SC_GBK (現在の最新の正式バージョン)
まずは公式の Empire CMS について話しましょうデータテスト投稿（2000万データ、17.3GBデータベース下でのEmpire CMSの超生成速度？）という大きな記事があり、このテスト投稿を見たとき、私も負荷が非常に強力であると感じましたが、テストした後は残念だった。
デフォルトのテストデータ（合計33ニューステストデータ）をインストールし、ホームページを動的ホームページに変更します。 最初の訪問は0.670127010345459です。 2回目の訪問は0.07926607131958です
100Wをインポートした場合データの場合、データベースのサイズは 3.6 G、ホームページへの最初の訪問には 182 秒かかり、2 回目の訪問には 155 秒かかりました。Empire CMS の作成者が、その間にホームページへの動的アクセスの時間をテストしたかどうかはわかりません。テスト。バージョン 6.0 以降も含め、アップデートのたびにパフォーマンスが向上していると言われていますが、これはなぜでしょうか。
Empire CMS の公式テスト投稿は、人々を誤解させ、欺いています。
質問 1. テスト データには、ホームページへの動的アクセスやホームページの生成については記載されていません。リスト ページに動的にアクセスし、リスト ページを生成することについては言及されていません。
質問 2. テスト統計では、データベースに接続した後の実行時間だけがカウントされ、データベースに接続するまでの時間は加算されません。これは多くの人に誤解を与えやすく、この時間を接続のカウントに使用する可能性があります。データベースと他のデータベースとの時間の比率。それは大きな違いを生みます。
質問 3. 各ニュース記事の内容はわずか数行です。同時に、コンテンツ ページのテンプレートも非常にシンプルで、生成されるファイルも非常に小さく、わずか 3K です。通常の記事は10Kから数十Kが一般的です。
質問 4. 同時に、phome_ecms_news テーブルの ID が主キーであるため、コンテンツを読み取るときにインデックスが使用されるため、コンテンツ ページに動的にアクセスし、コンテンツを編集し、コンテンツ ページをすばやく生成します。
質問 5. テストはサブテーブルを通じて行われます。実際の Web マスターが Web サイトを構築する場合、最初から Web サイトのコンテンツをサブテーブルにすることは不可能です。したがって、これは実際の Web サイトの状況とはまったく異なります。
公式のようなテスト投稿は非常に誤解を招きやすいため、数年間停止されています。テクノロジーを理解していない人にとって、それは誤解を招き、一般のユーザーを盲目的に崇拝させるものです。
2. dedecms
テストバージョン: DedeCMS V5.7 SP1_GBK 正式版 (現在の最新の正式版)
Dreamweaver CMS は Zhidu にありますか? CMS の中で負荷パフォーマンスが最も悪いと常に認識されている CMS は、実際には非常に悪いです。
100 万件のデータをインポートしたとき、データベースのサイズはわずか 330M で、ホームページにアクセスするのにすでに 70 ～ 80 秒かかっていました。
3. phpcms
テストバージョン: PHPCMS V9_GBK 正式バージョン (現在の最新の正式バージョン)
によって再開発されました。新しいチーム、高負荷とも呼ばれます。
100万件のデータをインポートしたところ、データベースのサイズが3Gになり、ホームページにアクセスするのに20秒以上かかりました。
4. phpwind
テスト バージョン: phpwind v9.0 UTF-8 正式バージョン (現在の最新の正式バージョン)
比較に使用discuz には速度の点で利点があると言われていますが、新しいバージョンでは実際に多くの変更が加えられています (私は以前から discuz を愛用していましたが、デザインは discuz とあまり変わりません)。この変更は賞賛されるべきですが、Web ページの下部に表示される実行時間が削除されました。
1000Wのデータをインポートしたときのデータベースサイズは13Gで、
ホームページへの初回訪問は8秒、2回目の訪問は0.70477390289307秒かかりました
投稿一覧ページ(デフォルトのソートでは 0.2 ～ 0.5 秒?? しかし、「最新の投稿」でソートすると、表示に 182 秒かかりました (データベースの設計を確認したところ、「最終返信」、「投稿時間」のみでインデックス付けされていたため)並べ替えはインデックス付けされていないため、非常に時間がかかります)?
投稿コンテンツ ページには多くの返信が入力されておらず、特にテストされていません
discuz
テストバージョン: Discuz_X2.5_SC_UTF8? Discuz_X3.0_SC_UTF8
DX3 は DX2.5 の拡張バージョンのようで、バックエンドとフロントエンドの設計に関してはほとんど変更がありません。データベースのアーキテクチャはあまり変わっていません。
1000W のデータをインポートすると、データベースのサイズは 18G になります。
ホームページには 0.05 ～ 0.06 秒かかります (スレッド テーブルがまだ読み込まれていないため、テストの価値はあまりありません)。
投稿一覧ページ (デフォルトのソート) 0.07～0.09 秒? ただし、「投稿時間」でソートすると、表示に 181 秒かかりました (データベースの設計を見て、「最終返信」でインデックス付けするだけなので)完了しました、 " 「投稿時間」の並べ替えはインデックスに登録されていないため、非常に時間がかかります)?
投稿コンテンツ ページ (返信があまり入力されておらず、具体的なテストも行われていません)
6. xiuno
テストバージョン: xiuno bbs 2.02 UTF8
1000Wのデータをインポートしたときのデータベースサイズは15Gでした
ホームページ0.03～0.05秒
投稿リストページ 0.03～0.05秒（返信仕分け）??? 0.01～0.03秒（投稿仕分け）
投稿コンテンツページ 0.03～0.05秒（返信が少ない？）
1 億件のデータをインポートしたところ、データベースは 215G まで埋まりました
ホームページ 0.05 ～ 0.08 秒
投稿リスト ページ0.05 ～ 0.08 秒 (返信の並べ替え)???? 0.03 ～ 0.05 秒 (投稿の並べ替え)
投稿コンテンツ ページには 0.05 ～ 0.08 秒かかります (返信の数が多くなく、ページのテストも行われませんでした)具体的には)
概要:
xiuno 負荷は非常に高いですが、機能の制御が多く、パフォーマンスに影響を与える可能性のある機能が多数あります。機能的には、それを補うWordPressのようなプラットフォームがあれば、大きなメリットがあると思います。
discuz は詳細なテストを行っていませんが、負荷にまだ欠陥があることがわかります。同時に、スレッド テーブルは tid mediaint(8) UNSIGNED として設計されているため、最大値は大きくなります。値は 16777215 であるため、デザインは更新されていません。
phpwind のこの新しいバージョンの変更は、discuz とは異なる道を歩む決意を証明しており、ユーザー エクスペリエンスにさらに注意を払っていることもわかります。プログラムのパフォーマンスは二の次にされています。
phpcms のパフォーマンスは以前より向上しましたが、ユーザー エクスペリエンスはあまり良いとは感じません。ただし、CMS のパフォーマンスが BBS プログラムほど良くないことは説明できます。並べ替え方法が多数あり、同じページにフォーラムよりも多くのリストがあるため、CMS のパフォーマンスは BBS ほど良くありません。
Empirecms の公式プログラムは常に負荷を重視してきましたが、サブテーブルを介して負荷を増やすだけでは実際には phpcms ほど優れたものではありません。私の意見としては、プログラムの負荷が高いかどうかに関係なく、最初のステップはインデックスを正しく設計することです。インデックスが正しく設計されていない場合は、別のテーブルを使用することで解決され、Web マスターが手動で設定する必要があります。これにより、使用の難易度が完全に高まります。
dedecms は非常に多くのユーザーを抱えていますが、データベースの設計が非常に悪いだけでなく、テーブルへの分割も考慮されていないことがわかります。高負荷、結局のところ数百Wレベル データを持っているWebサイトはほとんどありません。