SQL (MySQL) vs NoSQL (CouchDB) [zamknięte]

Jestem w trakcie projektowania wysoce skalowalnej aplikacji, która musi przechowywać dużo danych. Na przykład będzie przechowywać wiele informacji o użytkownikach, a następnie wiele ich wiadomości, komentarzy itp. Wcześniej zawsze korzystałem z MySQL, ale teraz mam zamiar wypróbować coś nowego, jak couchdb lub coś podobnego, co nie jest SQL.

Czy ktoś ma jakieś przemyślenia lub wskazówki na ten temat?

Oto cytat z ostatniego posta na blogu Dare Obasanjo .

Bazy danych SQL są podobne do transmisji automatycznej, a bazy danych NoSQL - do transmisji ręcznej. Po przejściu na NoSQL stajesz się odpowiedzialny za wiele pracy, którą system wykonuje automatycznie w systemie relacyjnych baz danych. Podobnie jak w przypadku wybrania skrzyni manualnej zamiast automatycznej. Po drugie, NoSQL pozwala wydobyć z systemu większą wydajność, eliminując wiele testów integralności wykonywanych przez relacyjne bazy danych z warstwy bazy danych. Ponownie, jest to podobne do tego, jak można uzyskać lepsze osiągi z samochodu, jeżdżąc z manualną skrzynią biegów w porównaniu z pojazdem z automatyczną skrzynią biegów.

Jednak najbardziej zauważalnym podobieństwem jest to, że podobnie jak większość z nas nie może tak naprawdę wykorzystać zalet pojazdu z ręczną skrzynią biegów, ponieważ większość naszej jazdy odbywa się w korku na drodze do iz pracy, istnieje podobna trudna rzeczywistość. ponieważ większość witryn nie jest w skali Google ani Facebooka, a zatem nie ma potrzeby korzystania z Bigtable lub Cassandra.

Do czego mogę dodać tylko to, że przejście z MySQL, gdzie masz przynajmniej pewne doświadczenie, na CouchDB, gdzie nie masz doświadczenia, oznacza, że ​​będziesz musiał poradzić sobie z zupełnie nowym zestawem problemów i nauczyć się różnych koncepcji i najlepszych praktyk. Chociaż samo w sobie jest to wspaniałe (gram w domu z MongoDB i bardzo to lubię), będzie to koszt, który trzeba obliczyć, szacując pracę nad tym projektem, i niesie ze sobą nieznane ryzyko, obiecując jednocześnie nieznane korzyści. Bardzo trudno będzie ocenić, czy uda Ci się wykonać projekt na czas iz jakością, którą chcesz / potrzebujesz, aby odnieść sukces, jeśli jest oparty na technologii, której nie znasz.

Teraz, jeśli masz w zespole eksperta w dziedzinie NoSQL, to koniecznie przyjrzyj się temu. Ale bez doświadczenia w zespole nie wskakuj na NoSQL w nowym projekcie komercyjnym.

Aktualizacja : Aby wrzucić trochę benzyny do rozpalonego ognia, oto dwa interesujące artykuły od ludzi z obozu SQL. :-)

I Can't Wait for NoSQL to Die (oryginalny artykuł zniknął, oto kopia )
Walka z nastawieniem NoSQL, chociaż to nie jest
aktualizacja fragmentu anty-NoSQL : Cóż, tutaj jest interesujący artykuł o NoSQL
Making Sense of NoSQL

Wydaje się, że obecnie tylko prawdziwe rozwiązania obracają się wokół skalowania lub fragmentowania. Wszystkie nowoczesne bazy danych (NoSQL i NewSQL) obsługują skalowanie poziome zaraz po wyjęciu z pudełka, w warstwie bazy danych, bez potrzeby, aby aplikacja miała fragment kodu lub coś w tym rodzaju.

Niestety, w przypadku zaufanego, starego, dobrego MySQL, fragmentowanie nie jest dostarczane „po wyjęciu z pudełka”. ScaleBase (zastrzeżenie: tam pracuję) jest producentem kompletnego rozwiązania skalowalnego w poziomie, „automatycznej maszyny do dzielenia fragmentów”, jeśli chcesz. ScaleBae analizuje dane i strumień SQL, dzieli je na węzły DB i agreguje w czasie wykonywania - więc nie musisz! Do pobrania za darmo.

Nie zrozum mnie źle, NoSQL są świetne, są nowe, nowe to większy wybór, a wybór zawsze dobry !! Ale wybór NoSQL ma swoją cenę, upewnij się, że możesz ją zapłacić ...

Możesz zobaczyć tutaj więcej danych o MySQL, NoSQL ...: http://www.scalebase.com/extreme-scalability-with-mongodb-and-mysql-part-1-auto-sharding

Mam nadzieję, że to pomogło.

Jedną z najlepszych opcji jest wybranie MongoDB (NOSql dB), który obsługuje skalowalność, przechowuje duże ilości danych, tylko bigdata w postaci dokumentów w przeciwieństwie do wierszy i tabel w sql. aby zapewnić gwarancję danych, która utrzymuje wiele serwerów z podstawowym serwerem db jako bazą. Niezależny od języka. Elastyczny w użyciu