NoSQL- dobre praktyki, spójność danych

0

Postanowiłem trochę się poduczyć z NoSQL- wybór padł na RavenDB jeśli to ma znaczenie. Problem w tym że ciężko mi znaleźć jakieś konkretne materiały na temat stosowania dobrych praktych w aplikacjach opartych na NoSQL, jeszcze lepiej na przykładzie jakiejś konkretnej domeny. Napotkałem wieloktronie opinie aby unikać skomplikowanych relacji- co oczywiście ma sens, w końcu od tego są relacyjne bazy danych- ale już ze świecą szukać więcej szczegółów na ten temat. Kiedy pozwalać sobie na tworzenie relacji, a kiedy trzymać wszystko w jednym dokumencie? Jak utrzymać spójność danych jeśli każdy dokument będzie miał swoją kopię- np. obiektu Person- i nazwisko osoby się zmieni? Chyba jeszcze nadal mentalnie siedzę w modelu relacyjnym bo dla mnie kwalifikuje się to do stworzenia oddzielnego dokumentu Person i nie martwienie się tym że obiekt ten może się zmienić skoro wszystkie inne dokumenty będą miały do niego tylko referencję.

Są tu jakieś osoby obcykane w NoSQL? Byłbym wdzięczny za wyjaśnienie lub linki do dobrych materiałów.

3

Z książek mogę polecić stare dobre darmowe microsoftowe z serii patterns & practises:

Data Access for Highly-Scalable Solutions: Using SQL, NoSQL, and Polyglot Persistence.
CQRS Journey

Pierwsza skupia się właśnie na zastosowaniu w praktyce NoSql, a druga na projekcie systemu rozproszonego w oparciu o nosql źródła danych, gdzie sporo miejsca jest właśnie poświęconego ewentualnej spójności i jak ją osiągnąć.

0
Aventus napisał(a):

Postanowiłem trochę się poduczyć z NoSQL- wybór padł na RavenDB jeśli to ma znaczenie
.....

Są tu jakieś osoby obcykane w NoSQL? Byłbym wdzięczny za wyjaśnienie lub linki do dobrych materiałów.

Witam wszystkich, jeśli tu się wita. :)

ktoś tu już pytał, dlaczego RavenDB ...
Z bazami NoSQL jest tak jak z kolorem NieZielonym. Słowo IMHO jest bardziej medialne czy marketingowe, niż techniczne. To taki parasol który okrywa bardzo różne rzeczy: klucz-wartość, kolumnowe, dokumentowe, In Memory gridy itd ...
W pierwotnym sensie nawet nie miało tego znaczenia, że chodzi o b.d. podatne na (wszelkie) clustrowanie/rozpraszanie (za angielską Wikipedią)

Więc spróbujmy myśleć oddzielnie przynajmniej o pewnych rodzinach baz NoSQL

0

Hej,
wybór Twój ma znaczenie, ponieważ jest najprawdopodobniej związany z C#... Generalnie w NoSQL technologiach zastępuje się tabele z relacjami (czyli relacyjne bazy danych) innymi strukturami danych... mogą to być na przykład słowniki... lub na przykład struktury grafowe... Dla większej ilości danych może to mieć kolosalne znaczenie, bo jak wiemy dostęp do elementów w słowniku jest dość szybki... Co do materiałów, które także być może odpowiedzą ciut na Twoje pytania:

  1. Looknij może na 2.10, 2.11, 2.12, 2.13 w załączniku (sensowna pracka)...
  2. https://www.coursera.org/learn/mongodb-aggregation-framework/ (co prawda to MongoDB, ale idea tworzenia objektów NoSQL podobna)...

PS. żeby nie było, ja się na tym dobrze nie znam... ale umiem czytać, szukać, całkiem nieźle łączyć fakty, i tematyka Big Data nie jest mi zupełnie obca... :)

0
Aventus napisał(a):

[...] Jak utrzymać spójność danych jeśli każdy dokument będzie miał swoją kopię- np. obiektu Person- i nazwisko osoby się zmieni?

To nie jest dobry przykład. Dane dokumentu i tak muszą mieć stare nazwisko, bo nie możesz zmienić treści dokumentu. A to, że w bazie będziesz miał 2 tabele i połączysz je przez id - to nic nie szkodzi. W bazach nosql też mogą być relacje, tylko dostęp do nich będzie z reguły trudniejszy. Bardziej będą to relacje po stronie klienta niż bazy danych. Wyszukiwanie odbywa się przede wszystkim po kluczu głównym.

Dane często się dubluje w wielu tabelach. Wręcz projekuje się tabela per ekran. Największym utrudnieniem jest brak transakcji. Trzeba to przewidzieć na etapie projektowania bazy. To tyle, co zapamiętałem ze szkolenia z Cassandry.

1 użytkowników online, w tym zalogowanych: 0, gości: 1