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

34

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).

rafamd
źródło
6
Bardzo chciałbym zobaczyć odpowiedzi poparte rzeczywistymi danymi.
mpdonadio
Pomyśl, że zebraliśmy bardzo konstruktywne i pouczające komentarze dotyczące tego pytania. Poczekam jednak jeden lub dwa dni, zanim oznaczę jako odpowiedź, ponieważ coś we mnie upiera się, że utrzymanie jednego lub dwóch najcięższych pól osobno (mimo że można je ponownie wykorzystać) może być dobrym pomysłem :) ... szczególnie znając te liczba zgłoszeń może łatwo wzrosnąć o 5, 10 lub 20 milionów pozycji rocznie.
rafamd

Odpowiedzi:

24

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.

Berdir
źródło
Cześć Berdir, dzięki za odpowiedź. Nie wiedziałem o tym narzutu dla liczby pól. Powinniśmy więc spróbować wykorzystać jak najwięcej, ale czy nie powinniśmy starać się rozdzielić te, o których wiemy, że są najcięższe? Nie wiem dużo o mongo i tym podobnych, ale czy to naprawdę nie obchodzi ich wielkość grupy, którą muszą zapytać? dzięki !
rafamd
Właściwie nie wiem. Zależy, jak sądzę. Wykonanie testu zgodnie z sugestią MPD może nie być złym pomysłem. Możesz nawet porównać to bardzo niski poziom bezpośrednio w MySQL. Utwórz dwie tabele o tym samym układzie i indeksach, co tabele danych pól, zapisz 10 m (pamiętaj, aby faktycznie użyć różnych wartości dla ID_ podmiotu) w jednym i 5 m w drugim. Następnie porównaj wydajność zapisu i wydajność odczytu (na podstawie bytu_id, czyli indeksu). Podejrzewam, że dzięki odczytowi wydajność odczytu będzie prawie taka sama, ale wydajność zapisu może mieć znaczenie.
Berdir,
To powiedziawszy, posiadanie garści pól mniej więcej tak naprawdę nie robi różnicy, więc jeśli czujesz się bardziej komfortowo w ten sposób, nie powinno to stanowić problemu.
Berdir,
Pisanie jest trudną częścią, stąd moja rekomendacja dotycząca wykonania testu. To, co może być sprzeczne z intuicją, to fakt, że MySQL upuszcza wpisy w pamięci podręcznej na podstawie tabeli, a nie wiersza (przy ostatnim sprawdzeniu). Nie jestem pewien, jaki byłby większy wpływ, narzut pamięci wielu pól i tabel lub brak pamięci podręcznej z zapisów do tej samej tabeli. Z pewnością zależy to jednak od ruchu / użytkowania. Systemy z wieloma pamięciami podręcznymi (pamięć podręczna Drupal, kod opc APC, użytkownik APC, pamięć podręczna zapytań MySQL, memcached, lakier itp.) Bardzo utrudniają podejmowanie decyzji bez profilowania.
mpdonadio
tak już nie jest: drupal.org/node/1040790
jackbravo
13

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.
BetaRide
źródło
Cześć @BetaRide, dzięki za wgląd. Około 2), staramy się już zminimalizować liczbę pól dla każdego typu treści i nie o to tutaj dokładnie rozmawiamy. Prawdziwa okazja: czy powinienem ślepo ponownie wykorzystywać pola, gdy tylko jest to możliwe, czy też powinienem spróbować (przynajmniej) przechowywać jeden lub dwa najcięższe osobno (nawet jeśli mogą być z łatwością takie same, np. Mają taką samą nazwę itp.). Tak, mongo powinno być na razie naszą ostatnią alternatywą :)
rafamd,
5

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.

mpdonadio
źródło
2

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.

jozwikjp
źródło
2

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.

Andre Baumeier
źródło
1

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) .

Waterskier19
źródło
0

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

joevallender
źródło
Cześć @drupaljoe, dzięki za odpowiedź. Oczekiwany ruch jest trudny do oszacowania, ponieważ jest to zupełnie nowa strona. Jest rozwijany z dużą starannością i spodziewamy się pewnego sukcesu, więc powiedzmy, że udało nam się mieć kilkuset równoczesnych użytkowników (większość z nich jest uwierzytelniona). Właśnie o tym myślałem, sprawdzanie, czy ogromna tabela musi być uciążliwe, więc może powinniśmy zaprojektować te pola, które nie wzrosną zbytnio, i oddzielić te, które będą zawierać więcej danych. Co można uznać za za dużo? 1 milion ? 100 milionów ? 300 milionów ? ...
rafamd,
Myślę, że komentarze pozostałych dwóch dotyczące tego, jak nie powinno to mieć większego znaczenia, ponieważ selekcje znajdują się na kluczu podstawowym, są dobrym punktem. Chyba powiedziałbym, że po prostu idź z tym na razie, ale upewnij się, że przeczytałeś o swoich opcjach na przyszłość, mongo na polach itp. Nie zawsze możesz zgadywać wszystko o przyszłości twojej witryny
joevallender
0

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 ...

Oscar
źródło
-3

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.

purab
źródło
1
W Drupal 7 zaczęli używać Doctrine ORM ... nie, nie zrobili tego. Drupal 8 nawet nie używa Doctrine
Clive
„Doctrine zawsze zwraca obiekt ze wszystkich zmapowanych danych”, jest również fałszywym stwierdzeniem. Obiekty mogą być opatrzone adnotacjami, aby wskazać doktrynie, że domyślne zachowanie nie jest odpowiednie. Nie jest to szczególnie istotne, biorąc pod uwagę, że, jak mówi Clive, Drupal nie używa Doktryny.
Letharion