Jaka jest równowaga między ponownym użyciem pól a tworzeniem nowych w kontekście skalowalności pól?

Przeczytałem następującą frazę na stronie internetowej:

Zamiast dodawać nowe pola do typu zawartości, dodanie istniejących pól jest lepszą opcją, aby zmniejszyć złożoność systemu i poprawić skalowalność.

I rodzą się wątpliwości.

W rozwijanym przez nas systemie mamy możliwość ponownego wykorzystania pola w 3 lub 4 typach treści, ale zamiast poprawić skalowalność, jak mówi cytowana fraza, obawiam się, że to zmniejszy, ponieważ tabela pola szybciej stałaby się wąskim gardłem (przynajmniej takie jest moje rozumowanie w tym przypadku, ponieważ wszystkie wartości tego pola łącznie wyniosłyby kilka milionów rocznie, co spowodowałoby, że stół byłby zbyt duży). Czy sie zgadzasz?

Ile rzędów byłoby rozsądnym maksymalnym celem przy tworzeniu architektury? W ten sposób moglibyśmy zdecydować, kiedy ponownie wykorzystać pola, a kiedy utworzyć nowe (nawet jeśli istnieje szansa na ponowne użycie).

Ilość danych w polu zwykle nie stanowi problemu. Jeśli martwisz się tym, zajrzyj do alternatywnych wtyczek do przechowywania danych lub napisz własne. Na przykład MongoDB , który może poradzić sobie z praktycznie wszystkim, co do niego włożysz. Jest na przykład używany na http://examiner.com .

Rzeczywistym jednak problemem jest liczba pól masz. Ponieważ obecnie w Drupal 7, pełna konfiguracja wszystkich pól, bez względu na to, czy są załadowane, czy nie, jest pobierana z pamięci podręcznej przy każdym pojedynczym żądaniu.

Widziałem witryny z ponad 250 polami, w których ładowanie i odserializowanie konfiguracji pola zajmuje ponad 13 MB pamięci.

Edycja: pamięć podręczna informacji o polach została ulepszona ( szczegółowe informacje można znaleźć w http://drupal.org/node/1040790 ) w Drupal 7.22, tylko pola pakietów wyświetlane na określonej stronie są ładowane z pamięci podręcznej i są one osobne wpisy w pamięci podręcznej. Działa to tylko wtedy, gdy nie ma niepoprawnych wywołań API, które żądają wystąpienia w wielu pakietach.

Całkowicie zgadzam się z berdir. Oto moje doświadczenia z projektem z milionami wierszy i 30-40 pól na niektórych typach węzłów.

1. Liczba wierszy w tabeli pól nie stanowi dużego problemu dla wydajności odczytu, ponieważ wszystkie pola są pobierane przez klucz podstawowy.
2. Liczba pól na typ węzła może szybko przerodzić się w duże problemy z wydajnością podczas pisania nowych węzłów. Posiadanie ponad 30 pól dla jednego typu węzła powoduje utworzenie ponad 60 instrukcji INSERT podczas tworzenia nowego węzła. Wykonanie tego zajmuje kilka sekund. Jeśli jesteś użytkownikiem tworzącym dużo danych, wpłynie to na Twoją wydajność. Wstawianie zbiorcze 1000 węzłów zajmie prawie godzinę. Jeśli musisz zaktualizować 100 000 węzłów, jest to duży problem.
3. Jeśli uważasz, że problem z polami cię dotknie, powinieneś poważnie pomyśleć o utworzeniu własnego pola pamięci lub po prostu nie używaj pól. (Nadal możesz zmusić swój węzeł do pracy z widokami przy pewnym nakładzie pracy).
4. Słowo o MongoDB. To bardzo interesujący projekt i mam nadzieję, że dostanie się do olimpiady dużych DB. Niestety w porównaniu z dojrzałością MySql lub PgSql jest to dziecko. Przygotuj się na bardzo młody produkt.

Jeśli naprawdę martwisz się tym, co się stanie, myślę, że symulacja jest w porządku.

Załóż konto w Rackspace Cloud, Amazon, Linode lub w dowolnym innym miejscu, w którym możesz łatwo uruchomić VPS. Wykonaj dwa identyczne wystąpienia. Zainstaluj Drupal na każdym z nich. Utwórz niektóre typy zawartości fikcyjnych i skonfiguruj pola w jedną stronę w jednym systemie, a drugą w drugą stronę. Użyj modułu devel, aby utworzyć mnóstwo treści. Dostosuj ustawienia wydajności, aby upewnić się, że Drupal buforuje w razie potrzeby. Uruchom mysqltuner i dostosuj MySQL dla każdej z rekomendacji. Dokładnie sprawdź ustawienia PHP i APC, aby nie uzyskiwać wymiany i nie wyrzucać pamięci podręcznej APC.

Gdy uzyskasz dobrą konfigurację podstawową dla każdego, zacznij symulować ruch (zarówno zwykłych gości, jak i aktualizacji administratora) za pomocą wget i drush, a następnie profilować.

Symulacje nigdy nie są idealne, ale mogą poprowadzić Cię we właściwym kierunku.

Jeden problem ze skalowalnością pól przy użyciu indeksów na każdym polu tabeli w każdym polu w utworzonej tabeli. Indeks klastrowany z kluczem podstawowym składa się z większości pól, a następnie tworzył osobne indeksy dla każdego pola osobno. Indeksy tworzą mnóstwo zapisów ogólnych dla bazy danych i w większości przypadków nigdy nie są używane.

kolejna wskazówka: posiadanie wielu pól spowoduje również problemy z wieloma różnymi modułami. Na przykład GUI tokena spowoduje opóźnienie przeglądarki o kilka minut, jeśli na przykład spróbujesz edytować aliasy URL. To zachowanie można zobaczyć na wszystkich stronach, na których token zostanie załadowany i wyświetlony (w tym devel - dpm () itp.)

Podział tych danych na wiele tabel przy korzystaniu z InnoDB nie przynosi żadnej korzyści w zakresie wydajności (MyISAM jest inny z powodu blokowania tabel). Tak więc - jeśli wiesz, że będziesz mieć wiele podobnych typów treści z podobnymi polami (które konfiguracje będą również takie same, może różnić się tylko etykietami), użyj ponownie pól!

Może to również ułatwić tworzenie szablonów z powodu podobnych atrybutów węzłów.

Po prostu dzieląc się moją historią, korzystamy z Drupal Commerce i mamy około 40 pól w naszych odmianach produktów (Sku), a następnie kolejne 460 (tak, szalone) na naszej wystawie produktów. Mieliśmy kilka widoków porównania produktów, które obejmowałyby wszystkie te pola. Bez buforowania niektóre ładowanie stron może zająć nawet minutę!

Jednak to zadziałało. Jeśli używałeś buforowania i lakieru, czas oczekiwania użytkownika nie był taki zły.

Główny problem, na który natrafiliśmy przy tak wielu polach, dotyczy Display Suite, ponieważ stałoby się to bardzo powolne (czasami nie reagujące), gdybyśmy próbowali zmienić układ lub przenieść pole.

Na szczęście postanowiliśmy nieco zmienić nasze produkty, aby mieć nadzieję, że uda nam się obniżyć maksymalną liczbę pól do zakresu 200-250 dla naszych najbardziej złożonych produktów (jesteśmy w oprzyrządowaniu naukowym, więc potrzebne są złożone pomiary i specyfikacje) .

To interesujące pytanie. Myślałem o tym wcześniej, czasami ponowne użycie pola może być wygodne, gdy nie ma wielu podobnych pól „leżących wokół”, ale głupotą wydaje się mieć pewien typ zawartości, który musi wybierać z dużego obciążenia danych Wiem, że wynik nie powinien zostać zwrócony.

Potrzebuję trochę więcej informacji na temat projektu, aby doradzić najlepsze praktyki skalowania. Jaki jest oczekiwany ruch, ilu użytkowników będzie zalogowanych itp.? Na przykład, jeśli cały ruch, z wyjątkiem ruchu administratora, nie jest uwierzytelniony i anonimowo buforowany

Do tej pory zawsze ponownie używałem pól, ale teraz rozważam użycie unikatowych pól dla każdego typu węzła w nowym projekcie. Naprawdę chcę zachować wszystko ładnie rozdzielone (pola, widoki, reguły, konteksty itp.) Dla każdego pakietu encji. Podniosło więc kwestię skalowalności, która mnie tu doprowadziła. Pociesza mnie edycja Berdira (pamięć podręczna informacji o polach została ulepszona ( szczegółowe informacje można znaleźć na stronie http://drupal.org/node/1040790 ) w programie Drupal 7.22. Tylko pola pakietów wyświetlane na określonej stronie są ładowane z pamięć podręczna i są to osobne wpisy pamięci podręcznej. Działa to tylko wtedy, gdy nie ma niepoprawnych wywołań API, które żądają wystąpienia w wielu pakietach).

Chciałbym tylko zauważyć, że istnieje bardzo interesujący moduł, którego używam od miesięcy na wielu, złożonych stronach: https://www.drupal.org/project/render_cache . Moim zdaniem jest to jeden z tych ukrytych klejnotów.

Jak napisano na stronie projektu, część komentarzy jest faktycznie używana w samym DO.

Czy mając to wszystko na uwadze, czy zmieniłoby to konsensus na korzyść odrębnych dziedzin? Zastrzeżenie, o którym wspomina się o DS, jest jednak wciąż kłopotliwe. To bardzo denerwuje sposób, w jaki oszczędza za pośrednictwem ajax zamiast, na przykład, w jaki sposób interfejs administracyjny bloku podstawowego obsługuje zmianę kolejności. Wydaje mi się, że to problem z DS, ale ...

Zgodnie z moją sugestią dobrym pomysłem jest używanie tych samych pól w osobnym typie treści. Ponieważ poprawi to wydajność Twojej witryny. W Drupal 7, kiedy korzystasz z operacji wyboru, użycie tych samych pól w typie zawartości jest naprawdę przydatne dla Twojej witryny Drupal7.