Przeznaczenie nierelacyjnych baz danych

Witam
Ostatnio po raz pierwszy miałem przyjemność zobaczyć z czym się je nierelacyjna baza danych (MongoDB). Zamiast pojęcia relacji/encji/tabeli mam 'dokument'. Interesujący jest sposób przechowywania informacji, mianowicie mogę sobie w ramach jednego bytu (dokumentu) mogę sobie stworzyć różnych atrybutów lub tablicę wewnątrz. Jest to wygodne bo nie muszę tworzyć nie wiadomo ile związków z innymi tabelami. Lub nie przechowywać wartości NULL dla konkretnej krotki, która nie posiada danego atrybutu.

Jednakże interesuje mnie doświadczenie ludzi, którzy pracują z takimi bazami. Mianowicie chciałbym poszerzyć swoją wiedzę. Mam kilka pytań

1. Jakie jest przeznaczenie tych baz > - otóż (tak mi się wydaje) wszystko co można umieścić w nierelacyjnej bazie danych da radę przenieść do relacyjnej bazy. Odwrotnie niekoniecznie.
2. Czy pomiędzy bytami ('dokumentami') są jakieś związki ? Czy można je stworzyć ? Czy to dobry tok myślenia ?
3. O ile dobrze pamiętam na studiach uczono mnie o obiektowych bazach danych - czy zatem bazy NoSQL są klasyfikowane jako bazy obiektowe ?

Pozdrawiam

NoSQL, "nierelacyjne bazy danych" to dość ogólne i mało precyzyjne terminy.
Podałeś przykład Mongo, które jest bazą dokumentową, ale nie każda baza nierelacyjna jest bazą dokumentową. Pakowanie ich do jednego worka mija się z celem. A skokro bazy są różne, to i przeznaczenie jest różne.

Inne przeznaczenie ma ElasticSearch, inne Cassandra, inne Hadoop, a jeszcze inne Titan.

Po co tyle różnych baz?
Ano w model relacyjny da się wiele wcisnąć, ale do pewnych rzeczy nadaje się słabo. Lepiej wziąć bazę, która jest dopasowana do modelu danych i rodzaju zapytań, które będziemy na tych danych robić. Jak potrzebujesz wyszukiwania pełnotekstowego w dużych dokumentach, to MongoDB czy PostgreSQL sobie z tym słabo poradzi, ale rozwiązania pokroju DSE Search, ElasticSearch czy nawet zwykły Solr bedą znacznie wydajniejsze i zaoferują znacznie większe możliwości, bo po prostu do tego zostały stworzone. Tak samo modelowanie sieci społecznościowej i np. liczenie czegoś w rodzaju PageRank będzie łatwiejsze i szybsze w bazie grafowej niż dzierganie tego ręcznie na relacjach.

A, i żeby nie było tak prosto, wiele baz oryginalnie opatrzonych etykietką NoSQL jest tak naprawdę bardzo blisko baz relacyjnych, jeśli chodzi o model danych. W tym przypadku główne różnice są np. w podejściu do dostępności i skalowania vs spójność danych. Tradycyjnie systemy relacyjne cenią sobie spójność danych ponad wszystko, bardzo utrudniając (lub wręcz uniemożliwiając) skalowalność i wysoką dostępność, natomiast NoSQLe zwykle są projektowane w pierwszej kolejności z myślą o wysokiej dostępności, skalowalności, odporności na awarie itp, a mechanizmy utrzymania spójności danych są raczej dodatkiem i gwarantują znacznie mniej niż w systemach relacyjnych. Z tego też powodu raczej nie obsługują wprost złączeń (bo się nie skalują), i wymuszają na programiście takie modelowanie danych, aby niepotrzebne były złączenia. W zamian oferują elastyczniejszy model danych, więc tam gdzie w relacyjnej bazie miałbyś 3 tabelki, w nierelacyjnej będziesz miał jedną z jakimiś zagnieżdżeniami.

Cassandra operuje na modelu relacyjnym z pewnymi rozszerzeniami, na których operuje się czymś bardzo zbliżonym składniowo do SQLa, jedynie wprost nie oferuje wszystkich operatorów relacyjnych. Jak się ktoś uprze, to uruchomi na tym Hive'a albo SparkSQL i ma relacyjną bazę danych do celów analitycznych. Jakaś forma ograniczonych transakcji rozproszonych też jest wspierana. A np. FoundationDB obsługuje transakcje ACID i SQL.