Strukturyzowanie danych
W tym przewodniku omawiamy niektóre kluczowe pojęcia związane z architekturą danych oraz sprawdzone metody tworzenia struktury danych JSON w Firebase Realtime Database.
Tworzenie odpowiednio uporządkowanej bazy danych wymaga sporo przemyślenia. Najważniejsze jest zaplanowanie sposobu zapisywania i późniejszego pobierania danych, aby proces ten był jak najprostszy.
Jaka jest struktura danych: drzewo JSON
Wszystkie dane Firebase Realtime Database są przechowywane jako obiekty JSON. Można wyobrazić ją w postaci drzewa JSON hostowanego w chmurze. W przeciwieństwie do bazy danych SQL nie ma w niej tabel ani rekordów. Gdy dodasz dane do drzewa JSON, staną się one węzłem w dotychczasowej strukturze JSON z powiązanym kluczem. Możesz podać własne klucze, takie jak identyfikatory użytkowników lub nazwy semantyczne, albo możesz je otrzymać za pomocą metody Push().
Jeśli tworzysz własne klucze, muszą być one zakodowane w standardzie UTF-8, mogą mieć maksymalnie 768 bajtów i nie mogą zawierać znaków sterujących ., $, #, [, ], / ani znaków sterujących ASCII 0–31 ani 127. W wartościach nie można też używać znaków kontrolnych ASCII.
Weźmy na przykład aplikację do czatu, która umożliwia użytkownikom przechowywanie podstawowego profilu i listy kontaktów. Typowy profil użytkownika znajduje się w ścieżce, np. /users/$uid. Użytkownik alovelace może mieć w bazie danych wpis o takiej treści:
{ "users": { "alovelace": { "name": "Ada Lovelace", "contacts": { "ghopper": true }, }, "ghopper": { ... }, "eclarke": { ... } } }
Chociaż baza danych korzysta z drzewa JSON, dane przechowywane w bazie danych mogą być reprezentowane jako określone typy natywne, które odpowiadają dostępnym typom JSON, aby ułatwić pisanie bardziej łatwego w utrzymaniu kodu.
Sprawdzone metody dotyczące struktury danych
Unikaj zagnieżdżania danych
Ponieważ Firebase Realtime Database umożliwia zagnieżdżanie danych na 32 poziomach, możesz pomyśleć, że to powinna być domyślna struktura. Jeśli jednak pobierasz dane z lokalizacji w bazie danych, pobierane są też wszystkie jego węzły podrzędne. Ponadto, gdy przyznasz komuś dostęp do odczytu lub zapisu w węźle w bazie danych, przyznasz mu też dostęp do wszystkich danych w tym węźle. Dlatego w praktyce najlepiej jest, aby struktura danych była jak najbardziej płaska.
Oto przykład takiej struktury:
{ // This is a poorly nested data architecture, because iterating the children // of the "chats" node to get a list of conversation titles requires // potentially downloading hundreds of megabytes of messages "chats": { "one": { "title": "Historical Tech Pioneers", "messages": { "m1": { "sender": "ghopper", "message": "Relay malfunction found. Cause: moth." }, "m2": { ... }, // a very long list of messages } }, "two": { ... } } }
W przypadku takiej zagnieżchłej struktury przechodzenie przez dane staje się problematyczne. Na przykład wyświetlanie tytułów rozmów na czacie wymaga pobrania na klienta całego drzewa chats, w tym wszystkich użytkowników i wiadomości.
Spłaszczanie struktur danych
Jeśli zamiast tego dane zostaną podzielone na oddzielne ścieżki (zwane też denormalizacją), można je w razie potrzeby efektywnie pobrać w osobnych wywołaniach. Rozważ tę spłaszczoną strukturę:
{ // Chats contains only meta info about each conversation // stored under the chats's unique ID "chats": { "one": { "title": "Historical Tech Pioneers", "lastMessage": "ghopper: Relay malfunction found. Cause: moth.", "timestamp": 1459361875666 }, "two": { ... }, "three": { ... } }, // Conversation members are easily accessible // and stored by chat conversation ID "members": { // we'll talk about indices like this below "one": { "ghopper": true, "alovelace": true, "eclarke": true }, "two": { ... }, "three": { ... } }, // Messages are separate from data we may want to iterate quickly // but still easily paginated and queried, and organized by chat // conversation ID "messages": { "one": { "m1": { "name": "eclarke", "message": "The relay seems to be malfunctioning.", "timestamp": 1459361875337 }, "m2": { ... }, "m3": { ... } }, "two": { ... }, "three": { ... } } }
Można teraz przeglądać listę pokojów przez pobieranie zaledwie kilku bajtów na rozmowę, a także szybko pobierać metadane na potrzeby wyświetlania informacji o pokojach lub wyświetlania ich w interfejsie. Wiadomości można pobierać osobno i wyświetlać w miarę ich przychodzenia, dzięki czemu interfejs pozostaje responsywny i szybki.
Tworzenie skalujących danych
Podczas tworzenia aplikacji często lepiej jest pobrać podzbiór listy. Dzieje się tak zwłaszcza wtedy, gdy lista zawiera tysiące rekordów. Gdy ta relacja jest statyczna i jednokierunkowa, możesz po prostu zagnieździć obiekty podrzędne pod obiektem nadrzędnym.
Czasami ta relacja jest bardziej dynamiczna lub konieczne może być zdenormalizowanie tych danych. Często możesz zdenormalizować dane, używając zapytania do pobrania podzbioru danych, jak opisano w artykule Pobieranie danych.
Ale nawet to może nie wystarczyć. Rozważ na przykład dwukierunkową relację między użytkownikami i grupami. Użytkownicy mogą należeć do grupy, a grupy zawierają listę użytkowników. Gdy przychodzi czas na określenie, do których grup należy użytkownik, sprawy się komplikują.
Potrzebny jest do tego elegancki sposób na wyświetlanie listy grup, do których należy użytkownik, oraz pobieranie tylko danych dotyczących tych grup. Indeks grup może bardzo pomóc:
// An index to track Ada's memberships { "users": { "alovelace": { "name": "Ada Lovelace", // Index Ada's groups in her profile "groups": { // the value here doesn't matter, just that the key exists "techpioneers": true, "womentechmakers": true } }, ... }, "groups": { "techpioneers": { "name": "Historical Tech Pioneers", "members": { "alovelace": true, "ghopper": true, "eclarke": true } }, ... } }
Możesz zauważyć, że część danych jest duplikowana, ponieważ przechowuje ona relację zarówno w rekordzie Ady, jak i w grupie. Teraz alovelace jest indeksowany w ramach grupy, a techpioneers jest wymieniony w profilu Ada. Aby usunąć Adę z grupy, trzeba ją zaktualizować w 2 miejscach.
Jest to konieczna nadmiarowość w przypadku relacji dwukierunkowych. Umożliwia to szybkie i wydajne pobieranie członkostw Ada, nawet gdy lista użytkowników lub grup obejmuje miliony elementów lub gdy Realtime Database zasady bezpieczeństwa uniemożliwiają dostęp do niektórych rekordów.
Takie podejście, polegające na odwróceniu danych przez podanie identyfikatorów jako kluczy i ustawienie wartości na „prawda”, sprawia, że sprawdzenie klucza jest tak proste jak odczytanie wartości /users/$uid/groups/$group_id i sprawdzenie, czy jest to null. Indeks jest szybszy i znacznie wydajniejszy niż skanowanie lub wysyłanie zapytań do danych.