Was ist ein gutes Gleichgewicht zwischen der Wiederverwendung von Feldern und der Erstellung neuer Felder im Kontext der Feldskalierbarkeit?

Ich habe den folgenden Satz auf einer Website gelesen:

Anstatt einem Inhaltstyp neue Felder hinzuzufügen, ist das Hinzufügen vorhandener Felder eine bessere Option, um die Komplexität des Systems zu verringern und die Skalierbarkeit zu verbessern.

Und es treten einige Zweifel auf.

In dem System, das wir entwickeln, haben wir die Möglichkeit, ein Feld für 3 oder 4 Inhaltstypen wiederzuverwenden. Anstatt jedoch die Skalierbarkeit zu verbessern, wie in der zitierten Formulierung angegeben, wird dies die Tabelle des Feldes möglicherweise schneller zu einem Engpass (Zumindest ist das meine Argumentation in diesem Fall, da alle Werte dieses Feldes zusammen ein paar Millionen pro Jahr wären und die Tabelle dadurch zu groß würde). Sind Sie einverstanden?

Wie viele Zeilen wären ein sinnvolles Maximum für die Architektur? Auf diese Weise können wir entscheiden, wann Felder wiederverwendet und wann neue erstellt werden sollen (obwohl die Möglichkeit zur Wiederverwendung besteht).

Die Datenmenge in einem Feld ist normalerweise kein Problem. Wenn Sie sich darüber Sorgen machen, schauen Sie sich alternative Feldspeicher-Plugins an oder schreiben Sie Ihre eigenen. Zum Beispiel MongoDB , die mit so ziemlich allem umgehen kann, was Sie in sie stecken . Es wird zum Beispiel auf http://examiner.com verwendet .

Ein echtes Problem ist jedoch die Anzahl der Felder, die Sie haben. Da derzeit in Drupal 7 die vollständige Feldkonfiguration aller Felder, unabhängig davon, ob sie geladen sind oder nicht, bei jeder einzelnen Anforderung aus dem Cache abgerufen wird.

Ich habe Websites mit mehr als 250 Feldern gesehen, bei denen das Laden und Deserialisieren der Feldkonfiguration mehr als 13 MB Speicher benötigt.

Bearbeiten: Der Feldinfocache wurde mit Drupal 7.22 verbessert (siehe http://drupal.org/node/1040790 für Details). Es werden nur die Felder von Bundles aus dem Cache geladen, die auf einer bestimmten Seite angezeigt werden separate Cache-Einträge. Das funktioniert nur, wenn es keine falschen API-Aufrufe gibt, die Instanzen über mehrere Bundles hinweg anfordern.

Ich stimme Berdir voll und ganz zu. Hier sind meine Erfahrungen mit einem Projekt mit Millionen von Zeilen und 30-40 Feldern auf einigen Knotentypen.

1. Die Anzahl der Zeilen in einer Feldtabelle ist kein großes Problem für die Leseleistung, da alle Felder vom Primärschlüssel abgerufen werden.
2. Die Anzahl der Felder pro Knotentyp kann beim Schreiben neuer Knoten schnell zu großen Leistungsproblemen führen. Wenn Sie mehr als 30 Felder für einen Knotentyp haben, werden beim Erstellen eines neuen Knotens mehr als 60 INSERT-Anweisungen ausgegeben . Dies dauert Sekunden. Wenn Sie Benutzer sind, die viele Daten erstellen, wird dies Ihre Leistung beeinträchtigen. Masseneinsätze von 1000 Knoten benötigen fast eine Stunde. Wenn Sie 100'000 Knoten aktualisieren müssen, ist dies ein großes Problem.
3. Wenn Sie glauben, dass das Problem mit der Anzahl der Felder Sie treffen wird, sollten Sie ernsthaft darüber nachdenken, Ihren eigenen Feldspeicher zu schreiben, oder einfach keine Felder verwenden. (Sie können Ihren Knoten immer noch mit etwas mehr Aufwand mit Ansichten arbeiten lassen.)
4. Ein Wort zu MongoDB. Es ist ein sehr interessantes Projekt und ich hoffe, es wird zum Olymp der großen DBs. Leider ist es im Vergleich zur Reife von MySql oder PgSql ein Baby. Seien Sie bereit, mit einem sehr jungen Produkt umzugehen.

Wenn Sie wirklich besorgt sind über das, was passieren wird, dann denke ich, dass eine Simulation in Ordnung ist.

Eröffnen Sie ein Konto bei Rackspace Cloud, Amazon, Linode oder an einem anderen Ort, an dem Sie ganz einfach ein VPS hochfahren können. Machen Sie zwei identische Instanzen. Installieren Sie jeweils Drupal. Erstellen Sie einige Dummy-Inhaltstypen und richten Sie die Felder auf die eine und auf die andere Weise ein. Verwenden Sie das Entwicklungsmodul, um eine Schiffsladung von Inhalten zu erstellen. Passen Sie die Leistungseinstellungen an, um sicherzustellen, dass Drupal nach Bedarf zwischengespeichert wird. Führen Sie mysqltuner aus und passen Sie MySQL für jede Empfehlung an. Überprüfen Sie die PHP- und APC-Einstellungen noch einmal, damit Sie nicht auf Swap drücken und den APC-Cache nicht umstellen.

Sobald Sie eine gute Basiskonfiguration für jeden Server erhalten haben, simulieren Sie den Datenverkehr (sowohl normale Besucher als auch Administratoraktualisierungen) mit wget und drush und erstellen Sie dann ein Profil.

Simulationen sind nie perfekt, aber sie können Sie in die richtige Richtung bringen.

Ein Problem mit der Skalierbarkeit von Feldern bei der Verwendung von Indizes für jedes einzelne Tabellenfeld in jedem Feld in der erstellten Tabelle. Der Primärschlüssel-Clustered-Index setzt sich aus den meisten Feldern zusammen und erstellt dann separate Indizes für jedes einzelne Feld. Die Indizes verursachen eine Menge Overhead-Schreibvorgänge für die Datenbank und werden in den meisten Fällen nie verwendet.

ein weiterer tipp: viele felder verursachen auch probleme mit vielen verschiedenen modulen. Die Token-GUI zum Beispiel lässt Ihren Browser einige Minuten warten, wenn Sie zum Beispiel versuchen, URL-Aliase zu bearbeiten. Dieses Verhalten ist auf allen Seiten zu sehen, auf denen das Token geladen und angezeigt wird (einschließlich devel - dpm () usw.).

Die Aufteilung dieser Daten auf mehrere Tabellen bei Verwendung von InnoDB bietet keinen Leistungsvorteil (MyISAM unterscheidet sich aufgrund der Tabellensperrung). Wenn Sie also wissen, dass Sie viele ähnliche Inhaltstypen mit ähnlichen Feldern haben (welche Konfigurationen auch gleich sind, sich möglicherweise nur in der Beschriftung unterscheiden), können Sie Ihre Felder wiederverwenden!

Aufgrund ähnlicher Knotenattribute erleichtert dies möglicherweise auch die Erstellung von Vorlagen.

Wenn wir nur meine Geschichte teilen, verwenden wir Drupal Commerce und haben ungefähr 40 Felder in unseren Produktvarianten (Sku) und dann weitere 460 (ja, verrückt) in unserer Produktanzeige. Wir hatten einige Produktvergleichsansichten, die sich mit all diesen Bereichen befassten. Ohne Caching kann das Laden einiger Seiten bis zu einer Minute dauern!

Es hat jedoch funktioniert. Wenn Sie Caching und Varnish verwendet haben, war die Wartezeit der Benutzer nicht so schlecht.

Das Hauptproblem, auf das wir bei so vielen Feldern gestoßen sind, ist bei Display Suite, da dies sehr langsam werden würde (manchmal nicht mehr reagiert), wenn wir versuchen würden, ein Feld neu anzuordnen oder zu verschieben.

Glücklicherweise haben wir uns entschlossen, unsere Produkte ein wenig neu zu faktorisieren, damit wir hoffentlich unsere maximale Anzahl von Feldern für unsere komplexesten Produkte in den Bereich von 200 bis 250 bringen können (wir sind in der wissenschaftlichen Instrumentierung, daher sind komplexe Messungen und Spezifikationen erforderlich). .

Das ist eine interessante Frage. Ich habe bereits darüber nachgedacht, dass die Wiederverwendung eines Feldes manchmal praktisch sein kann, wenn nicht viele ähnliche Felder "herumliegen", aber es ist albern, wenn ein bestimmter Inhaltstyp aus einer großen Datenmenge ausgewählt werden muss, die wir verwenden know soll nicht im Ergebnis zurückgegeben werden.

Ich benötige weitere Informationen zum Projekt, um Empfehlungen für die Skalierung zu erhalten. Wie hoch ist der erwartete Datenverkehr, wie viele dieser Benutzer müssen angemeldet sein usw.? Zum Beispiel, wenn der gesamte Datenverkehr außer dem Ihrer Administratorbenutzer nicht authentifiziert und anonym zwischengespeichert ist

Bisher habe ich Felder immer wieder verwendet, erwäge jetzt jedoch, eindeutige Felder pro Knotentyp für ein neues Projekt zu verwenden. Eigentlich möchte ich alles (Felder, Ansichten, Regeln, Kontexte usw.) für jedes Entity-Bundle getrennt halten. Es stellte sich also die Frage nach der Skalierbarkeit, die mich hierher geführt hat. Berdir's Edit (Der Feld-Info-Cache wurde verbessert (siehe http://drupal.org/node/1040790 für Details) mit Drupal 7.22, es werden nur die Felder von Bundles geladen, die auf einer bestimmten Seite angezeigt werden Dies funktioniert nur, wenn keine falschen API-Aufrufe vorliegen, die Instanzen über mehrere Bundles hinweg anfordern.

Ich möchte nur darauf hinweisen, dass es ein sehr interessantes Modul gibt, das ich seit Monaten auf mehreren komplexen Websites verwende: https://www.drupal.org/project/render_cache . Meiner Meinung nach ist es eines dieser versteckten Juwelen.

Wie auf der Projektseite steht, wird der Kommentarteil tatsächlich für DO selbst verwendet.

Würde sich in diesem Sinne der Konsens zugunsten getrennter Bereiche wenden? Der Vorbehalt, über DS erwähnt zu werden, ist jedoch immer noch ein Mist. Es ist sehr ärgerlich, wie über Ajax gespeichert wird, anstatt zum Beispiel, wie die zentrale Blockadministrationsschnittstelle die Nachbestellung handhabt. Ich denke, es ist ein DS-Problem, obwohl ...

Gemäß meinem Vorschlag ist es eine gute Idee, die gleichen Felder in einem separaten Inhaltstyp zu verwenden. Weil es die Leistung Ihrer Site verbessert. In Drupal 7 ist die Verwendung der gleichen Felder im Inhaltstyp für Ihre Drupal7-Site wirklich nützlich, wenn Sie zu diesem Zeitpunkt eine Auswahloperation verwenden.