Jak uporządkować relacje w Azure Cosmos DB?

głosy
0

Mam dwa zestawy danych w tej samej kolekcji w kosmosie, jedno są „posty”, a druga to „użytkownicy”, są one połączone stanowisk utworzonych przez użytkowników.

Obecnie mój struktura przedstawia się następująco;

// user document
{
id: 123,
postIds: ['id1','id2']
}

// post document
{
id: 'id1',
ownerId: 123
}
{
id: 'id2',
ownerId: 123
}

Moim głównym problemem z tej konfiguracji jest zmienny charakter niego, kod musi egzekwować link i czy jest jakiś bug dane będą bardzo łatwo zgubić bez wyraźnego sposób, aby ją odzyskać.

Jestem również zaniepokojony wydajność, jeśli użytkownik posiada 10.000 posty to 10.000 wyszukiwań muszę zrobić, aby rozwiązać wszystkie posty ..

Czy to prawidłowa metoda modelowania związków encji?

Utwórz 19/12/2018 o 14:09
źródło użytkownik
W innych językach...                            


1 odpowiedzi

głosy
2

Jak powiedział David, to długa dyskusja, ale jest to bardzo często jeden tak, ponieważ mam na godzinę lub tak „wolnego” czasu, jestem bardziej niż zadowolony, aby spróbować odpowiedzieć na to pytanie, raz na zawsze, mam nadzieję.

DLACZEGO normalizować?

Pierwszą rzeczą, którą zauważysz w swoim poście: szukasz pewnego poziomu integralność referencyjna ( https://en.wikipedia.org/wiki/Referential_integrity ), który jest coś, co jest potrzebne, gdy rozkładają większego obiektu do jego elementy składowe. Zwany także normalizacja.

Choć jest to zazwyczaj odbywa się w relacyjnej bazie danych, jest teraz coraz bardziej popularne również w nie-relacyjnej bazy danych, ponieważ bardzo pomaga uniknąć dublowania danych, która zazwyczaj tworzy więcej problemów niż to, co rozwiązuje.

https://docs.mongodb.com/manual/core/data-model-design/#normalized-data-models

Ale czy naprawdę potrzebny? Ponieważ nie wybrano do wykorzystania bazy dokumentów JSON, należy wykorzystać fakt, że jest w stanie przechowywać cały dokument, a następnie po prostu zapisać dokument wraz ze wszystkimi danymi właściciela: imię, nazwisko, lub wszystkie inne dane, które mają o użytkowniku który stworzył dokument. Tak, mówię, że możesz nie mieć ocenić post i użytkownika, ale tylko posty, z informacją użytkownika wewnątrz it.This może być rzeczywiście bardzo poprawne, a będziesz mieć pewność, aby uzyskać dokładne dane dla istniejącego użytkownika w momencie tworzenia postu. Powiedzieć na przykład utworzyć post i mam biografia „X”. I wtedy zaktualizować biografii na „Y” i utworzyć nowy post. Dwa post będzie mieć różne biografie autora i to jest w porządku, tak jak zostały one dokładnie ujęte rzeczywistość.

Oczywiście możesz również wyświetlać biografii w stronę autora. W tym przypadku będziemy mieli problem. Który z nich będziesz używać? Prawdopodobnie ostatni.

Jeśli wszyscy autorzy, aby istnieć w systemie, musi mieć blogu publikowane, które mogą okazać się za mało. Ale może chcesz mieć autor napisać jego biografię i są notowane w systemie, zanim jeszcze pisze na blogu.

W takim przypadku trzeba znormalizować modelu i utworzyć nowy typ dokumentu, tylko dla autorów. Jeśli jest to Twoja sprawa, to, trzeba także dowiedzieć się, jak handler sytuacji opisanej wcześniej. Gdy autor zaktualizuje własną biografię, po prostu zaktualizować dokument autor, lub utworzyć nowy? W przypadku utworzenia nowego, dzięki czemu można śledzić wszystkie zmiany, będzie również aktualizować cały poprzedni post tak, że będą odwoływać się do nowego dokumentu, czy nie?

Jak widać odpowiedź jest złożona i zależy od tego, jakie informacje chcesz uchwycić od realnego świata.

Więc przede wszystkim dowiedzieć się, czy naprawdę trzeba zachować postów i użytkowników oddzielone.

KONSYSTENCJA

Załóżmy, że chcesz mieć stanowisk i użytkowników przechowywane w oddzielnych dokumentach, a zatem znormalizować model. W tym przypadku należy pamiętać, że Kosmos DB (ale NoSQL w ogóle) bazy danych nie oferują wszelkiego rodzaju natywnym wsparciem wymusić więzy integralności, więc są prawie na własną rękę. Indeksy mogą pomóc, oczywiście, więc może chcesz indeksować właściwość ownerid, tak że przed usunięciem autora, na przykład, można skutecznie sprawdzić, czy są jakieś blogu wykonywana przez niego / niej, że pozostanie sierot inaczej. Inną opcją jest ręczne tworzenie i aktualizuje innego dokumentu, że dla każdego autora, śledzi blogach on / ona na piśmie. Dzięki takiemu podejściu można patrzeć tylko na tym dokumencie, aby zrozumieć, które blogi należą do autora. Można starać się utrzymać ten dokument uaktualniany przy użyciu wyzwalaczy, czy to w aplikacji. Wystarczy pamiętać, że kiedy normalizacji, w bazie danych NoSQL przechowywać dane zgodne jest odpowiedzialny. To jest dokładnie przeciwieństwem relacyjnej bazy danych, w której Twoim zadaniem jest, aby zachować spójność danych podczas de-normalizacji go.

WYSTĘPY

Wydajność może być problemem, ale zazwyczaj nie modelować w celu wspierania występy w pierwszej kolejności. Modelować, aby upewnić się, że model może reprezentować i przechowywać informacje potrzebne od realnego świata, a potem zoptymalizować go, aby mieć przyzwoitą wydajność z bazą danych masz zdecydował się użyć. Jako inna baza danych mają różne ograniczenia, model zostanie przystosowany do radzenia sobie z tym ograniczeń. To nic więcej i nic mniej, że stary dobry „logiczne” vs „fizyczne” modelowanie dyskusja.

W przypadku Cosmos DB, nie powinien mieć zapytań, które wykraczają przekrój partycji, ponieważ są one droższe.

Niestety partycjonowania jest coś wybrał raz na zawsze, tak naprawdę trzeba mieć jasne w swoim umyśle, co jest najczęstszym przypadkiem użycia chcesz wesprzeć w najlepsze. Jeśli większość zapytań są wykonywane na podstawie jednej autora, chciałbym podzielić za autora.

Teraz Choć może to wydaje się mądry wybór, to będzie tylko wtedy, gdy masz dużo autorów. Jeśli masz tylko jeden, na przykład, wszystkie dane i zapytania trafi do tylko jednej partycji, ograniczając wiele wydajność. Pamiętaj, że w rzeczywistości, że Kosmos DB RU są dzielone między wszystkich dostępnych partycji: z 10.000 RU, na przykład, zwykle dostać 5 partycji, co oznacza, że ​​wszystkie wartości zostaną rozłożone 5 partycji. Każda partycja będzie mieć górną granicę 2000 RU. Jeśli wszystkie zapytania używać tylko jedną partycję, twój prawdziwy maksymalna wydajność jest to, że 2000 a nie 10000 Kijowskiej.

Naprawdę mam nadzieję, że to pomoże Ci zacząć, aby dowiedzieć się odpowiedź. I mam nadzieję, że to pomoże, aby wspierać i rozwijać dyskusję (jak model na bazie dokumentu), które myślę, że jest naprawdę wymagalne i dojrzewają teraz.

Odpowiedział 03/01/2019 o 02:37
źródło użytkownik

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more