Ewolucja struktury danych jest bardzo trudna.

Szybko reakcja na zmiany jest jedną z największych zalet małego start-upu. Zmiana produktu czy procesów jest wykonalna, ale co jeżeli potrzeba zmienić samą strukturę kodu. Istnieją sposoby na zmianę kodu np. z rozbudowanymi testami. Ale co zmianą struktury danych?

Zmiany schematu mają opinię bardzo bolesnych, jest to przede wszystkim wina MySQL: po prostu dodanie kolumny do tabeli wymaga całej tabeli do skopiowania. Na dużej tablicy, to może oznaczać kilka godzin, podczas których nie można nic zapisać. Istnieją różne narzędzia, aby było to mniej dokuczliwe. Nie mniej jednak to niewiarygodne, że najbardziej popularna bazy danych open source na świecie zachowuję się tak źle.

PostgreSQL może dokonać prostych zmian schematu bez kopiowania tabeli, co oznacza, że ​​są prawie natychmiastowe. I oczywiście unikanie zmiany schematu jest podstawowym punktem dla baz danych, takich jak MongoDB. Poruszam tu drobne zmiany schematu, takie jak dodanie nowego pola ew. dwóch.

Nie wszystkie dane znajdują się w bazach danych. Niektóre mogą być w zarchiwizowanych plików (logi) lub jakiegoś magazynu danych. Jak radzić sobie ze zmianą schematu tych danych? I czasami trzeba dokonać skomplikowanych zmian w danych, takich jak podzielenie dużej rzeczy, lub połączenie kilku małych rzeczy lub migracji z jednego magazynu danych do innego. Narzędzia standardowe nie pomagają tu wiele, a bazy danych dokumentów nie sprawiają, że jest łatwiej.

Napisaliśmy dużych zadań migracyjnych, które podzieliliśmy na cały zestaw mniejszych kroków. Które to powoli będą uruchamiane w ciągu weekendu (tak na marginesie lepszy jest środek tygodnia). Oczywiście całą serenada powinna się zawiesić w połowie, część rzeczy zacznie działać na nowych danych a część nie. Drugie wyjście to całe mnóstwo komplikacji dla migracji danych jednorazowej. Czasami to jest nieuniknione.

Oczywiście są narzędzia które mogą nam pomóc, ale w małym zespole na poznawanie nie ma czasu, na konfigurowanie klastra, nie ma czasu na czytanie dokumentacji jak go używać też nie ma czasu. Duże firmy mają czas żeby się tym zająć, ale w małym zespole jest to nie do ogarnięcia.

Realistyczne badanie odciążenia (ruch)

Poprawa wydajności systemu to proces bardziej teoretyczny. Masz w głowie model, dodatkowo to co system robi i trochę teorii na temat co jest najbardziej zżera zasoby. Potem propozycja zmian do systemu oraz przewidywane korzyści jakie powinno to przynieść. Następnie wprowadzamy zmiany, obserwujemy zachowanie systemu w warunkach testowych. W końcu zbieranie dowodów które potwierdzają lub obalają teorię. Ta droga poprawiamy teorię i także w końcu poprawiamy działający system. Proste, skuteczne i małymi krokami poprawiające system.

Niestety, jeszcze nigdy nie udało mi się tego zrobić w praktyce. Jeżeli do optymalizacji wystarczyło by odpalić ten sam kod milion razy w pętli, było by to proste. Ale mamy do czynienia z dużą ilością danych, rozłożonych na wiele maszyn. Jeśli czytasz ten sam element milion razy w pętli, to po prostu będzie przechowywany w cach i test obciążenia nie powie Ci nic. Jeśli potrzebujesz realistyczne wyniki, test obciążenia musi symulować rzeczywistą duży zestaw danych, rzeczywistą mieszaninę odczytów i zapisów, rzeczywistą ilość żądań w czasie, i tak dalej. To bywa trudne.

Jest to na tyle trudne, że po pierwsze trzeba wiedzieć jakie są wzorce obciążenia, potem trzeba znaleźć sposób aby je symulować. Na początek, watro zacząć od czytania logów. Plusem tego jest to że są to rzeczywiste dane, minus że to są tylko dane odczytu. Napisanie na tej podstawie symulacji jest trudniejsze, ponieważ trzeba uwzględnić zasady logiki biznesowej (np.sekwencyjny przepływ pracy musi najpierw zaktualizować A, następnie zaktualizować B , a następnie zaktualizować C ) i radzić sobie ze zmianami, które mogą zdarzyć się tylko raz ( jeśli zapis zmienia stan z D do E , nie można zmienić z D E później ponownie w teście , jak już jesteś w E ). Pamiętać należy o prawach dostępu, spr logów, sesji i masie innych rzeczy.

Jeszcze trudniejsze zadanie, jeśli chcesz przetestować zestaw danych, który jest większy niż ten rzeczywisty ( tak aby można było dowiedzieć się, co się stanie, gdy podwoi się liczba użytkowników i przygotować się do tego wydarzenia ). Teraz trzeba wypracować właściwości statystyczne zbioru danych (zastanowić się jak użytkownicy wpływają na siebie i jak to będzie się zmieniać wraz ze wzrostem ich liczby) i wygenerować syntetyczny zestaw danych dla tych parametrów. W tej chwili znajdujemy się w jakiejś wirtualnej rzeczywistości, coraz dalej od tego co naprawdę dzieje się z aplikacją.

W praktyce rzadko działa to w ten sposób. Mamy szczęście, jeśli czasem możemy uruchomić stary kod i nowy side- by-side potem obserwować, i starać się wyciągać wnioski. Często zdarza się, że nawet to nie jest możliwe. Zazwyczaj po prostu bierzesz kawałek kodu, a potem albo go wdrażasz albo wyrzucasz, zależnie od tego czy przyniósł więcej pożytku czy złego. Podejście to jest głęboko niesatysfakcjonujące dla umysłów ścisłych, nie mniej jednak jako tako działa.

Scaling wstęp

Patrząc wstecz na ostatnie kilka lat programowania, zdałem sobie sprawę, że nie było wiele lekcji, za to musieliśmy się wiele nauczyć na własnej skórze. Zbudowaliśmy kilka rozsądnie dużych systemów danych, a tam kilka rzeczy które mogły by być rozwiązane inaczej. Naprawdę żałuję, że nie znałem ich wcześniej.

Nie są to jakieś magiczne i nieznane rozwiązania - wszystkie one są dobrze udokumentowane, jeśli wiesz gdzie szukać. Są to rzeczy rodzaju, że łapię się za głowę "Nie mogę uwierzyć, że tego nie wiedziałem, że jestem aż tak głupi". Mam nadzieję że nie jestem jedynym, który rozpoczął pracę nie wiedząc tych rzeczy. Postaram się je tu spisać. Polecam każdemu kto ma konieczności skalowania systemu.

Rodzaj systemu mówię to backend danych internetowej / mobilnej aplikacji z milionem użytkowników (to rząd wielkości ) . W skali od Google, LinkedIn, Facebook czy Twitter ( to setki milionów użytkowników ), będziesz miał zupełnie inny zestaw problemów, ale i większy zespół doświadczonych programistów wokół ciebie. Skala około milion użytkowników jest interesująca , ponieważ jest osiągalna dla małego zespołu z odrobiną szczęścia i dobrych umiejętności marketingowych. Jeśli brzmi to jak opis twojego projektu, oto kilka rzeczy o których warto pamiętać.