W NoSQL:gdyby tylko to było takie proste autor pisze o MongoDB:
MongoDB nie jest magazynem klucz/wartość, to coś więcej. To zdecydowanie nie jest też RDBMS. Nie używałem MongoDB w produkcji, ale wykorzystałem go trochę do budowania aplikacji testowej i jest to bardzo fajny zestaw. Wydaje się, że jest bardzo wydajny i albo ma, albo wkrótce będzie miał, odporność na błędy i auto-sharding (czyli będzie się skalować). Myślę, że Mongo może być najbliższym zamiennikiem RDBMS, jaki do tej pory widziałem. Nie będzie działać ze wszystkimi zestawami danych i wzorcami dostępu, ale jest stworzona z myślą o typowych rzeczach CRUD. Przechowywanie tego, co jest zasadniczo ogromnym haszem, i możliwość wyboru dowolnego z tych kluczy, to jest to, do czego większość ludzi używa relacyjnej bazy danych. Jeśli twoja baza danych to 3NF i nie robisz żadnych złączeń (po prostu wybierasz kilka tabel i łączysz wszystkie obiekty razem, czyli to, co większość ludzi robi w aplikacji internetowej), MongoDB prawdopodobnie kopnie tyłki ty.
Następnie na zakończenie:
Prawdziwą rzeczą, na którą należy zwrócić uwagę, jest to, że jeśli powstrzymuje Cię przed zrobieniem czegoś super niesamowitego, ponieważ nie możesz wybrać bazy danych, robisz to źle. Jeśli znasz mysql, po prostu go użyj. Optymalizuj, kiedy naprawdę tego potrzebujesz. Używaj go jak sklepu k/v, używaj go jak rdbms, ale na miłość boską, zbuduj swoją zabójczą aplikację! Nic z tego nie będzie miało znaczenia dla większości aplikacji. Facebook nadal często używa MySQL. Wikipedia często używa MySQL. FriendFeed często korzysta z MySQL. NoSQL to świetne narzędzie, ale z pewnością nie zapewni Ci przewagi konkurencyjnej, nie sprawi, że Twoja aplikacja będzie gorąca, a przede wszystkim Twoi użytkownicy nie będą się tym przejmować.
Na czym zbuduję następną aplikację? Prawdopodobnie Postgres. Czy będę używać NoSQL? Być może. Mogę też użyć Hadoopa i Hive. Mogę trzymać wszystko w płaskich plikach. Może zacznę hakować na Maglevie. Będę używał wszystkiego, co najlepsze do pracy. Jeśli potrzebuję raportowania, nie będę używał żadnego NoSQL. Jeśli potrzebuję buforowania, prawdopodobnie użyję Tokyo Tyrant. Jeśli potrzebuję ACIDity, nie użyję NoSQL. Jeśli potrzebuję mnóstwa liczników, użyję Redis. Jeśli potrzebuję transakcji, użyję Postgresa. Jeśli mam mnóstwo dokumentów jednego typu, prawdopodobnie użyję Mongo. Gdybym musiał pisać miliard przedmiotów dziennie, prawdopodobnie użyłbym Voldemorta. Jeśli potrzebuję wyszukiwania pełnotekstowego, prawdopodobnie użyłbym Solr. Jeśli potrzebuję pełnotekstowego wyszukiwania danych ulotnych, prawdopodobnie użyłbym Sphinxa.
Podoba mi się ten artykuł, uważam go za bardzo pouczający, daje dobry przegląd krajobrazu i szumu NoSQL. Ale i to jest najważniejsza część, naprawdę pomaga zadać sobie właściwe pytania, jeśli chodzi o wybór między RDBMS a NoSQL. Warto przeczytać IMHO.
