Przechodzenie do społeczności za pomocą usługi Azure Cosmos DB

DOTYCZY: Nosql Mongodb Cassandra Gremlin Tabeli

Życie w niezwykle połączonym społeczeństwie oznacza, że w pewnym momencie życia stajesz się częścią sieci społecznej. Używasz sieci społecznościowych, aby skontaktować się z przyjaciółmi, kolegami, rodziną lub czasami dzielić się swoją pasją z ludźmi ze wspólnymi zainteresowaniami.

Jako inżynierowie lub deweloperzy mogli się zastanawiać, jak te sieci przechowują i łączą ze sobą dane. Możesz nawet mieć zadanie utworzenia lub utworzenia nowej sieci społecznościowej dla konkretnego rynku niszowego. Wtedy pojawia się istotne pytanie: Jak są przechowywane wszystkie te dane?

Załóżmy, że tworzysz nową i błyszczącą sieć społecznościową, w której użytkownicy mogą publikować artykuły z powiązanymi mediami, takimi jak zdjęcia, filmy, a nawet muzyka. Użytkownicy mogą komentować wpisy i udzielać punktów oceny. Będzie dostępny kanał informacyjny wpisów, z którymi użytkownicy będą widzieć stronę docelową głównej witryny internetowej i korzystać z niej. Ta metoda nie brzmi na początku, ale ze względu na prostotę zatrzymajmy się tam. (Możesz zagłębić się w niestandardowe kanały informacyjne użytkowników, których dotyczą relacje, ale wykracza poza cel tego artykułu).

Jak więc przechowywać te dane i gdzie?

Być może masz doświadczenie w bazach danych SQL lub masz pojęcie modelowania relacyjnego danych. Możesz zacząć rysować coś w następujący sposób:

Diagram illustrating a relative relational model

Idealnie znormalizowana i ładna struktura danych... to nie skaluje.

Nie pomylij się, przez całe życie pracowałem z bazami danych SQL. Są świetne, ale jak każdy wzorzec, praktyka i platforma oprogramowania nie jest idealny dla każdego scenariusza.

Dlaczego usługa SQL nie jest najlepszym wyborem w tym scenariuszu? Przyjrzyjmy się strukturze pojedynczego wpisu. Gdybym chciał wyświetlić wpis w witrynie internetowej lub aplikacji, musiałbym wykonać zapytanie z... łącząc osiem tabel (!) tylko po to, aby pokazać jeden wpis. Teraz obraz strumienia wpisów, które dynamicznie ładują się i pojawiają na ekranie, i możesz zobaczyć, gdzie idę.

Możesz użyć ogromnego wystąpienia SQL z wystarczającą mocą, aby rozwiązać tysiące zapytań z wieloma sprzężeniami, aby obsłużyć zawartość. Ale dlaczego, gdy istnieje prostsze rozwiązanie?

Droga NoSQL

Ten artykuł zawiera instrukcje dotyczące modelowania danych platformy społecznościowej przy użyciu bazy danych NoSQL platformy Azure w usłudze Azure Cosmos DB w sposób ekonomiczny. Informuje również, jak używać innych funkcji usługi Azure Cosmos DB, takich jak interfejs API dla języka Gremlin. Korzystając z podejścia NoSQL, przechowywania danych w formacie JSON i stosowania denormalizacji, wcześniej skomplikowany wpis można przekształcić w pojedynczy dokument:

{
    "id":"ew12-res2-234e-544f",
    "title":"post title",
    "date":"2016-01-01",
    "body":"this is an awesome post stored on NoSQL",
    "createdBy":User,
    "images":["https://myfirstimage.png","https://mysecondimage.png"],
    "videos":[
        {"url":"https://myfirstvideo.mp4", "title":"The first video"},
        {"url":"https://mysecondvideo.mp4", "title":"The second video"}
    ],
    "audios":[
        {"url":"https://myfirstaudio.mp3", "title":"The first audio"},
        {"url":"https://mysecondaudio.mp3", "title":"The second audio"}
    ]
}

Można go uzyskać za pomocą pojedynczego zapytania i bez sprzężeń. To zapytanie jest znacznie proste i proste, a budżet wymaga mniejszej liczby zasobów, aby uzyskać lepszy wynik.

Usługa Azure Cosmos DB zapewnia, że wszystkie właściwości są indeksowane za pomocą automatycznego indeksowania. Automatyczne indeksowanie można nawet dostosować. Podejście bez schematu umożliwia przechowywanie dokumentów z różnymi i dynamicznymi strukturami. Może jutro chcesz, aby posty miały listę kategorii lub hashtagów skojarzonych z nimi? Usługa Azure Cosmos DB będzie obsługiwać nowe dokumenty z dodanymi atrybutami bez dodatkowej pracy wymaganej przez nas.

Komentarze do wpisu mogą być traktowane jako inne wpisy z właściwością nadrzędną. (Ta praktyka upraszcza mapowanie obiektów).

{
    "id":"1234-asd3-54ts-199a",
    "title":"Awesome post!",
    "date":"2016-01-02",
    "createdBy":User2,
    "parent":"ew12-res2-234e-544f"
}

{
    "id":"asd2-fee4-23gc-jh67",
    "title":"Ditto!",
    "date":"2016-01-03",
    "createdBy":User3,
    "parent":"ew12-res2-234e-544f"
}

Wszystkie interakcje społecznościowe mogą być przechowywane w osobnym obiekcie jako liczniki:

{
    "id":"dfe3-thf5-232s-dse4",
    "post":"ew12-res2-234e-544f",
    "comments":2,
    "likes":10,
    "points":200
}

Tworzenie kanałów informacyjnych to tylko kwestia tworzenia dokumentów, które mogą zawierać listę identyfikatorów postów z daną kolejnością istotności:

[
    {"relevance":9, "post":"ew12-res2-234e-544f"},
    {"relevance":8, "post":"fer7-mnb6-fgh9-2344"},
    {"relevance":7, "post":"w34r-qeg6-ref6-8565"}
]

Możesz mieć strumień "najnowszy" z wpisami uporządkowanymi według daty utworzenia. Możesz też mieć "najgorętszy" strumień z tymi wpisami z większą ilością polubień w ciągu ostatnich 24 godzin. Można nawet zaimplementować niestandardowy strumień dla każdego użytkownika na podstawie logiki, takiej jak obserwatorzy i zainteresowania. Nadal byłaby to lista wpisów. Jest to kwestia sposobu kompilowania tych list, ale wydajność odczytu pozostaje niezakłócona. Po uzyskaniu jednej z tych list należy wysłać pojedyncze zapytanie do usługi Azure Cosmos DB przy użyciu słowa kluczowego IN w celu pobrania stron wpisów naraz.

Strumienie kanału informacyjnego można tworzyć przy użyciu procesów w tle usług aplikacja systemu Azure Services: Webjobs. Po utworzeniu wpisu przetwarzanie w tle można wyzwolić przy użyciu kolejek usługi Azure Storagei zadań Webjob wyzwalanych przy użyciu zestawu SDK usługi Azure Webjobs, implementując propagację postów wewnątrz strumieni opartych na własnej logice niestandardowej.

Punkty i polubień nad postem można przetworzyć w sposób odroczony przy użyciu tej samej techniki, aby utworzyć ostatecznie spójne środowisko.

Obserwatorzy są bardziej podstępni. Usługa Azure Cosmos DB ma limit rozmiaru dokumentu, a odczytywanie/zapisywanie dużych dokumentów może mieć wpływ na skalowalność aplikacji. Możesz więc myśleć o przechowywaniu obserwujących jako dokumencie o tej strukturze:

{
    "id":"234d-sd23-rrf2-552d",
    "followersOf": "dse4-qwe2-ert4-aad2",
    "followers":[
        "ewr5-232d-tyrg-iuo2",
        "qejh-2345-sdf1-ytg5",
        //...
        "uie0-4tyg-3456-rwjh"
    ]
}

Ta struktura może działać dla użytkownika z kilkoma tysiącami obserwujących. Jeśli jednak niektóre gwiazdy dołączą do szeregów, takie podejście doprowadzi do dużego rozmiaru dokumentu i może ostatecznie osiągnąć limit rozmiaru dokumentu.

Aby rozwiązać ten problem, możesz użyć podejścia mieszanego. W ramach dokumentu Statystyki użytkowników możesz przechowywać liczbę obserwujących:

{
    "id":"234d-sd23-rrf2-552d",
    "user": "dse4-qwe2-ert4-aad2",
    "followers":55230,
    "totalPosts":452,
    "totalPoints":11342
}

Rzeczywisty graf obserwujących można przechowywać przy użyciu interfejsu API usługi Azure Cosmos DB dla języka Gremlin, aby utworzyć wierzchołki dla każdego użytkownika i krawędzi, które utrzymują relacje "A-follow-B". Za pomocą interfejsu API dla języka Gremlin możesz uzyskać obserwatorów określonego użytkownika i utworzyć bardziej złożone zapytania, aby sugerować typowe osoby. Jeśli dodasz do grafu kategorie zawartości, które osoby lubią lub lubią, możesz zacząć tkać środowiska, które obejmują inteligentne odnajdywanie zawartości, sugerując zawartość, którą obserwujesz, lub znajdując osoby, które mogą być często używane.

Dokument Statystyka użytkownika może być nadal używany do tworzenia kart w interfejsie użytkownika lub w szybkich podglądach profilów.

Wzorzec "Drabina" i duplikowanie danych

Jak można zauważyć w dokumencie JSON odwołującym się do wpisu, istnieje wiele wystąpień użytkownika. I odgadnąć dobrze, te duplikaty oznaczają, że informacje opisujące użytkownika, biorąc pod uwagę tę denormalizację, mogą być obecne w więcej niż jednym miejscu.

Aby umożliwić szybsze wykonywanie zapytań, duplikujesz dane. Problem z tym skutkiem ubocznym jest to, że jeśli w wyniku jakiejś akcji zmiany danych użytkownika, musisz znaleźć wszystkie działania, które kiedykolwiek zrobił użytkownik i zaktualizować je wszystkie. Nie brzmi praktyczne, prawda?

Rozwiążesz ten problem, identyfikując kluczowe atrybuty użytkownika wyświetlanego w aplikacji dla każdego działania. Jeśli wizualnie wyświetlasz wpis w aplikacji i wyświetlasz tylko nazwę i obraz twórcy, dlaczego przechowujesz wszystkie dane użytkownika w atrybucie "createdBy"? Jeśli dla każdego komentarza po prostu wyświetlisz obraz użytkownika, nie potrzebujesz reszty informacji użytkownika. To tam coś, co nazywam "Wzór drabiny" staje się zaangażowany.

Przyjrzyjmy się informacjom o użytkowniku jako przykładowi:

{
    "id":"dse4-qwe2-ert4-aad2",
    "name":"John",
    "surname":"Doe",
    "address":"742 Evergreen Terrace",
    "birthday":"1983-05-07",
    "email":"john@doe.com",
    "twitterHandle":"\@john",
    "username":"johndoe",
    "password":"some_encrypted_phrase",
    "totalPoints":100,
    "totalPosts":24
}

Patrząc na te informacje, możesz szybko wykryć, które informacje są krytyczne i które nie są, tworząc w ten sposób "Drabinę":

Diagram of a ladder pattern

Najmniejszy krok jest nazywany fragmentem UserChunk, minimalnym elementem informacji identyfikującym użytkownika i używanym do duplikowania danych. Zmniejszenie zduplikowanego rozmiaru danych tylko do informacji, które będą wyświetlane, zmniejsza możliwość ogromnych aktualizacji.

Środkowy krok jest nazywany użytkownikiem. To pełne dane, które będą używane w przypadku większości zapytań zależnych od wydajności w usłudze Azure Cosmos DB, najbardziej używanych i krytycznych. Zawiera on informacje reprezentowane przez element UserChunk.

Największy jest użytkownik rozszerzony. Zawiera on krytyczne informacje o użytkowniku i inne dane, które nie muszą być odczytywane szybko lub mają ostateczne użycie, takie jak proces logowania. Te dane mogą być przechowywane poza usługą Azure Cosmos DB w tabelach usługi Azure SQL Database lub Azure Storage.

Dlaczego podzielisz użytkownika, a nawet zapiszesz te informacje w różnych miejscach? Ze względu na to, że z punktu widzenia wydajności większe dokumenty są bardziej kosztowne zapytania. Zachowaj szczupłe dokumenty z odpowiednimi informacjami, aby wykonywać wszystkie zapytania zależne od wydajności dla twojej sieci społecznościowej. Przechowuj inne dodatkowe informacje dla scenariuszy ostatecznej, takich jak pełne edycje profilu, dane logowania i wyszukiwanie danych na potrzeby analizy użycia i inicjatyw związanych z danymi big data. Naprawdę nie obchodzi Cię, czy zbieranie danych na potrzeby wyszukiwania danych jest wolniejsze, ponieważ działa w usłudze Azure SQL Database. Masz jednak obawy, że użytkownicy mają szybkie i szczupłe doświadczenie. Użytkownik przechowywany w usłudze Azure Cosmos DB wygląda następująco:

{
    "id":"dse4-qwe2-ert4-aad2",
    "name":"John",
    "surname":"Doe",
    "username":"johndoe"
    "email":"john@doe.com",
    "twitterHandle":"\@john"
}

Post będzie wyglądać następująco:

{
    "id":"1234-asd3-54ts-199a",
    "title":"Awesome post!",
    "date":"2016-01-02",
    "createdBy":{
        "id":"dse4-qwe2-ert4-aad2",
        "username":"johndoe"
    }
}

Gdy pojawi się edycja, gdy ma to wpływ na atrybut fragmentu, można łatwo znaleźć dokumenty, których dotyczy problem. Wystarczy użyć zapytań wskazujących indeksowane atrybuty, takie jak SELECT * FROM posts p WHERE p.createdBy.id == "edited_user_id", a następnie zaktualizować fragmenty.

Użytkownicy będą generować, na szczęście, dużo zawartości. I powinno być możliwe zapewnienie możliwości wyszukiwania i znajdowania zawartości, która może nie znajdować się bezpośrednio w ich strumieniach zawartości, być może dlatego, że nie obserwujesz twórców, a może po prostu próbujesz znaleźć ten stary wpis, który zrobiłeś sześć miesięcy temu.

Ponieważ używasz usługi Azure Cosmos DB, możesz łatwo zaimplementować wyszukiwarkę przy użyciu usługi Azure AI Search w ciągu kilku minut bez wpisywania kodu innego niż proces wyszukiwania i interfejs użytkownika.

Dlaczego ten proces jest tak łatwy?

Usługa Azure AI Search implementuje to, co nazywają indeksatory, procesy w tle, które są przyłączające się do repozytoriów danych i automatycznie dodają, aktualizują lub usuwają obiekty w indeksach. Obsługują one indeksatory usługi Azure SQL Database, indeksatory obiektów blob platformy Azure i na szczęście indeksatory usługi Azure Cosmos DB. Przejście informacji z usługi Azure Cosmos DB do usługi Azure AI Search jest proste. Obie technologie przechowują informacje w formacie JSON, więc wystarczy utworzyć indeks i zamapować atrybuty z dokumentów, które mają być indeksowane. I już! W zależności od rozmiaru danych cała zawartość będzie dostępna do wyszukania w ciągu kilku minut przez najlepsze rozwiązanie Search-as-a-Service w infrastrukturze chmury.

Aby uzyskać więcej informacji na temat usługi Azure AI Search, możesz odwiedzić przewodnik po wyszukiwaniu hitchhikera.

Podstawowa wiedza

Po przechowywaniu całej tej zawartości, która rośnie i rośnie każdego dnia, możesz pomyśleć: Co mogę zrobić ze wszystkim strumieniem informacji od moich użytkowników?

Odpowiedź jest prosta: Umieść ją, aby pracować i uczyć się od niej.

Ale czego można się nauczyć? Kilka prostych przykładów to analiza tonacji, rekomendacje dotyczące zawartości oparte na preferencjach użytkownika, a nawet zautomatyzowany con tryb namiotu rator, który zapewnia bezpieczeństwo zawartości opublikowanej przez twoją sieć społecznościową.

Teraz, gdy cię podłączyłeś, prawdopodobnie myślisz, że potrzebujesz doktoratu w nauce matematycznej, aby wyodrębnić te wzorce i informacje z prostych baz danych i plików, ale byłoby źle.

Azure Machine Edukacja to w pełni zarządzana usługa w chmurze, która umożliwia tworzenie przepływów pracy przy użyciu algorytmów w prostym interfejsie przeciągania i upuszczania, kodowanie własnych algorytmów w języku R lub używanie niektórych już utworzonych i gotowych do użycia interfejsów API, takich jak: analiza tekstu, Content Moderator lub Rekomendacje.

Aby osiągnąć dowolny z tych scenariuszy usługi Machine Edukacja, możesz użyć usługi Azure Data Lake do pozyskiwania informacji z różnych źródeł. Możesz również użyć języka U-SQL, aby przetworzyć informacje i wygenerować dane wyjściowe, które mogą być przetwarzane przez usługę Azure Machine Edukacja.

Inną dostępną opcją jest użycie usług sztucznej inteligencji platformy Azure do analizowania zawartości użytkowników, a nie tylko lepsze zrozumienie ich (analizowanie tego, co piszą za pomocą interfejsu API analiza tekstu), ale także wykrywanie niepożądanej lub dojrzałej zawartości i odpowiednie działanie przy użyciu interfejsu API przetwarzanie obrazów. Usługi azure AI obejmują wiele wbudowanych rozwiązań, które nie wymagają żadnej wiedzy Edukacja maszyny do użycia.

Środowisko społeczne na skalę planety

Istnieje ostatni, ale nie tylko ważny artykuł muszę rozwiązać: skalowalność. Podczas projektowania architektury każdy składnik powinien być skalowany samodzielnie. W końcu trzeba będzie przetworzyć więcej danych lub mieć większy zasięg geograficzny. Na szczęście osiągnięcie obu zadań jest kluczem do użycia w usłudze Azure Cosmos DB.

Usługa Azure Cosmos DB obsługuje partycjonowanie dynamiczne gotowe do użycia. Automatycznie tworzy partycje na podstawie danego klucza partycji, który jest definiowany jako atrybut w dokumentach. Definiowanie poprawnego klucza partycji należy wykonać w czasie projektowania. Aby uzyskać więcej informacji, zobacz Partycjonowanie w usłudze Azure Cosmos DB.

W przypadku środowiska społecznościowego należy dostosować strategię partycjonowania do sposobu wykonywania zapytań i pisania. (Na przykład operacje odczytu w ramach tej samej partycji są pożądane i unikaj "punktów aktywnych", rozkładając zapisy na wiele partycji). Niektóre opcje to: partycje oparte na kluczu czasowym (dzień/miesiąc/tydzień), według kategorii zawartości, według regionu geograficznego lub użytkownika. To wszystko naprawdę zależy od tego, jak będziesz wykonywać zapytania o dane i wyświetlać dane w środowisku społecznościowym.

Usługa Azure Cosmos DB będzie uruchamiać zapytania (w tym agregacje) we wszystkich partycjach w sposób niewidoczny, więc nie trzeba dodawać żadnej logiki w miarę wzrostu danych.

Wraz z upływem czasu w końcu zwiększysz ruch, a użycie zasobów (mierzone w jednostkach RU lub jednostki żądań) zwiększy się. Będziesz odczytywać i zapisywać częściej w miarę wzrostu bazy użytkowników. Baza użytkowników zacznie tworzyć i odczytywać więcej zawartości. Dlatego możliwość skalowania przepływności jest niezbędna. Zwiększenie liczby jednostek RU jest łatwe. Możesz to zrobić za pomocą kilku kliknięć w witrynie Azure Portal lub wydając polecenia za pośrednictwem interfejsu API.

Scaling up and defining a partition key

Co się stanie, jeśli rzeczy będą coraz lepsze? Załóżmy, że użytkownicy z innego kraju/regionu lub kontynentu zauważają platformę i zaczynają z niej korzystać. Co za wielkie zaskoczenie!

Ale czekaj! Wkrótce zdajesz sobie sprawę, że ich doświadczenie z platformą nie jest optymalne. Są tak daleko od regionu operacyjnego, że opóźnienie jest straszne. Oczywiście nie chcesz, aby rzucili. Jeśli tylko nie było łatwego sposobu rozszerzania zasięgu globalnego? Nie ma!

Usługa Azure Cosmos DB umożliwia globalne i przejrzyste replikowanie danych za pomocą kilku kliknięć i automatyczne wybieranie spośród dostępnych regionów z kodu klienta. Ten proces oznacza również, że można mieć wiele regionów trybu failover.

Podczas replikacji danych globalnie należy upewnić się, że klienci mogą z niej korzystać. Jeśli używasz frontonu internetowego lub uzyskujesz dostęp do interfejsów API z klientów mobilnych, możesz wdrożyć usługę Azure Traffic Manager i sklonować usługę aplikacja systemu Azure we wszystkich żądanych regionach, używając konfiguracji wydajności do obsługi rozszerzonego zasięgu globalnego. Gdy klienci uzyskują dostęp do frontonu lub interfejsów API, zostaną przekierowani do najbliższej usługi App Service, która z kolei połączy się z lokalną repliką usługi Azure Cosmos DB.

Adding global coverage to your social platform

Podsumowanie

Ten artykuł rzuca pewne światło na alternatywy tworzenia sieci społecznościowych całkowicie na platformie Azure z usługami o niskich kosztach. zapewnia wyniki, zachęcając do korzystania z wielowarstwowego rozwiązania magazynu i dystrybucji danych o nazwie "Drabina".

Diagram of interaction between Azure services for social networking

Prawda jest taka, że nie ma srebrnej kuli dla tego rodzaju scenariuszy. Jest to synergia stworzona przez połączenie wspaniałych usług, które pozwalają nam tworzyć wspaniałe środowiska: szybkość i wolność usługi Azure Cosmos DB w celu zapewnienia doskonałej aplikacji społecznościowej, analizy rozwiązania do wyszukiwania najwyższej klasy, takiego jak azure AI Search, elastyczność aplikacja systemu Azure Usługi do hostowania nie tylko aplikacji niezależnie od języka, ale zaawansowanych procesów w tle oraz rozszerzalnych usług Azure Storage i Azure SQL Database do przechowywania ogromnych ilości danych i analitycznej mocy usługi Azure Machine Edukacja do tworzenia wiedzy i analizy, która może przekazywać opinie do Twoich procesów i pomagać nam dostarczać odpowiednią zawartość odpowiednim użytkownikom.

Następne kroki

Aby dowiedzieć się więcej na temat przypadków użycia usługi Azure Cosmos DB, zobacz Typowe przypadki użycia usługi Azure Cosmos DB.