Separacja odczytu i zapisu
Gdy działalność firmy nadal się rozwija, a liczba użytkowników znacznie wzrasta, oryginalna baza danych prawdopodobnie nie będzie w stanie się utrzymać. To tak
- Scale-in, który zwiększa wydajność sprzętu, ale prawdopodobnie liczba użytkowników będzie nadal rosła, a zwiększona wydajność wkrótce zostanie zniknięta.
- Rozdzielenie odczytu i zapisu: Baza danych nie jest w stanie się utrzymać, to nic innego jak zbyt dużo czytania i zapisu, zwłaszcza jeśli pojawiają się złożone zapytania, takie jak najpopularniejsze produkty w ciągu ostatnich 24 godzin. Wymaga bardzo skomplikowanych instrukcji SQL i oczywiście działa wolno.
Jednak aby oddzielić czytanie i zapisy, baza danych musi być podzielona na biblioteki główne i podrzędne.
Główne relacyjne bazy danych na rynku obsługują replikację danych, więc można podzielić bazę danych na dwie role: master i slave, pisać operacje na masterze oraz synchronizować serwer master z innymi serwerami slave.
Operacje offline, takie jak operacje odczytu i analiza danych, są wykonywane na serwerze podrzędnym.
Wiemy, że wiele aplikacji w Internecie jest czytanych, aby wiele podrzędnych użytkowników mogło dzielić obciążenie i zapewnić dostępność oraz poprawność danych.
Jednak odpowiadający mu oryginalny kod aplikacji również wymaga modyfikacji i musi zostać zmieniony, aby używać biblioteki głównej do zapisu danych oraz używać biblioteki podrzędnej podczas odczytu danych, co jest równoważne przepisywaniu.
Zapytania złożone
Jednak nawet po przepisaniu kodu zauważyłem, że wydajność nie poprawiła się znacząco, ponieważ użyto zbyt wielu złożonych zapytań, a w komponencie bazy danych powiedzieliśmy, że łączenia są bardzo wydajne.
Czy możemy użyć osobnej tabeli do przechowywania popularnych produktów z ostatnich 24 godzin, tak że wystarczy użyć prostego SQL?
Innymi słowy, pojedynczy zestaw tabel bazy danych nie nadaje się do różnych zachowań, takich jak raporty, wyszukiwania, transakcje itp.
Obecna tabela została zaprojektowana do dodawania i modyfikowania danych i nie nadaje się do złożonych zapytań.
Musimy jednak również rozważyć, jak ta baza zapytań jest aktualizowana, czy możemy tolerować to opóźnienie, czy może nie być aktualizowana w czasie rzeczywistym.
CQRS
Czy opóźnienie jest tolerowane, należy ocenić z perspektywy biznesowej, na przykład popularne najlepsze produkty w ciągu ostatnich 24 godzin – trochę przestarzałe informacje nie mają większego znaczenia, potrzebna jest jedynie ostateczna spójność.
Możemy użyć CQRS (Command Query Responsibility Segregation), czyli oddzielenia poleceń do dodawania lub modyfikowania poleceń od zadań zapytań.
W CQRS nacisk kładzie się na rozdzielenie odczytu (Query) i zapisu (Command), ponieważ dane odczytywane przez użytkowników są zazwyczaj przestarzałe, więc po co czytać z bazy danych, można bezpośrednio ustanowić źródło danych odczytu. Może to być Cache, XML, JSON itd.
Jak rozwiązać wspomniany wcześniej problem aktualizacji związany z aktualizacją? Możesz użyć Zdarzenia, czyli zdarzenia, na przykład gdy produkt zostanie sprzedany, możesz opublikować zdarzenie, aby zmodyfikować oryginalny model odczytu.
W ten sposób synchronizacja staje się asynchroniczna poprzez mechanizm zdarzeń.
Wreszcie, metoda ta najlepiej sprawdza się tylko w przypadku złożonych zapytań, a oryginalne proste zapytania są nadal pobierane w relacyjnej bazie danych. Dlaczego? Ponieważ wprowadzenie nowej technologii wymaga ceny, takiej jak synchroniczne kroki mutacji i mechanizmy zdarzeń, nie możemy dostrzegać tylko zalet nowych technologii, a nie tylko wad.
|
Opublikowano 04.05.2020 09:58:50
|
|
|
|
