Aktualizacja aplikacji w środowisku wysokiej dostępności

Question

Piszę silnik bazy danych NoSQL i chcę udostępnić funkcje, które pomogą programistom zaktualizować aplikację do nowej wersji bez zatrzymywania działania witryny, tj. 0% przestoju podczas aktualizacji. Moje pytanie brzmi: jakie są metody lub ogólny projekt aplikacji internetowej, która działa 24 godziny na dobę, 7 dni w tygodniu i bardzo często zmienia strukturę bazy danych? Wszelkie przykłady lub historie sukcesu byłyby bardzo mile widziane.

Answer 1

Struktura bazy danych jest ściśle powiązana z regułami biznesowymi, więc jedynym scenariuszem, który mogę wymyślić, w którym często zmienia się baza danych, jest etap rozwoju projektu.

W środowisku produkcyjnym zakłada się, że aplikacja jest już stabilna pod względem reguł biznesowych, dlatego zakłada się, że zmiany w strukturze bazy danych występują rzadko. Dlatego uważam, że bardzo trudno będzie znaleźć wyszukane rozwiązania dla tej sprawy.

Istnieje oczywiście naiwne podejście, takie jak wykonanie dokładnej kopii bazy danych przed aktualizacją, przełączenie aplikacji na kopię, uaktualnienie i ponowne przełączenie.

Poza tym nie mogę myśleć o niczym innym.

Answer 2

Dzięki NoSQL - a konkretnie bazie danych zorientowanej na dokumenty - można to osiągnąć dzięki wersjonowaniu.

Rozważ MongoDB, który przechowuje wszystko jako dokumenty.

MongoDB pozwala mieć kolekcję (grupę dokumentów), gdzie schemat dla każdego dokumentu może się różnić.

Powiedzmy masz ten dokument dla użytkownika:

{ "_id" : 100, "firstName" : "John", "lastName" : "Smith" }

Można również mieć to jako dokumentu w tej samej kolekcji:

{ "_id" : 123, "firstName" : "John", "lastName" : "Smith", "hasFoo" : false }

różnych schematów, ale zarówno w tej samej kolekcji. Oczywiście to bardzo różni się od tradycyjnej relacyjnej bazy danych.

Rozwiązaniem jest wtedy dodanie pola do każdego dokumentu, który ma wersję schematu. Wtedy Twoja aplikacja będzie szukała tej wersji przy każdym zapytaniu.

MongoDB kwerenda może wyglądać następująco:

users.find({ "version" : 3 }).limit(10);

To właśnie zwraca wszystkich użytkowników, którzy są przy użyciu wersji schematu "3". Możesz wstawiać nowsze schematy bez wpływu na istniejącą witrynę i powoli usuwać stare wersje schematów, które nie są już przydatne.

Answer 3

Będziesz budował system rozproszony. Nie da się tego obejść, ponieważ będziesz potrzebować wielu maszyn do obsługi takich rzeczy jak restart.

Budowanie systemu rozproszonego oznacza dokonywanie wyborów.Odbiór 2:

1. Trwałość
2. Dostępność
3. Strong consistancy

Systemy takie jak S3, wybrało 1 & 2 i zapłacił cenę poświęcając nr 3 na korzyść "Eventual consistancy" . Istnieje great paper on S3, którą możesz przeczytać. Inne rozwiązania bazodanowe, takie jak DynamoDB, wybrały różne kompromisy.

Będziesz potrzebował load balancerów. W przeciwnym razie utkniesz w sytuacji, gdy klienci łączą się bezpośrednio z Twoją usługą, co jest trudne z różnych powodów. System Load Balancer umożliwia ponowne uruchomienie komputera we flocie bez konieczności przestoju. Rebooty, jak wszyscy wiemy, są faktem.

Wykonanie tego, co opisujesz, jest bardzo trudne. Prawdę mówiąc, powiedziałbym, że jest to problem niemal niemożliwy do rozwiązania dla pojedynczego programisty.

Jesteś daleko, daleko, daleko bardziej prawdopodobne, aby uzyskać lepsze wyniki przy użyciu istniejącej bazy NoSQL i spędzać cały swój czas pracy na produkcie ....

Answer 4

Jeżeli przedsiębiorstwo może zainwestować w rozkładzie geograficznym Baza danych. Podobnie jak tolerancja awaryjna; Brzmi to tradycyjnie, ale replikacja danych (lub replikacja magazynu danych) nie stanowi problemu dla ruchu routingu.

Opcja 2: - korzystanie z buforowania (opracowanie niestandardowe) & jazda na rowerze. np .: - od 1 rano do 2 rano użyj migawki 1 bazy danych (powiedzmy serwer1/centrum danych 1) 1:59 am serwer2/centrum danych 2 składa się z nowej architektury bazy danych (nowe pola, nowe tabele itp.) I @ 2am wszystkie Trasa ruchu przez centrum danych 2.

Jazda rowerem w oparciu o migawkę może być rozwiązaniem do rozważenia.

Answer 5

Gdy wiele serwerów WWW w środowisku produkcyjnym uzyskuje dostęp do tej bazy danych, a użytkownik ma niekompatybilną zmianę kodu (która usuwa pole i dodaje nowe pole), zaleciłbym rozwiązanie wieloetapowe. To trochę pracy, ale nie tracisz czasu na przestoje, gdy jakiś szczegół idzie źle.

Pierwszy Krok rozszerzyć stosowanie tak, że stara i nowa wersja zostanie napisane, wdrażać, że wersja

Krok drugi nawrócony jak najdalej stare wartości pól danych do nowego pola danych (może trochę czasu).

Krok trzeci zmienić aplikację do odczytu tylko nowe pole, wdrożyć go

Czwarty Krok usunąć stare pole wartości

piątym etapie usunąć zapis dawnych wartości pól z kod, wdrożyć go.

Answer 6

Jedynym możliwym przypadkiem, w którym można to osiągnąć, jest aplikacja całkowicie bezstanowa. Termin "stateless" obejmuje zarówno dane aplikacji, jak i strukturę aplikacji. Pamiętaj, że aktualizacja może wymagać zmiany definicji obiektów biznesowych oprócz danych.Biorąc pod uwagę, że taka bezpaństwowa aplikacja nie jest praktyczna z oczywistych powodów, nie ma praktycznego sposobu na osiągnięcie zerowego czasu przestojów w przypadku ogólnych ulepszeń. Każda aplikacja, która nie jest bezpaństwowcem, będzie zawierała buforowanie na żywo (w środkowej fazie) definicji obiektów biznesowych i danych biznesowych. Aktualizacja może uzasadniać nie tylko nowe dane biznesowe, ale także nowe definicje obiektów biznesowych. Dane przechowywane w pamięci podręcznej przez aktywnych użytkowników mogą zawsze powodować potencjalne niespójności z nowym schematem. Nie można migrować użytkowników, chyba że możliwe jest migrowanie zarówno danych, jak i metadanych (definicji biznesowych), buforowanych w warstwie pośredniej. Jeśli rozwalisz pamięć podręczną średniego poziomu, użytkownicy na żywo zostaną dotknięci. Można rozważyć zezwolenie użytkownikom na żywo na kontynuowanie pracy w starej wersji db i migrowanie/łączenie wszelkich zmian danych z nowym db później. Ale to także skomplikowany problem do rozwiązania. Teraz możliwe jest ograniczenie dozwolonego czasu bez konieczności aktualizacji przestojów bez wpływu na bieżących użytkowników lub upewnienie się, że po aktualizacji bazy danych, użytkownicy na żywo stają się tylko użytkownikami tylko do odczytu, chyba że wylogują się i zalogują się ponownie w stosunku do nowego schematu .