Wyzwania
Wiem, że istnieją takie praktyki, jak dodawanie tylko obiektów bazy danych, tj. Tabel i kolumn, nigdy ich nie modyfikując ani nie usuwając
W jednej firmie, dla której pracowałem, okno surowych danych wynosiło około 6 miesięcy i zjadło 10 TB. Dane zostały następnie przetworzone do formatu RDBMS, który kosztował 6 TB danych użytkowych, co stanowiło około 10 lat danych podlegających zgłoszeniu. Chodzi o to, że tego rodzaju praktyki po prostu nie są praktyczne. Magazynowanie jest drogie - prawdopodobnie największy koszt obliczeniowy. Zapewnia to kilka interesujących wyzwań:
- Kopie zapasowe - wtyczki innodb są świetne, ale czasy tworzenia kopii zapasowych tak dużej ilości danych nie są tak praktyczne
- Czasy przywracania - w przypadku dużych zestawów danych - szczególnie jeśli potrzebujesz replikacji, aby nadrobić zaległości po przywróceniu przywracania do stanu operacyjnego może potrwać kilka dni, a nawet tygodni
- Tworzenie / inicjowanie nowych instancji - Często praca, którą możesz wykonywać w dev / test, obejmuje zadania ETL (wyodrębnianie, transformacja i ładowanie) w zbiorze danych. Należy je zweryfikować za pomocą jednostek testujących QA, ale należy to zrobić w sposób nieniszczący, aby zachować oryginalny zestaw danych produkcyjnych. Podczas katastrofy możesz być gotów poradzić sobie z długim czasem przywracania, zakładając, że kopie zapasowe są polisą ubezpieczeniową, a ich celem jest ich uniknięcie, proces tworzenia oprogramowania DevOps wymaga, w zasadzie, że możesz wykonać przywracanie lub regularne kopiowanie danych (być może wiele razy dziennie)
- Pojemność - Przerzucanie tak dużej ilości danych w skali, którą właśnie opisałem, może być bardzo intensywne we / wy. Nie tylko musisz rozwiązać problemy opisane w 1-3, ale musisz to zrobić w sposób, który nie spowoduje przestojów ani spowolnienia wydajności systemów produkcyjnych.
Chociaż powyższe rozważania mogą nie dotyczyć mniejszych skal, w większych skalach stają się one ogromnymi problemami. Oznacza to, że niezwykle ważne jest zdefiniowanie wymagań i prognozowanie rozmiaru zestawu danych.
Określanie wymagań
W rezultacie musisz zdefiniować kilka wymagań:
- RTO - RTO lub czas przywracania kopii zapasowych są jednym z najważniejszych sterowników rozwiązań do tworzenia kopii zapasowych baz danych. Chociaż na początku może nie wydawać się odpowiedni dla większości innych problemów, staje się niezwykle istotny, gdy zapytasz „Co, jeśli użyłem mojego rozwiązania do tworzenia kopii zapasowych lub tworzenia nowych instancji?”. W następnej sekcji omówię kilka technik.
- RPO - RPO lub cel punktu przywracania dla kopii zapasowych określa A) jak daleko można przywrócić (minuty, godziny, dni, tygodnie, miesiące lub lata) B) Interwał tworzenia kopii zapasowych na różnych poziomach i C) jak szczegółowo możesz przywrócić . Na przykład w przypadku baz danych e-mail często poszukuje się kopii zapasowych na poziomie wiadomości - przywracania określonej wiadomości e-mail. Podobnie może się okazać, że dane z kilku dni są całkowicie bezużyteczne - więc nie ma sensu przywracać wstecz o rok.
- Rozmiar zestawu danych - Jest to ważne, ponieważ w przypadku bazy danych o wielkości 1 MB Twój RTO może zostać osiągnięty za pomocą większości produktów i rozwiązań do tworzenia kopii zapasowych. Jednak w przypadku bazy danych 10 TB okaże się, że pełna kopia zapasowa na poziomie wiersza na taśmie LTO 3 prawdopodobnie nie osiągnie RTO i może zakłócać RPO, ponieważ kopie zapasowe zaczynają przekraczać okno kopii zapasowej. Nie można dokładnie zrobić mysqldump na tym dużym zbiorze danych, ale prawdopodobnie można by tego uniknąć w bazie danych 1 MB.
- Spójność bazy danych - Ostatnią rzeczą, która ma ogromne znaczenie w ciągłym wdrażaniu, niezawodności witryny, skalowalności i wysokiej dostępności podczas pracy z bazami danych, jest twoja potrzeba (lub jej brak) spójności. Istnieją trzy podstawowe typy: natychmiastowa spójność, spójność Just-In-Time (JIT) i ostateczna spójność
Oprócz powyższych głównych uwag należy również wziąć pod uwagę wymagania dotyczące licencji i wsparcia (otwarte lub zamknięte źródło; wsparcie wewnętrzne, wsparcie strony trzeciej lub wsparcie dostawcy) wymagania dotyczące aplikacji / języka (konektory dla wielu baz danych mogą być ważne; Twoja aplikacja jest skompilowana? Czy masz dostęp do kodu źródłowego? Czy możesz go ponownie skompilować, czy też jest on dostarczany przez dostawcę? Czy może też działa w tłumaczonym języku?) Wymagania polityczne (Czy Twoja organizacja ufa Oracle? Czy nienawidzi wyroczni? „Czy nie ufają MySql?” Co sądzisz o MariaDB lub Postgres?) I silniku bazy danych (innoDB? MyISAM? Blackhole? NDB Cluster? Spider?) Oraz wymagania historyczne lub dotyczące zgodności (używaliśmy PL / SQL od półtora roku naszego kodu jest wbudowany w silnik Oracle! Jak moglibyśmy przenieść się do MariaDB?!?)
Wszystkie te rzeczy (znacząco) wpływają na dostępne narzędzia.
Niektóre opcje wewnętrznego zarządzania danymi
Uwaga: Poniższe informacje nie są w żaden sposób wyczerpujące, a inni użytkownicy SE powinni włączyć dodatkowe sugestie.
Uwzględniając ogólne rozważania, pozwólcie, że przedstawię kilka technik i technologii umożliwiających rozwiązanie powyższego problemu. Po pierwsze, zadaj sobie pytanie, czy naprawdę potrzebujesz korzystać z RDBMS, czy też nieuporządkowane dane z czymś takim jak Hadoop, CouchDB lub nawet Object Oriented Storage (coś takiego jak swift) są opcją.
Po drugie, zastanów się nad rozwiązaniem opartym na chmurze. W ten sposób część tego bólu głowy zostaje zlecona na zewnątrz, a skomplikowane problemy pozostawia się wysoko wykwalifikowanym (i opłacanym) osobom. W skali można jednak zauważyć, że to naprawdę pochłania Twój budżet (dostawcy usług chmurowych ZYSKUJĄ na tym zysk, i na pewną skalę możesz sobie pozwolić na zatrudnienie tych ekspertów samodzielnie) lub jeśli pracujesz pod szczególną ochroną lub polityką wymagania (czytaj: nie możemy robić chmur) rozważ hybrydowy filtr NFS / FibreChannel. Większość tych filtrów, takich jak NetApp, Pure Storage i Tegile, obsługuje technikę migawek i klonowania opartą na delcie, która może być bardzo przydatna dla A) robienia kopii zapasowych, B) przywracania kopii zapasowych i C) inicjowania nowych kopii zapasowych.
W tym momencie muszę zauważyć, że nie jestem ekspertem od tworzenia kopii zapasowych i przechowywania, więc jest kilka części tego problemu, których nigdy nie byłem w stanie rozwiązać, zanim przeszedłem na inne problemy (i bardziej zielone pastwiska).
Ale powiedziawszy to, produkty te umożliwiają robienie różnicowych migawek pod bazą danych. Będziesz musiał wykonać skrypt „pełnej tabeli blokowania z blokadą odczytu” na jednej z instancji bazy danych (zalecany jest tylko moduł podrzędny tylko do odczytu) i zrzucić swoją pozycję binlog lub GTID, ale w przypadku tych filtrów będzie to możliwe aby użyć tych przystawek do utworzenia nowych instancji bazy danych. Będziesz chciał umieścić binlogs na osobnej partycji i umieścić tylko dane bazy danych na tych partycjach. Gdy to zrobisz, będziesz mógł sklonować te partycje (w NetApps jest to znane jako „ FlexClone ”
Jest tak, ponieważ dla każdego odczytu bloku filer musi ustalić, czy dane znajdują się w zamrożonym oryginalnym obrazie stanu, czy w delcie. W przypadku woluminów / sklepów z wieloma migawkami może to wymagać wielokrotnego sprawdzenia. Możesz temu zaradzić, odświeżając dane (co oznacza, odrzuć migawkę i okresowo ją klonuj - co może się zdarzyć naturalnie i organicznie w celu zapewnienia dobrego ciągłego środowiska wdrażania) lub trwale dzieląc wolumin (znany jako „Flex Split” w terminologii NetApp ), co zajmie chwilę, aby trwale rozwiązać delty i utworzyć całkowicie nowy i osobny wolumin.
Te klony delta mają dodatkową zaletę polegającą na zmniejszeniu ogólnego zapotrzebowania na pamięć - możesz spawnować kilka klonów lub wystąpienie danych z produkcyjnej bazy danych, aby wykonać programowanie, testowanie i sprawdzanie poprawności. Jeśli przechowujesz tylko jedną kopię dużego zestawu danych plus (prawdopodobnie prawdopodobnie) małe delty, zmniejszysz całkowity koszt przechowywania i powierzchnię.
Jedyną sztuczką jest to, że może nie stanowić pełnego rozwiązania do tworzenia kopii zapasowych, ponieważ „kopia zapasowa” nadal znajduje się w twoim filerze. W tym celu może być konieczne użycie czegoś, co NetApp nazywa Snap Mirror, który będzie dublował dane (przy użyciu technologii w stylu rsync) między filtrami, a nawet centrami danych, lub użyć pewnego rodzaju zintegrowanego rozwiązania do tworzenia kopii zapasowych, które może wykonać kopię zapasową na jednej z migawek delta lub flex-klon.
Ma to jednak jedną poważną wadę: wszystkie twoje dane - deweloper, test i prod nadal używają I / O na tym samym filtrze i głowicy pamięci. Aby obejść ten problem, rozważ utworzenie instancji podrzędnej bazy danych na drugim filtrze, który może być punktem początkowym dla testowania i / lub filtrowania deweloperów, lub rozważ użycie kontrolera dostarczania równoważenia obciążenia / aplikacji dla warstwy aplikacji w celu odzwierciedlenia żądań produkcyjnych w twoim środowisko testowe (i / lub programistyczne). Ma to tę dodatkową zaletę, że generuje ruch produkcyjny w środowisku kontroli jakości / testowania przed awansowaniem do produkcji w przypadku problemów, które mogą nie zostać natychmiast zauważone. Następnie można sprawdzić dzienniki pod kątem błędów w oparciu o ruch produkcyjny i zachowanie użytkownika.
To powinno pozwolić ci na użycie kilku skryptów do programowego odrodzenia i zniszczenia całych (i dużych) zestawów danych do użycia z metodologiami ciągłego wdrażania.
Skalowalność i wysoka dostępność
Podczas gdy pytasz o ciągłe wdrażanie, DevOps jest zabezpieczony czymś więcej niż tylko ciągłym wdrażaniem - dlatego przedstawię kilka informacji na temat redundancji, skalowalności i wysokiej dostępności.
Wspomniałem, JIT, natychmiastową i ewentualną spójność. W tym miejscu pojawiają się różne silniki RDBMS. Ostateczna spójność jest stosunkowo łatwa dzięki prostej konfiguracji cyklicznej asynchronicznej replikacji. Może to jednak powodować niektóre kolizje * (co jeśli warstwa aplikacji aktualizuje dane po jednej stronie klastra i po drugiej stronie klastra przed zakończeniem replikacji?) Aby uzyskać natychmiastową spójność, spójrz na klaster Galera, który wymusi synchroniczną replikację, ale powoduje problemy ze skalowalnością (w jaki sposób zostanie przeprowadzona replikacja do witryny odzyskiwania po awarii lub równoważenie obciążenia geograficznego bez znacznego opóźnienia z powodu opóźnienia propagacji w warstwie sieci?) Możesz także sprawdzić, czy możesz wykonać replikację synchroniczną w centrum danych i replikację asynchroniczną między witrynami, ale wydaje się to najgorsze z obu światów.
Zazwyczaj jednak większość ludzi nie potrzebuje w pełni synchronicznej replikacji - jest to zwykle potrzebne tylko w bardzo specyficznych (i egzotycznych) środowiskach z wysokim zapisem, w których wymagany jest multi-master z dzieleniem tabel. Większość aplikacji może poradzić sobie ze spójnością Just-In-Time za pomocą serwera proxy bazy danych. Na przykład ScaleArc będzie monitorować stan replikacji i śledzić dokąd właśnie zapisy (aby wysłać kolejne żądania odczytu do momentu, aż replika się dogoni), aby zapewnić spójność i wygląd Just-In-Timespójności bazy danych. ScaleArc jest kompatybilny z Postgres, MySQL, MariaDB, Oracle i MSSQL i może używać wyrażeń regularnych do dzielenia / partycjonowania baz danych dla aplikacji, które nie mogą używać kluczy odłamków. Posiada również solidny interfejs API REST do oprogramowania do zarządzania konfiguracją, z którym można współpracować - a ich zespół wsparcia jest wyjątkowy
Podobnie możesz rozważyć darmową alternatywę MaxScale opracowaną przez zespół MariaDB dla MariaDB. Brakuje jednak GUI i niektórych funkcji buforowania ScaleArc.
Wreszcie, tkanina MySQL (i tylko klaster MySQL w pamięci RAM - jeśli możesz sobie pozwolić na tak dużo pamięci RAM) to inne potencjały - szczególnie z nowym serwerem proxy MySQL. Może to zapewnić składnik skalowalności i redundancji w twoim środowisku.
Postgres i Oracle powinny mieć potrzebne funkcje replikacji i shardingu, ale ScaleArc dobrze się sparuje, jeśli potrzebujesz proxy.
Ostatecznie wszystkie te elementy składają się na wysoce elastyczne środowisko odpowiednie do ciągłego wdrażania i rozwoju, jeśli nie jesteś w stanie po prostu korzystać ze środowiska opartego na chmurze i pozwolić dostawcy usług chmurowych zająć się powyższymi problemami.