Czy bazy danych zorientowane na dokumenty zostały opracowane jako następna generacja baz danych i zasadniczo całkowicie zastępują relacyjne bazy danych?
Nie. Bazy danych zorientowane na dokumenty (takie jak MongoDB) są bardzo dobre w tego typu zadaniach, które zwykle spotykamy w nowoczesnych witrynach internetowych (szybkie wyszukiwanie pojedynczych elementów lub małych zestawów elementów).
Ale robią duże kompromisy z systemami relacyjnymi. Bez takich rzeczy jak zgodność z ACID nie będą w stanie zastąpić niektórych RDBMS. A jeśli spojrzysz na systemy takie jak MongoDB, brak zgodności z ACID jest ważnym powodem, dla którego jest to tak szybkie.
Czy to możliwe, że w projektach lepiej byłoby używać zarówno bazy danych zorientowanej na dokumenty, jak i relacyjnej bazy danych obok różnych danych, które lepiej pasują do jednego lub drugiego?
Tak. W rzeczywistości prowadzę bardzo dużą witrynę produkcyjną, która używa obu. System został uruchomiony w MySQL, ale przenieśliśmy jego część do MongoDB, ponieważ potrzebujemy magazynu Key-Value, a MySQL po prostu nie jest zbyt dobry w znajdowaniu jednego elementu w 150 milionach rekordów.
Jeśli bazy danych zorientowane na dokumenty nie mają zastąpić relacyjnych baz danych, to czy ktoś ma przykład struktury bazy danych, która byłaby absolutnie lepsza w relacyjnej bazie danych (lub odwrotnie)?
Bazy danych zorientowane na dokumenty świetnie przechowują dane, które są łatwo zawarte w „klucz-wartość” i prostych, liniowych relacjach „nadrzędny-podrzędny”. Proste przykłady to takie rzeczy jak blogi i wiki.
Jednak relacyjne bazy danych nadal mają silną pozycję w takich sprawach, jak raportowanie, które zwykle jest „oparte na zestawach”.
Szczerze mówiąc, widzę świat, w którym większość danych jest „obsługiwana” przez bazę danych zorientowaną na dokumenty, ale raportowanie odbywa się w relacyjnej bazie danych, która jest aktualizowana przez zadania Map-reduce.
