フィールドのスケーラビリティーのコンテキストでフィールドを再利用することと新しいフィールドを作成することの間の適切なバランスは何ですか？
ウェブサイトで次のフレーズを読みました。
新しいフィールドをコンテンツタイプに追加する代わりに、既存のフィールドを追加することは、システムの複雑さを軽減し、スケーラビリティを改善するためのより良いオプションです。
そして、いくつかの疑問が生じます。
私たちが開発しているシステムでは、3つまたは4つのコンテンツタイプにまたがってフィールドを再利用する可能性がありますが、引用句が言うようにスケーラビリティを向上させる代わりに、フィールドのテーブルがより早くボトルネックになるため、それは減少します。 （少なくとも、この場合は私の推論です。そのフィールドのすべての値を合わせると、年間数百万になるため、テーブルが大きくなりすぎます）。同意しますか？
いくつの行が、建築するときに狙うのが賢明な最大値でしょうか？そうすることで、フィールドをいつ再利用するか、いつ新しいフィールドを作成するかを決定できます（再利用する機会はあるとしても）。
通常、フィールドのデータ量は問題ではありません。それが心配な場合は、代替のフィールドストレージプラグインを調べるか、独自のプラグインを作成してください。たとえば MongoDB は、入力したほとんどすべてのものを処理できます。たとえば、 http://examiner.com で使用されます。
realの問題は、フィールドの数です。現在Drupal 7にあるため、ロードされているかどうかに関係なく、allフィールドの完全なフィールド構成、リクエストごとにキャッシュからフェッチされます。
250以上のフィールドを持つサイトを見てきました。フィールド構成のロードとシリアル化解除に13MB以上のメモリが必要です。
編集：フィールド情報キャッシュが改善されました（詳細は http://drupal.org/node/104079 を参照）Drupal 7.22、バンドルのフィールドのみ）特定のページに表示されるものはキャッシュから読み込まれ、それらは個別のキャッシュエントリです。これは、複数のバンドルにまたがるインスタンスを要求する間違ったAPI呼び出しがない場合にのみ機能します。
私は完全にberdirに同意します。これは、いくつかのノードタイプで数百万行と30〜40フィールドを持つプロジェクトでの私の経験です。
- すべてのフィールドが主キーによってフェッチされるため、フィールドテーブルの行数は読み取りパフォーマンスにとって大きな問題ではありません。
- ノードタイプごとのフィールド数は、新しいノードを作成するときに、すぐに大きなパフォーマンスの問題に発展する可能性があります。 1つのノードタイプに30以上のフィールドがあると、新しいノードを作成するときに60+ INSERTステートメントになります。これには数秒かかります。ユーザーが大量のデータを作成している場合、これはパフォーマンスに影響します。 1000ノードの一括挿入には、ほぼ1時間かかります。 100'000ノードを更新する必要がある場合、これは大きな問題です。
- フィールド数の問題が発生すると思われる場合は、独自のフィールドストレージを作成することを真剣に検討するか、フィールドを使用しないでください。 （追加の労力で、ノードをビューで機能させることができます。）
- MongoDBについて一言。これは非常に興味深いプロジェクトであり、大きなDBのオリンプになることを願っています。残念ながら、MySqlまたはPgSqlの成熟度と比較すると、それは赤ちゃんです。非常に若い製品を扱う準備をしてください。
何が起こるか本当に心配しているのなら、シミュレーションが適切だと思います。
Rackspace Cloud、Amazon、Linode、またはVPSを簡単に起動できる他の場所でアカウントを取得します。 2つの同一のインスタンスを作成します。インストールDrupal on each。ダミーのコンテンツタイプをいくつか作成し、一方のシステムと他方のシステムでフィールドを設定します。develモジュールを使用してコンテンツのボートロードを作成します。パフォーマンス設定を調整して、Drupalが必要に応じてキャッシュされていることを確認します。mysqltunerを実行し、推奨ごとにMySQLを調整します。PHPおよびAPC設定を確認して、スワップを打たず、APCキャッシュをチャーンしないこと。
それぞれの適切なベースライン構成を取得したら、wgetとdrushを使用してトラフィック（通常の訪問者と管理者の更新の両方）のシミュレーションを開始してから、プロファイルを作成します。
シミュレーションは完璧ではありませんが、正しい方向に進むことができます。
別のヒント：フィールドがたくさんあると、多くの異なるモジュールでも問題が発生します。たとえばトークンGUIを使用すると、たとえばURLエイリアスを編集しようとすると、ブラウザが数分遅れます。この動作は、トークンが読み込まれて表示されるすべてのページで確認できます（devel-dpm（）などを含む）。
InnoDBを使用する場合、このデータを複数のテーブルに分割してもパフォーマンス上の利点はありません（MyISAMはテーブルロックのために異なります）。したがって、類似のフィールドを持つ多くの類似のコンテンツタイプがあることがわかっている場合（どの構成も同じで、ラベル付けのみが異なる場合があります）、フィールドを再利用してください！
同様のノード属性により、テンプレートの作成が容易になる場合もあります。
作成されたテーブルの各フィールドのすべての単一テーブルフィールドでインデックスを使用する場合のフィールドのスケーラビリティに関する1つの問題。主キーのクラスター化インデックスは、ほとんどのフィールドの複合であり、フィールドごとに個別のインデックスを作成しました。インデックスはデータベースに大量のオーバーヘッド書き込みを作成し、ほとんどの場合使用されません。
私のストーリーを共有するだけで、Drupal Commerceを使用しており、製品バリエーション（Sku）に約40のフィールドがあり、製品表示に別の460（そう、クレイジー）があります。製品の比較がいくつかありました。これらのすべてのフィールドを表示するビューです。キャッシュがないと、一部のページの読み込みに1分ほどかかることがあります。
しかし、それはうまくいきました。キャッシュとワニスを使用した場合、ユーザーの待機時間はそれほど悪くありませんでした。
非常に多くのフィールドで遭遇した主な問題はDisplay Suiteにあります。フィールドを再配置または移動しようとすると、非常に遅くなります（応答しなくなる場合があります）。
幸いにも、私たちは製品を少しリファクタリングすることにしました。そうすることで、最も複雑な製品の最大フィールド数を200〜250の範囲に収めることができます（私たちは科学機器を使用しているため、複雑な測定と仕様が必要です）。 。
面白い質問ですね。私は以前これについて考えましたが、フィールドを再利用すると、同様のフィールドがたくさんあるので便利な場合がありますが、特定のコンテンツタイプが大量のデータから選択しなければならないのはばかげているように見えます。 knowは結果で返されることを意図していません。
スケーリングのベストプラクティスについて助言するには、プロジェクトについてもう少し情報が必要です。予想されるトラフィックとは何ですか、それらのユーザーのうち何人がログインする必要がありますか？たとえば、管理ユーザーのトラフィックを除くすべてのトラフィックが認証されておらず、匿名でキャッシュされている場合
私はこれまで常にフィールドを再利用してきましたが、新しいプロジェクトではノードタイプごとに一意のフィールドを使用することを検討しています。実際には、各エンティティバンドルのすべて（フィールド、ビュー、ルール、コンテキストなど）を適切に分離しておく必要があります。そのため、ここに私を導いたスケーラビリティの問題が提起されました。 Berdirの編集に満足しています（フィールド情報キャッシュが改善されました（詳細は http://drupal.org/node/104079 を参照）Drupal 7.22 、特定のページに表示されるバンドルのフィールドのみがキャッシュから読み込まれ、それらは別個のキャッシュエントリです。これは、複数のバンドルにまたがるインスタンスを要求する間違ったAPI呼び出しがない場合にのみ機能します。
複数の複雑なサイトで何ヶ月も使用してきた非常に興味深いモジュールがあることを指摘したいだけです。 https://www.drupal.org/project/render_cache 。それは私の意見ではそれらの隠された宝石の1つです。
プロジェクトページで述べているように、コメント部分は実際にはD. O.自体で使用されています。
それで、それらすべてを念頭に置いて、それはコンセンサスを別々の分野に有利に変えるでしょうか？ DS=について言及されている警告は、それでもなお厄介です。たとえば、コアブロック管理インターフェイスが並べ替えを処理する方法ではなく、ajaxを使用して保存する方法は非常に迷惑です。それはdsの問題ですが...