フィールドのスケーラビリティのコンテキストで、フィールドの再利用と新しいフィールドの作成のバランスはどうですか？

ウェブサイトで次のフレーズを読みました。

コンテンツタイプに新しいフィールドを追加する代わりに、既存のフィールドを追加することは、システムの複雑さを軽減し、スケーラビリティを改善するためのより良いオプションです。

そして、いくつかの疑問が生じます。

開発中のシステムでは、3つまたは4つのコンテンツタイプでフィールドを再利用する可能性がありますが、引用されたフレーズが示すようにスケーラビリティを改善する代わりに、フィールドのテーブルがより速くボトルネックになるため、それが減少することを恐れています（少なくともこの場合の理由は、そのフィールドのすべての値が一緒になって年間数百万になり、テーブルが大きくなりすぎるためです）。同意しますか？

設計する際に目標とする合理的な最大数は何行ですか？そうすることで、いつフィールドを再利用し、いつ新しいフィールドを作成するかを決定できます（再利用の機会がそこにあるとしても）。

通常、フィールドのデータ量は問題ではありません。心配な場合は、別のフィールドストレージプラグインを調べるか、独自のプラグインを作成してください。たとえば、MongoDBは、ユーザーが入力したほとんどすべてのものを処理できます。たとえば、http：//examiner.comで使用されます。

本当の問題は、しかし、あなたが持っているフィールドの数です。現在、Drupal 7では、すべてのフィールドの完全なフィールド構成が、ロードされているかどうかに関係なく、すべての単一の要求でキャッシュから取得されます。

250以上のフィールドを持つサイトを見てきましたが、フィールド構成の読み込みと非シリアル化には13 MB以上のメモリが必要です。

編集：Drupal 7.22では、フィールド情報キャッシュが改善されました（詳細はhttp://drupal.org/node/1040790を参照）。特定のページに表示されるバンドルのフィールドのみがキャッシュから読み込まれ、個別のキャッシュエントリ。これは、複数のバンドルにわたってインスタンスを要求する間違ったAPI呼び出しがない場合にのみ機能します。

私は完全にberdirに同意します。これは、一部のノードタイプで数百万の行と30〜40のフィールドを持つプロジェクトでの私の経験です。

1. すべてのフィールドは主キーによってフェッチされるため、フィールドテーブルの行数は読み取りパフォーマンスにとって大きな問題ではありません。
2. ノードタイプごとのフィールドの数は、新しいノードを書き込むときに、すぐに大きなパフォーマンスの問題になります。1つのノードタイプに30以上のフィールドがあると、新しいノードを作成するときに60以上のINSERTステートメントになります。これには数秒かかります。ユーザーが大量のデータを作成している場合、これはパフォーマンスに影響します。1000ノードの一括挿入には、ほぼ1時間かかります。100'000ノードを更新する必要がある場合、これは大きな問題です。
3. フィールド数の問題が発生すると思われる場合は、独自のフィールドストレージの作成を真剣に検討するか、フィールドを使用しないでください。（ノードをビューで動作させるには、さらに努力する必要があります。）
4. MongoDBについての言葉。これは非常に興味深いプロジェクトであり、大きなDBのオリンピックになっていることを願っています。残念ながら、MySqlやPgSqlの成熟度と比較すると、それは赤ん坊です。非常に若い製品に対処する準備をしてください。

あなたが本当に何が起こるか心配しているなら、シミュレーションが適切だと思います。

Rackspace Cloud、Amazon、Linode、またはVPSを簡単に起動できる他の場所でアカウントを取得します。2つの同一のインスタンスを作成します。それぞれにDrupalをインストールします。いくつかのダミーコンテンツタイプを作成し、一方のシステムでフィールドを設定し、もう一方のシステムでフィールドを設定します。develモジュールを使用して、大量のコンテンツを作成します。パフォーマンス設定を調整して、必要に応じてDrupalがキャッシュされるようにします。mysqltunerを実行し、推奨事項ごとにMySQLを調整します。PHPとAPCの設定を再確認して、スワップをヒットしないようにし、APCキャッシュを変更しないようにします。

それぞれに対して適切なベースライン構成を取得したら、wgetとdrushを使用してトラフィック（通常の訪問者と管理者更新の両方）のシミュレーションを開始し、プロファイルを作成します。

シミュレーションは決して完璧ではありませんが、正しい方向に進むことができます。

作成されたテーブルの各フィールドのすべての単一テーブルフィールドでインデックスを使用する場合のフィールドのスケーラビリティに関する1つの問題。主キーのクラスター化インデックスは、ほとんどのフィールドの複合体であり、各フィールドに個別のインデックスを作成しました。インデックスはデータベースに大量のオーバーヘッド書き込みを作成し、ほとんどの場合使用されません。

別のヒント：フィールドが多いと、多くの異なるモジュールでも問題が発生します。たとえば、トークンGUIを使用すると、たとえばURLエイリアスを編集しようとすると、ブラウザーが数分間遅れます。この動作は、トークンがロードおよび表示されるすべてのページで見ることができます（devel-dpm（）などを含む）

InnoDBを使用する場合、このデータを複数のテーブルに分割してもパフォーマンス上の利点はありません（MyISAMはテーブルロックのために異なります）。そのため、類似したフィールドを持つ類似したコンテンツタイプが多数あることがわかっている場合（構成も同じで、ラベル付けのみが異なる場合があります）、フィールドを再利用します。

同様のノード属性により、テンプレートの作成が容易になる場合もあります。

私の話を共有するだけで、Drupal Commerceを使用して、製品バリエーション（Sku）に約40のフィールドがあり、製品ディスプレイにさらに460（はい、クレイジー）があります。これらのすべてのフィールドを調べる製品比較ビューがいくつかありました。キャッシュを使用しないと、ページの読み込みに最大1分かかる場合があります。

しかし、うまくいきました。キャッシュとVarnishを使用した場合、ユーザーの待ち時間はそれほど悪くはありませんでした。

非常に多くのフィールドで遭遇した主な問題はDisplay Suiteにあります。フィールドを再配置または移動しようとすると、非常に遅くなることがあります（応答しない場合があります）。

幸いなことに、私たちは製品を少しリファクタリングして、最も複雑な製品の最大フィールド数を200-250の範囲に収めることができるようにしました（科学機器であるため、複雑な測定と仕様が必要です） 。

興味深い質問です。私はこれについて前に考えましたが、フィールドを再利用すると、「横たわる」類似のフィールドの負荷を持たないことが便利な場合がありますが、特定のコンテンツタイプが大量のデータから選択しなければならないのは愚かなことですknowは結果に返されることを意図していません。

スケーリングのベストプラクティスについてアドバイスするには、プロジェクトについてもう少し情報が必要です。予想されるトラフィックは何ですか、ログインするユーザーは何人ですか？たとえば、管理ユーザー以外のすべてのトラフィックが認証されておらず、匿名でキャッシュされている場合

私はこれまでずっとフィールドを再利用してきましたが、現在は新しいプロジェクトのノードタイプごとに一意のフィールドを使用することを検討しています。実際には、各エンティティバンドルについて、すべてを適切に分離（フィールド、ビュー、ルール、コンテキストなど）したいです。そこで、ここで私を導いたスケーラビリティの問題を提起しました。私は、Berdirの編集（フィールド情報キャッシュが改善されました（詳細はhttp://drupal.org/node/1040790を参照）Drupal 7.22で安心しています。特定のページに表示されるバンドルのフィールドのみが読み込まれますキャッシュとそれらは別々のキャッシュエントリです。これは、複数のバンドルにわたってインスタンスを要求する間違ったAPI呼び出しがない場合にのみ機能します）。

複数の複雑なサイトで何ヶ月も使用している非常に興味深いモジュールがあることを指摘したいだけです：https : //www.drupal.org/project/render_cache。それは私の意見ではそれらの隠された宝石の一つです。

プロジェクトページにあるように、コメント部分は実際にはDO自体で使用されています。

それで、それをすべて念頭に置いて、コンセンサスを別々の分野に向かわせるでしょうか？ただし、DSについて言及されている警告は、依然として残念です。たとえば、コアブロック管理インターフェイスが並べ替えを処理する方法ではなく、ajaxを介して保存する方法は非常に面倒です。しかし、私はそれがDSの問題だと感じています...

私の提案によると、別のコンテンツタイプで同じフィールドを使用するのは良い考えです。サイトのパフォーマンスが向上するためです。Drupal 7では、その時点で選択操作を使用している場合、コンテンツタイプで同じフィールドを使用することは、Drupal7サイトにとって本当に便利です。