Już pewnie wiesz, że w chmurach lubię wszystko co jest PaaS, a już naprawdę uwielbiam usługi, które pozwalają Ci budować rozwiązania o dowolnej skali i dużej wydajności. Taką usługą bez wątpienia jest Azure Document DB czy też od konferencji MS Build 2017 Azure Cosmo DB.
Zaraz, zaraz…. czyżby to oznaczało, że tak po prostu, tak bez wysiłku załadujesz swoje dane i już?
Tak będzie ale najpierw przeczytaj moich 5 rad i zastosuj je w swoim projekcie.
1. Bazy dokumentowe (albo NoSQL) to zupełnie inny świat rozwiązań niż bazy relacyjne. KROPKA.
Tu nie ma relacji, nie ma narzuconej struktury, nie ma kluczy głównych. Zapomnij też o widokach. Skalowalne funkcje agregujące dopiero co się pojawiły a język zapytań jest jeszcze ograniczony. O różnicach pomiędzy bazami dokumentowymi a relacyjnymi pisałem na drugim blogu. Jednym zdaniem, jeśli Twoja aplikacja przechowuje dane typowo relacyjne i nie wpada w żaden z rekomendowanych scenariuszy użycia to Cosmo DB nie jest bazą dla Ciebie. Serio. Nie czytaj dalej. Inaczej, będziesz tak jak ja migrował rozwiązanie do Azure SQL czy innych rozwiązań 🙂
2. Partycjonować czy nie partycjonować?
Można oczywiście nie, ale jeśli chcesz napisać kolejną grę typu Walking Dead albo przechowywać > 10 GB danych, to odpowiedź jest tylko jedna, partycjonować. Dzięki temu twoja baza będzie miała praktycznie nie ograniczoną wielkość, nie ograniczoną wydajność i w dodatku będziesz mógł ją replikować po całym świecie. Zachęcam Cię byś przeczytał ten artykuł i wybrał dobrze klucz partycjonujący dla siebie. Aha… jeśli tego nie napisałem, to zmiana z jednego modelu na drugi… wymaga migracji. „Taką mamy bazę”. Co więcej, w modelu bazy podzielonej na partycje, operacje (odczyt, zapis) domyślnie działają w ramach jednej partycji. Jeśli ma być inaczej, użyj Cross Query.
3. Cosmo DB to baza o tzw. z góry określonej wydajności.
Nie dbasz o procesory, pamięć, dysk a jedynie mówisz ile jednostek RU potrzebujesz na sekundę. Co ciekawe, baza ma taką samą, stałą wydajność niezależnie od wielkości bazy, ilości akcji itd. A górnego limitu RU praktycznie nie ma. Każda operacja (odczyt, zapis, zmiana, ect.) kosztuje Cię pewną ilość jednostek RU i dopóki nie przekroczysz określonego przez siebie limitu RU na sekundę, jesteś po bezpiecznej stronie mocy. Posłuchaj tego wprowadzenia, na pewno zrozumiesz model działania. Po szczegóły i odpowiedni kalkulator, który podpowie Ci, ile budżetu zarezerwować na utrzymanie bazy, zapraszam tutaj.
Ważne. Jeśli nie podzieliłeś swojej bazy na partycję to Twój limit RU wynosi 10 000. Jeśli podzieliłeś to dopiero przy 250 000 zaczynasz się martwić i pisać do supportu o zwiększenie.
4. Wybór poziomu spójności czyli „consistency level” to nasze kolejne zadanie.
Cosmo DB oferuje aż 5 różnych poziomów, z czego najczęściej wybierany to „Session Consistency”. Zanim zdecydujesz, przeczytaj o nich. To naprawdę dobre wprowadzenie. To jedna z niewielu baz na rynku, która ma aż tak szeroki model spójności, gwarantowanych komercyjnie i objętych SLA.
Dlaczego to takie ważne? Im większa spójność tym niższa wydajność i wyższe koszty zapytań. Im mniejszy poziom spójności, tym wydajność bazy jest większa. Po prostu wydasz więcej swoich RU. Jeśli nie wiesz, który poziom dobrać, zacznij od domyślnego czyli Session Consistency, zmiana tego poziomu jest zawsze możliwa.
5. A na koniec polecam Ci świetny wpis kolegów z grupy produktowej o tym, jak osiągać maksymalną wydajność bazy.
Jeśli nie masz czasu na wszystkie detale, przeczytaj sekcje Networking i SDK Usage, będziesz zaskoczony jak wiele mogą zmienić:)
Na dziś zostawiam Cię z tymi 5 poradami. Nie wszystko od razu. Jeśli przebrniesz przez te, w kolejnym wpisie opowiem Ci jeszcze o indeksowaniu, które pozwoli ci przyspieszyć Twoje zapytanie 60 razy, testowaniu wydajności, backupie, raportach i automatyzacji.
PS. Chcesz zobaczyć jedno z największy wdrożeń Azure Cosmo DB na świecie? Polecam grę Walking Dead.