Cześć! To będzie drugi wpis na temat Document DB, który pozwoli Ci lepiej wykorzystać potencjał usługi. Jeśli nie widziałeś pierwszej części to zapraszam tutaj. Od konferencji Build 2017 Document DB nazywa się Cosmos DB. Niech jednak ta marketingowa zmiana nie przeszkodzi Ci by sprawdzić co w trawie piszczy 🙂
Wybranie odpowiednich indeksów to klucz to dobrej wydajności i niskich kosztów.
Po pierwsze warto wiedzieć jak działają indeksy w bazie Comsos DB. Temat nie jest banalny, bo działanie indeksu jest silnie uzależnione od typu spójności jaki ustawiłeś na bazie. Musisz to przeczytać i zrozumieć:)
Zanim zaczniesz modyfikować indeks…pomyśl:
- Jaki będzie wzorzec zapisywania, odczytywania czy aktualizacji danych w Twojej bazie?
- W szczególności po czym (jakich atrybutach) będziesz robił takie operacje jak Order By, Group By czy Where?
- Jaki poziom spójności jest Ci potrzebny – on szalenie wpłynie na wydajność Twojego indeksu. Jeśli nie wiesz o co mi chodzi, wróć tutaj.
Jeśli już znasz odpowiedzi to możesz planować swoje Index Policy. Na czym ja poległem?
- W dokumentach przechowywałem pozycje budynków na mapie. Następnie szukałem obiektów, które są najbliższe mojej lokalizacji lub w danej odległości od moje lokalizacji dzięki funkcji ST_DISTANCE. Bazując tylko na domyślnym indeksie koszt zapytania przekraczał 2300 RU, dodanie tylko typu indeksu SPATIAL jak niżej oszczędziło mi 97.5% kosztu zapytania i spadło do 66 RU. Nieźle prawda?
"includedPaths":
[
{
"path": "/*", "indexes":
[
{
"kind": "Range", "dataType": "String", "precision": -1
},
{
"kind": "Range", "dataType": "Number", "precision": -1
},
{
"kind":"Spatial", "dataType":"Point"
}
]
}
]
2. Drugi problem to tzw. Index Collision, czyli sytuacja kiedy Twój indeks jest ‚nieprecyzyjny’. U mnie dokument używa tej samej nazwy właściwości na dwóch różnych poziomach dokumentu. W przykładzie poniżej atrybut DataUtworzenia jest na poziomie Kategorie ale też PodKategorie.
Teraz, jeśli dodasz index na typy Date i będziesz pytał o atrybut DataUtworzenia na poziomie Kategorie i tak znajdą się w nim wszystkie elementy o nazwie DataUtworzenia. W moim przypadku pól DataUtworzenia na poziomie Kategorie było ponad 400, na poziomie niżej ponad 12tyś. Niezależnie o co pytałem, zawsze wykonywałem scan po indeksie w którym było 12tyś elementów. Koszt zapytania ponad 2500 RU.
Rozwiązanie? Wybranie unikalnej nazwy atrybutu, czas wykonania zapytania lekko ponad 60 RU. W przyszłości koledzy z grupy obiecali rozwikłać problem.
"Kategorie":
[
{
"Code":"",
"Name":"",
"Podkategorie":[
{
"DataUtworzenia":
{ "Date":"2015-08-11T16:24:20.5763546Z" },
},
{
"DataUtworzenia":
{ "Date":"2015-08-11T16:24:20.5763546Z" },
},
],
"id":"",
"TypDokumentu":"",
"DataUtworzenia":{ "Date":"2015-08-11T16:24:20.5763546Z"},
}
]
3. Zostańmy jeszcze chwilę w temacie wydajności zapytań. Kilka drobiazgów:
- Jeśli macie zmienną typu Boolean to w klauzuli ‚Where’ fraza d.IsClosed=true będzie szybsze niż d.IsClosed.
- Zamiast pisać d.TypeId!=1 lepiej napisać d.TypeId in (0,2,3)
Operacje, gdzie argumenty nie są podane wprost wykonują scan na bazie. Jeśli są podane wprost, baza wykorzysta index.
Kopia zapasowa zawsze się przyda. W końcu są dwa typy ludzi, którzy robią backup i będą robić:)
Ktoś może zapytać, ale po co ci kopia zapasowa skoro włączyłeś dla Cosmos DB replikację do innego ośrodka? Pół żartem, pół serio… na wypadek gdybym skasował bazę nie umyślnie, mój kod spowodował by błędne nadpisanie danych ect. Replika do drugiego ośrodka nie chroni przed błędem ludzkim :). Jeśli już wiesz po co mi backup, to w przypadku bazy Cosmos DB backup jest po prostu wbudowany w usługę i nie musicie sami o nim specjalnie pamiętać. Polecam artykuł, który wyjaśnia wszelkie szczegóły.
Co ciekawe, żeby ten backup odtworzyć, trzeba napisać lub zadzwonić do support’u ;). Dla sytuacji planowych taka procedura być może wystarczy. Jeśli jednak chcesz mieć na tym procesem 100% kontroli, to polecam Ci Data Factory, które wykona kopię bazy w ustalonym harmonogramie. Data Factory jest tanie i wygodne, a dla Document DB ma gotowy ‚connector’. Szczegóły znajdziesz tutaj.
W życiu każdej aplikacji jest taki dzień, że Analityk z tzw. biznesu przyjdzie i powie… daj mi raport. Raportowanie danych z DocumentDB w pierwszy kroku może wcale nie być takie oczywiste:)
Pojawia się kilka wyzwań. Dokumenty w jednej kolekcji mogą być różnego typu, dokumenty jednego typu mogą mieć różny schemat, dokument może zawierać w sobie kolekcje o różnej długości. Jeśli ktoś korzysta z Document DB wie o czym mówię.
Jeśli nie chcesz tracić czasu, przeczytaj ten artykuł . Sam szybko dojdziesz, że w ramach tworzonego raportu można napisać jeszcze query, które z kolekcji wyciągnie potrzebny element. W razie problemów, polecam właściciela bloga https://sql4you.info/, który wyjaśnił to nietechnicznemu analitykowi :). Dodatek do PowerBI dla DocumentDB jest już w GA a do tego sam PowerBI w wersji darmowej oferuje coraz więcej możliwości.
Automatyzacja, mechanizacja, devops, powershell, rest…
Kiedy zaczynałem rok temu z DocumentDB jedną opcją by utworzyć konto, potem bazę a na końcu kolekcję było klikanie w portal, REST lub C#. Dziś jest lepiej, mamy pierwsze komendy PowerShell. Jeśli jednak zależy Ci na szerszej automatyzacji to żądania REST zapisanie w Postmanie lub stare, dobre Consol App okażą się najlepsze i najszybsze.
O testowaniu wydajności swojej bazy i dostrajaniu indeksu można by napisać zapewne książkę.
Zachęcę Cię jednak jeszcze raz do rzucenia okiem na ten przykładowy kod. Pokazuje on jak podejść te przetestowania wydajności Twojej bazy jeśli już masz strukturę i choćby przykładowe dane. Jeśli tych przykładowych Ci brak, JSON Generator chętnie Ci pomoże. Mają wstępne zrozumienie wydajności Twojej bazy, już tylko krok dzieli Cię od poznania jej kosztu.
Słowo podsumowania
Jeśli poważnie podchodzisz do swojej aplikacji i chcesz wydajnie składować dane typu NoSQL, poświęć dłuższą chwilę na przeanalizowanie tych 10 krótkich porad. Gwarantuję Ci, że korzystanie z Cosmos DB okażę się przyjemnością… albo zrozumiesz, że NoSQL baza nie jest dla Ciebie 🙂 To będzie nawet bardziej wartościowe niż naginanie jej działania do scenariuszy, do których się nie nadaje.