Nosql a relacje

0

Czy w momencie keidy zaczynamy myslec o modelu naszych danych , dostrzegamy koniecznosc wprowadzenia relacji, jest to znak ze w naszym use case nosql nie ma sensu? Z drugiej strony czy nie jestesmy 'wyuczeni' myslec relacyjnie i koniec koncow mozemy sie obejsc bez tego? Czy jestescie w stanie wyznaczyc granice kiedy uzyc sql a kiedy nosql(mogno). Pisze sobie projekt po godzinach i chce w nim uzyc mogno (i uzyje) jednak ciagle mysle relacyjnie i nie wiem czy dobrym podejsicem jest porzucenie tego typu myslenia i myslec o tym bardziej w kategoraich ... kompozycji? Wtedy wpedzam sie w jeden wielki obiekt user , ktory ma wszystko, i n stopni zagniezdzenia obiektow (user ma projectlist ktora ma projekty, ktore z kolei maja rysunki , ktore maja liste ...)

0

Zaznaczam że ekspertem od mongo nie jestem, ale z tego co kojarzę to mongo wspiera jakieś pseudo relacje, z wyjątkiem 'many to many' bo to faktycznie może tworzyć problemy przy dużej liczbie. Więc samo tworzenie relacji w mongo chyba raczej dużym błędem nie jest.

0

W 99% jak zaczynasz projekt NoSQL nie ma sensu. SQLa używasz tak długo jak Ci starcza (a uwierz, starcza na długo). Jak przestaje Ci starczać to wtedy dopiero szukasz innych rozwiązań lub piszesz własne. I tak powstaje nowy NoSQL.

A jak potrzebujecie swobodnej struktury danych to użycie Postgresa i JSONB.

0

Lekcja na dziś: Polyglot persistence

1

Iloma terabajtami będziecie operować, że myślicie o NoSQL już na etapie projektowania? I jeśli już musicie używać NoSQL, to na Peruna niech to nie będzie MongoDB - trochę stary wpis, ale na początek researche'u wystarcza. Polecam Apache Cassandre, czasem mam wrażenie, że jest niezniszczalna i to nie tylko moje wrażenie. Minusem może być to, że trzeba wiedzieć jak dbać o JVM na produkcji, ale to niewielki koszt za przewidywalną bazę.

1

Pytanie podstawowe - co nazywasz "relacjami"?

4
several napisał(a):

Iloma terabajtami będziecie operować, że myślicie o NoSQL już na etapie projektowania?

Często nie chodzi o terabajty. Czasami ważniejsze są:

  • odporność na awarię, brak centralizacji
  • dostępność 24/7 np. aktualizacja systemu bazy bez zatrzymywania systemu
  • kontrola nad rozproszeniem geograficznym / replikacją danych (czasami dla spełnienia wymogów prawnych)
  • minimalne opóźnienia
  • wydajność zapisów liczona w setkach tysięcy na sekundę na serwer
  • niezarzynanie SSD
  • analityka danych operacyjnych bez zabijania systemu "real-time" (bez ETL), izolowane różnych rodzajów ruchu

To są wszystko rzeczy z którymi dobre noSQLe radzą sobie zwykle o wiele lepiej niż RDBMSy.

0
somekind napisał(a):

Pytanie podstawowe - co nazywasz "relacjami"?

mowiac relacje mam na mysli to ze jeden obiekt np User ma liste obiektow Projekt i wtedy powstaje relacja one to many.

2

W nomenklaturze baz danych mówisz o krotnościach encji, w nomenklaturze OOA&D o asocjacjach. Relacja to coś zupełnie innego.

1

To, że będziesz miał relacje (nie mylić ze związkami encji z ERD i asocjacjami UML) to naturalne, bo w życiu między pojęciami takowe występują :)

Baza to tylko składowisko danych. Są istotne różnice między relacyjnymi, a NoSQLowymi (np. pojęcie klucza obcego czy transakcyjności). Nic jednak nie stoi na przeszkodzie, żeby dane utrwalać w jednym czy drugim typie bazy danych. Stosując OOAD + bazy relacyjne pewnie skończysz z jakimś Object-Relational Mapperem (np. Hibernate), zaś korzystając z NoSQLowej bazy pewnie sam napiszesz sobie takiego Object-to-NoSQL mappera (nie wiem, ale pewnie są jakieś gotowce).

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