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


34

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

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

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

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

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


6
実際のメトリックでバックアップされた回答が見たいです。
mpdonadio

この質問に関する非常に建設的で有益なコメントを集めたと思います。ただし、1つまたは2日待ってから回答としてマークします。1つまたは2つの最も重いフィールドを(再利用可能であっても)分離しておくことをお勧めします。フィールドは、年間5千万、1千万、または2,000万アイテム増加する可能性があります。
rafamd

回答:


24

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

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

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

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


こんにちは、Berdir、ご回答ありがとうございます。フィールド数のオーバーヘッドについては知りませんでした。したがって、可能な限り再利用を試みる必要がありますが、それでも、最も重いものであることがわかっているものを分割しようとすべきではありませんか?私はmongoなどについてあまり知りませんが、クエリする必要のあるグループのサイズを気にしないのは本当にですか?ありがとう!
rafamd

私は実際に知りません。依存します、私は推測します。MPDが提案したようにテストを行うことは悪い考えではないかもしれません。Mysqlで非常に低レベルで直接比較することもできます。フィールドデータテーブルと同じレイアウトとインデックスを使用して2つのテーブルを作成し、1行目に10m(実際にはentity_idに異なる値を使用してください)行を書き込み、2行目に5mを書き込みます。次に、書き込みパフォーマンスと読み取りパフォーマンスを比較します(entity_idまたはインデックスに基づく)。インデックスのおかげで読み取りパフォーマンスはほぼ同等になると思いますが、書き込みパフォーマンスは違いをもたらす可能性があります。
ベルディール

そうは言っても、少数のフィールドが多少あっても、実際には違いはありません。
ベルディール

書き込みは難しい部分なので、テストを行うことをお勧めします。直観に反するのは、MySQLが行ではなくテーブルに基づいてキャッシュされたエントリを削除するという事実です(前回チェックしたとき)。複数のフィールドとテーブルのメモリオーバーヘッド、または同じテーブルへの書き込みによるキャッシュミスのどちらがより大きな影響を与えるかはわかりません。ただし、確実にトラフィック/使用に依存します。複数のキャッシュ(Drupalキャッシュ、APCオペコード、APCユーザー、MySQLクエリキャッシュ、memcached、ニスなど)を備えたシステムは、プロファイリングなしではガットベースの決定を非常に困難にします。
mpdonadio

これはもはやケースではありません:drupal.org/node/1040790
jackbravo

13

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

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

こんにちは@BetaRide、洞察力に感謝します。2)については、既にコンテンツタイプごとのフィールド数を最小限にしようとしていますが、それはここで説明していることとは異なります。本当の取引は、可能な限りフィールドを盲目的に再利用するか、(少なくとも)最も重い1つまたは2つを別々に保つことを試みる必要があります(例:簡単に同じでも、実際には同じ名前を持つなど)。ええ、mongoは今のところ最後の選択肢になります:)
rafamd

5

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

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

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

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


2

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


2

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

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

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


1

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

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

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

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


0

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

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


こんにちは@drupaljoe、返信ありがとうございます。予想されるトラフィックはまったく新しいサイトであるため、推定が困難です。細心の注意を払って開発されており、何らかの成功を期待しているため、数百人の同時ユーザー(大部分は認証済み)を管理できるとしましょう。それはまさに私が考えていたことであり、その巨大なテーブルを照会するのは苦痛に違いないので、あまり成長しないフィールドを再利用し、より多くのデータを保持するフィールドを別々に保つように設計する必要があります。何が考えすぎるのでしょうか?100万 ?1億?3億?...
rafamd

選択が主キー上にあるため、それが重要ではないという他の2つのコメントは良い点だと思います。とりあえずこれでいいと思いますが、将来のオプション、フィールドのmongoなどについて読んだことを確認してください。あなたのサイトの将来についてすべてを常に推測することはできません
joevallender

0

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

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

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

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


-3

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


1
Drupal 7で、彼らはDoctrine ORMを使い始めました ...いいえ。Drupal 8はDoctrineを使用していません
Clive

「Doctrineは常にすべてのマッピングされたデータからオブジェクトを返します」も偽のステートメントです。デフォルトの動作が適切でないことを教義に示すために、オブジェクトに注釈を付けることができます。Cliveが言うように、DrupalはDoctrineを使用していないことを考えると、それはそれほど関連しているわけではありません。
レサリオン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.