Jestem pewien, że widziałeś, jak to nadchodzi, „To zależy”.
To zależy od wszystkiego. Rozwiązanie udostępniania danych Klienta dla działu A może być zupełnie inne w przypadku udostępniania danych Klienta działowi B.
Moją ulubioną koncepcją, która pojawiła się na przestrzeni lat, jest koncepcja „Ostatecznej spójności”. Termin pochodzi od Amazona mówiącego o systemach rozproszonych.
Założenie jest takie, że chociaż stan danych w rozproszonym przedsiębiorstwie może nie być teraz idealnie spójny, „w końcu” tak będzie.
Na przykład, gdy rekord klienta zostanie zaktualizowany w systemie A, dane klienta systemu B są teraz nieaktualne i nie pasują do siebie. Ale „ostatecznie” rekord z A zostanie wysłany do B w jakimś procesie. Tak więc ostatecznie te dwie instancje będą pasować.
Kiedy pracujesz z jednym systemem, nie masz „EC”, a raczej masz natychmiastowe aktualizacje, jedno „źródło prawdy” i zazwyczaj mechanizm blokujący do obsługi sytuacji wyścigowych i konfliktów.
Im lepiej twoje operacje są w stanie pracować z danymi „EC”, tym łatwiej jest oddzielić te systemy. Prostym przykładem jest hurtownia danych używana przez sprzedaż. Używają DW do sporządzania codziennych raportów, ale sporządzają je dopiero wczesnym rankiem i zawsze patrzą na dane „wczorajsze” (lub wcześniejsze). Nie ma więc potrzeby w czasie rzeczywistym, aby DW było idealnie spójne z codziennym systemem operacyjnym. Całkowicie dopuszczalne jest, aby proces był uruchamiany, powiedzmy, pod koniec dnia roboczego i przemieszczał się w ciągu dni, masowo transakcje i działania w ramach jednej dużej, pojedynczej operacji aktualizacji.
Możesz zobaczyć, jak ten wymóg może rozwiązać wiele problemów. Nie ma sporu o dane transakcyjne, nie ma obaw, że niektóre dane raportu ulegną zmianie w trakcie gromadzenia statystyk, ponieważ raport wykonał dwa oddzielne zapytania do aktywnej bazy danych. Nie ma potrzeby, aby szczegółowe rozmowy pochłaniały przetwarzanie sieci i procesora itp. w ciągu dnia.
To ekstremalny, uproszczony i bardzo toporny przykład EC.
Ale rozważ duży system, taki jak Google. Jako konsument wyszukiwarki nie mamy pojęcia, kiedy i ile czasu zajmuje uzyskanie wyniku wyszukiwania, który Google zbiera do pozycji na stronie wyszukiwania. 1ms? 1s? 10s? 10 godzin? Łatwo sobie wyobrazić, że jeśli trafisz na serwery Google's West Coast, możesz uzyskać inny wynik wyszukiwania, niż jeśli trafisz na ich serwery East Coast. W żadnym momencie te dwa przypadki nie są całkowicie spójne. Ale w dużej mierze są one w większości spójne. A w przypadku ich użycia, ich konsumenci nie są tak naprawdę dotknięci opóźnieniem i opóźnieniem.
Rozważ e-mail. A chce wysłać wiadomość do B, ale w trakcie tego procesu wiadomość jest kierowana przez systemy C, D i E. Każdy system akceptuje wiadomość, przejmuje za nią całkowitą odpowiedzialność, a następnie przekazuje ją innemu. Nadawca widzi, że wiadomość e-mail jest w drodze. Odbiorca tak naprawdę tego nie tęskni, ponieważ niekoniecznie wie, że nadchodzi. Tak więc istnieje duże okno czasu, które może zająć, aby wiadomość przeszła przez system, a nikt nie wiedział ani nie dbał o to, jak szybko jest.
Z drugiej strony A mógł rozmawiać przez telefon z B. „Właśnie to wysłałem, już go dostałeś? Teraz? Teraz? Pobierz teraz?”
W związku z tym istnieje pewien ukryty, dorozumiany poziom wydajności i reakcji. W końcu „ostatecznie” skrzynka nadawcza A pasuje do skrzynki odbiorczej B.
Te opóźnienia, akceptacja nieaktualnych danych, niezależnie od tego, czy są sprzed jednego dnia, czy sprzed 1-5 lat, kontrolują ostateczne sprzężenie systemów. Im luźniejsze jest to wymaganie, tym luźniejsze jest złącze i tym większa elastyczność, którą masz do dyspozycji w zakresie projektowania.
Dotyczy to aż do rdzeni w twoim procesorze. Nowoczesne, wielordzeniowe, wielowątkowe aplikacje działające w tym samym systemie mogą mieć różne widoki „tych samych” danych, nieaktualnych tylko o mikrosekundy. Jeśli Twój kod może działać poprawnie z danymi potencjalnie niespójnymi ze sobą, to szczęśliwego dnia. Jeśli nie, musisz zwrócić szczególną uwagę, aby upewnić się, że Twoje dane są całkowicie spójne, używając technik, takich jak kwalifikacja pamięci ulotnej lub konstrukcje blokujące itp. Wszystko to na swój sposób obniża wydajność.
To jest więc podstawa. Wszystkie inne decyzje zaczynają się tutaj. Odpowiedź na to pytanie może powiedzieć, jak podzielić aplikacje na różne maszyny, jakie zasoby są udostępniane i jak są udostępniane. Jakie protokoły i techniki są dostępne do przenoszenia danych i ile będzie kosztować przetwarzanie w celu wykonania transferu. Replikacja, równoważenie obciążenia, udostępnianie danych itp. Wszystko oparte na tej koncepcji.
Edytuj w odpowiedzi na pierwszy komentarz.
Dokładnie. Gra tutaj, na przykład, jeśli B nie może zmienić danych klienta, to jaka jest szkoda ze zmienionymi danymi klienta? Czy można „zaryzykować” to, że przez krótki czas będzie nieaktualny? Być może dane Twoich klientów napływają na tyle wolno, że możesz je natychmiast zreplikować z punktu A do punktu B. Powiedzmy, że zmiana jest umieszczana w kolejce, która z powodu małego wolumenu jest łatwo odbierana (<1 s), ale mimo to byłaby „poza transakcją” z pierwotną zmianą, więc jest małe okno, w którym A musiałby dane, których B nie ma.
Teraz umysł naprawdę zaczyna się kręcić. Co się dzieje podczas tych 1 sekund "lagu", jaki jest najgorszy możliwy scenariusz. I czy możesz wokół tego zaprojektować? Jeśli potrafisz zaprojektować z opóźnieniem 1 s, możesz być w stanie zaprojektować z opóźnieniem około 5 s, 1 m lub nawet dłuższym. Ile danych klientów faktycznie wykorzystujesz w B? Maybe B to system zaprojektowany w celu ułatwienia kompletacji zamówień z magazynu. Trudno sobie wyobrazić coś więcej, niż tylko identyfikator klienta i być może imię i nazwisko. Po prostu coś, co rażąco identyfikuje, dla kogo zamówienie jest składane.
System kompletacji niekoniecznie musi drukować wszystkie informacje o kliencie do samego końca procesu kompletacji, a do tego czasu zamówienie może zostać przeniesione do innego systemu, który być może jest bardziej aktualny, zwłaszcza w zakresie informacji o wysyłce, więc w końcu system kompletacji nie potrzebuje prawie żadnych danych klienta. W rzeczywistości można WBUDOWAĆ i zdenormalizować informacje o kliencie w zleceniu pobrania, dzięki czemu nie ma potrzeby ani oczekiwania na późniejszą synchronizację. Dopóki identyfikator klienta jest poprawny (która i tak nigdy się nie zmieni) oraz nazwa (która zmienia się tak rzadko, że nie warto omawiać tego), jest to jedyne prawdziwe odniesienie, którego potrzebujesz, a wszystkie twoje potwierdzenia wyboru są idealnie dokładne w momencie tworzenie.
Sztuczka polega na sposobie myślenia, polegającym na rozbiciu systemów i skupieniu się na podstawowych danych, które są niezbędne do wykonania zadania. Dane, których nie potrzebujesz, nie muszą być replikowane ani synchronizowane. Ludzie irytują się takimi rzeczami, jak denormalizacja i redukcja danych, zwłaszcza gdy pochodzą ze świata relacyjnego modelowania danych. I nie bez powodu należy podchodzić do tego ostrożnie. Ale kiedy zostaniesz rozprowadzony, domyślnie się denormalizujesz. Heck, kopiujesz to teraz hurtowo. Więc równie dobrze możesz być mądrzejszy.
Wszystko to można złagodzić dzięki solidnym procedurom i dokładnemu zrozumieniu przepływu pracy. Zidentyfikuj zagrożenia i opracuj zasady i procedury, aby sobie z nimi poradzić.
Ale najtrudniejszą częścią jest przerwanie łańcucha do centralnej bazy danych na początku i poinstruowanie ludzi, że nie mogą „mieć wszystkiego”, czego mogą oczekiwać, gdy masz jeden, centralny, idealny magazyn informacji.
