WordPress DBの成長を計画するための良い戦略は何ですか?


9

WordPressデータベースの成長に合わせて最適化し、パフォーマンスを維持するというトピックについてのフィードバックを期待しています...画像を描くために...約150 kbから始まるWordPress / Buddypress MUサイトがあるとします(バニラインストール) ...時間の経過とともにユーザーはブログ、フォーラム、投稿、コメントを追加し、データベースは5メガバイトに増加します。その後、翌年には10メガバイトに増加します。...ホスティングコントロールがCpanelやPleskなどの標準の同じ場所にあるセットアップであると仮定します。

  • データベースのエントリ数は、どの時点でフロントエンドWebサイトのパフォーマンスに影響しますか?
  • データベースの成長に合わせてこれをスムーズに実行し続けるために、Webサイト管理者として何ができますか?
  • データベースのサイズが500〜600MBである5年目以降のパフォーマンスに関して、何を期待できますか?

タイトな船を維持する上であなたが持っているかもしれないフィードバックをありがとう。

よろしく、

S


3
7つの質問をして、1つだけ受け入れました。良い記録ではありません。:-(

8
25mbは何もありません。GBに達するので、データベースのサイズについて心配する必要があります。
Dunhamzzz

ご意見をいただきありがとうございます。500 mbでのパフォーマンスに問題がある場合、それはおそらく私たちのホスティング会社です。PS質問に答え、回答を受け入れました。
Simon

回答:


4

あなたの特定の質問:

1)パフォーマンスに影響が出る前にDBに含めることができる「エントリ数」に厳密な制限はありません。パフォーマンスは、DBのサイズと構造と同様に、ハードウェアと構成にも大きく依存します。

2)DBレイヤーのスケーラビリティが心配な場合は、クラスターで実行するか、サイズ変更が可能なクラウドボックスまたはVPSで実行できます。DBが遅くなり始めたら、サイズを増やすことができます(通常は追加料金がかかります)。これらのオプションはコストを追加しますが、DBのスケーラビリティを確保するための本当に最良の方法です。

3)これは実際にはホスティングのセットアップとDBアーキテクチャに依存します。しかし、一般的に(非常に安価なボックスを使用している場合を除いて)、30 MBのWordPressデータベースについて心配する必要はありません。WordPressはテーブルのインデックス作成に優れており、OOB MySQL構成でもこのサイズのDBでWordPressクエリを簡単に処理できます。ギガバイトに達すると、パフォーマンスの最適化オプションを真剣に検討する必要があるかもしれません。

一般に:

パフォーマンスが心配な場合は、既存のMySQL設定のチューニングやキャッシュレイヤーの設定に集中してください。キャッシングにより、MySQLへの負荷を大幅に削減できます(特にWordPressサイトでは、一般に多数のDBクエリを実行するため)。

あなたが適切にMySQLをチューニングし、まともなキャッシング層を設定した後、あなたがしている場合は、まだハードウェア構成外部増殖を心配し、あなたは時間のX量後のコンテンツを削除する方針をスティチュートことができます。

これはWordPress固有のものではありません。そして、私は疑問を適用していないすべての答えがあることはよく分からない任意の LAMPスタック上のウェブサイトやアプリケーションを実行し。しかし、多分誰かがMUテーブル構造または他のWP固有のDBトリックに関する提案を持っているかもしれません...私は知りません。


4

MySQLの視点から厳密に言えば、MySQLインスタンスのデータ/インデックスのキャッシュを改善する方法に関する提案があります。

MySQLには2つの主要なストレージエンジンがあることに注意してください。

  • MyISAM
  • InnoDB

それらのキャッシングメカニズムは異なります。選択したストレージエンジンに合わせて調整できることがいくつかあります。

MyISAM

MyISAMはインデックスページのみをキャッシュします。データをキャッシュすることはありません。MyISAMテーブルのI / Oを改善するには、2つのことを行うことができます。

MyISAMの改善#1

VARCHAR列を持つMyISAMテーブルは、初期設計に手を加えることなく内部でCHARに変換できます。mydb.mytableという名前のテーブルがあり、そのI / Oを改善したい場合は、そのテーブルで以下を実行します。

ALTER TABLE mydb.mytable ROW_FORMAT=Fixed;

これにより、テーブルのサイズが60%〜100%増加しますが、他に何も変更することなく、I / Oのパフォーマンスが20〜30%向上します。これについては、以前にDBA StackExchangeで書いています。

MyISAMの改善#2

MyISAMキーキャッシュを増やす必要があります(key_buffer_sizeでサイズ設定)。このクエリを実行してください:

SELECT CONCAT(ROUND(KBS/POWER(1024,
IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.4999),
SUBSTR(' KMG',IF(PowerOf1024<0,0,
IF(PowerOf1024>3,0,PowerOf1024))+1,1))
recommended_key_buffer_size FROM
(SELECT LEAST(POWER(2,32),KBS1) KBS
FROM (SELECT SUM(index_length) KBS1
FROM information_schema.tables WHERE engine='MyISAM' AND
table_schema NOT IN ('information_schema','mysql','performance_schema')) AA ) A,
(SELECT 2 PowerOf1024) B;

これにより、現在のデータセットに基づいた理想的なkey_buffer_sizeが表示されます。

InnoDB

InnoDBはデータとインデックスの両方をキャッシュします。すべてのデータをInnoDBに変換し、現在すべてのInnoDBデータベースからWordPressを実行している場合は、InnoDBバッファープールのサイズを設定する必要があります(innodb_buffer_pool_sizeでサイズ設定)。このクエリを実行してください:

SELECT CONCAT(ROUND(KBS/POWER(1024,
IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.49999),
SUBSTR(' KMG',IF(PowerOf1024<0,0,
IF(PowerOf1024>3,0,PowerOf1024))+1,1)) recommended_innodb_buffer_pool_size
FROM (SELECT SUM(data_length+index_length) KBS FROM information_schema.tables
WHERE engine='InnoDB') A,
(SELECT 2 PowerOf1024) B;

これにより、現在のデータセットに基づいた理想的なkey_buffer_sizeが表示されます。

予測

データセットが20倍に成長すると予測した場合、このクエリが推奨する数の20倍になります。MyISAMデータセットが15MBで、3MBがインデックスの合計であるとします。20倍のデータがあると推定する場合は、/ etc / my.cnfで次のようにkey_buffer_sizeを60MBに設定します。

[mysqld]
key_buffer_size=60M

次にMySQLを再起動します。同じことがInnoDBバッファープールにも当てはまります。

すべてのデータがInnoDBの場合、私がStackOverflowに投稿したInnoDBインフラストラクチャの完全なクリーンアップを実行する必要があります


2

データベースのエントリ数は、どの時点でフロントエンドWebサイトのパフォーマンスに影響しますか?

クエリがホスティングアカウントのリソース制限に達し始めたとき。

データベースの成長に合わせてこれをスムーズに実行し続けるために、Webサイト管理者として何ができますか?

リソースの使用状況に注意してください。リソースを増やすか、使用量を最適化するための手順を実行します。

データベースのサイズが25〜30MBである5年目以降のパフォーマンスに関して、どのようなことが期待できますか?

その小さなデータベースのパフォーマンスに変化はないはずです。

サイトの成長が遅いと予想される場合は、成長を管理する方法を学ぶための十分な時間があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.