WordPressのユーザーメタスケーリング
私はWordPressのユーザー管理と統合されたクライアント用のCRMプラグインを開発し、wp_usermetaテーブルの下に各ユーザーの追加情報を格納しました。
しかし、クライアントの顧客データベースは指数関数的に成長しており、現在はthousandになっています。これにより、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です。たいていの場合、問題なく動作しているように見えますが、たまには最適化する必要があるという変わった質問を見つけることがあります。
APIを使用せずに独自のクエリを実行しているのでなければ、wordpressがテーブルのインデックスによってクエリを実行し、MYSQLがこの種のクエリを最適化することになっているので、テーブルのサイズはそれほど問題になりません。各クエリは、1つのクエリ内のすべてのメタ情報も取得します。
テーブル名としてユーザーIDのハッシュを使用してユーザーメタテーブルを複数のテーブルに分割できると主張した場合、おそらくクエリに基づいて正しいテーブルにアクセスするためにwp_dbクラスの代わりを書く必要があります。このパスをたどることに興味があるなら、多くのブログで大規模ネットワークインストールを処理するための解決策を探してください。
しかし、パフォーマンスに問題がなければ、大幅な調整をしなくてもさらに成長することができます。パフォーマンスの問題が発生し始めたら、DBをより高速なサーバーに移動するだけで、その情報にアクセスする方法WPよりも費用効率が高くなります。