WordPressユーザー管理と統合されたクライアント用のCRMプラグインを開発し、各ユーザーの追加情報をwp_usermetaテーブルの下に保存しました。
しかし、クライアントの顧客データベースが指数関数的に成長している、と我々はに今ある何千もの私たちにいくつか与え、数千人の数十の行をwp_usermeta：私は心配され始めています。この時点で、スケーラビリティこのアーキテクチャ。
このようなユーザー数をWordPressで管理した経験はありますか？列にwp_users依存するのではなく、列をテーブルに追加する必要がありますwp_usermetaか？この段階でWordPressと自分のコードパフォーマンスを診断/プロファイルするにはどうすればよいですか？
私はこれほどの量のデータをこれほどの割合で処理したことは一度もありません。
回答:
テーブルのサイズは実際には問題ではなく、そのテーブルで実行しているクエリが問題になる可能性があります。
たとえば、user-metaテーブルに格納されたデータに基づいてユーザーを選択する場合、meta_valueはインデックス付きフィールドではないため、そのクエリは非常に最適化されません。その場合、追加のインデックスを追加する必要があるか、その特定のデータをカスタム分類法などの別の方法で保存することを検討する必要があります。
一般的に言って、メタとして保存するものは、排他的に検索するものであってはなりません。これは、WordPressのすべてのメタテーブルに適用されます。メタは主にmeta_valueではなくmeta_keyによって引き出されるように設計されています。分類法は、可能な値をセットに制限し、情報を異なる方法で編成するため、「値」が選択対象として数えられるとより効果的です。
mySQLは最初にmeta_keyに基づいてクエリを最適化し、検索できるデータの量を（うまくいけば）管理可能な制限に削減するため、meta_keyとmeta_valueの両方で選択しても、通常は問題ありません。これでも問題が発生した場合は、メタテーブルに新しいインデックスを追加することにより、インデックスにmeta_keyとmeta_valueの両方を追加することで「修正」できます。ただし、meta_valueはLONGTEXTであるため、そのインデックスの長さを適切なものに制限する必要があります。あなたのデータに応じて、20-30か何かのように。このインデックスは実際のデータよりはるかに大きくなる可能性があり、必要なストレージスペースが大幅に増えることに注意してください。ただし、これらのタイプのクエリでははるかに高速になります。これが本当に問題になる場合は、資格のあるDBAに相談してください。
参考までに、WordPress.orgには約1,100万人のユーザーが登録されています。メタの量はユーザーごとに異なり、おそらく1行あたり最低8行、最大で約250行です。usersテーブルは約2.5 GB、usermetaテーブルは約4 GBです。ほとんどの場合、問題なく実行されているようですが、時々、最適化しなければならない奇妙なクエリを見つけます。
(object_type,meta_key,meta_value(50))
APIを使用する代わりに独自のクエリを実行している場合を除き、WordPressがテーブルのインデックスによってクエリを実行し、MYSQLがこの種のクエリを最適化するため、テーブルのサイズはそれほど重要ではありません。各クエリは、1つのクエリですべてのメタ情報もフェッチします。
主張する場合は、ユーザーIDのハッシュをテーブル名として使用して、ユーザーメタテーブルを複数のテーブルに分割できますが、クエリに基づいて適切なテーブルにアクセスするには、おそらくwp_dbクラスに置換を書き込む必要があります。この方法に従うことに興味がある場合は、多くのブログで大きなネットワークインストールを処理するためのソリューションを探してください。
ただし、パフォーマンスの問題がない場合は、大幅な調整を行わなくても、さらに成長することができます。パフォーマンスの問題が発生し始めたら、DBをより高速なサーバーに移動するだけで、WPがその情報にアクセスする方法に対して行うことができる操作よりも費用対効果が高くなります。