skąd taki szał z MongoDB

Skąd k#$%a taki szał na MongoDB? Gadam z kumplem, mówi mi, że szukają webmastera ze znajomością MongoDB. Gadam z drugim kumplem, mówi że przechodzą w jego firmie w kluczowych serwisach na MongoDB. Ktoś inny, chwali się że w poprzedniej firmie to pracowali w MongoDB. W dupach im się poprzewracało, mysql stał się nudny, czy co?

Spotkałem się ostatnio z takim serwisem opartym o Node.js, Meteor.js oraz właśnie MongoDB. Mam tylko podstawową wiedzę z zakresu tej bazy, więc bardzo chciałbym również sam wiedzieć:

1. Jaki jest zakres zastosowań tejże bazy i w czym wygrywa z MySQL czy tam PostgreSQL?
2. Czy nie ma to przypadkiem ścisłego związku z również chyba modnymi technologiami typu Angular.js, Metor.js, NodeJS?
3. Czy też może jest to taki model biznesowy i te technologie są wybierane przez niektóre firmy zajmujące się realizacją webserwisów bazując na technologiach które mało kto zna, nie wiem może chodzi o ograniczenie albo pozbycie się konkurencji (tak żeby zapewnić sobie robotę przy dalszych pracach związanych z rozbudową serwisów)?
4. Czy też może wygrywa tu potrzeba biznesowa a chodzi o większe serwisy i duży ruch?

Czarny Krawiec napisał(a):

Skąd k#$%a taki szał na MongoDB? Gadam z kumplem, mówi mi, że szukają webmastera ze znajomością MongoDB. Gadam z drugim kumplem, mówi że przechodzą w jego firmie w kluczowych serwisach na MongoDB. Ktoś inny, chwali się że w poprzedniej firmie to pracowali w MongoDB. W dupach im się poprzewracało, mysql stał się nudny, czy co?

Akurat trafiałeś na kilka przypadków użycia mongo. Nie sądzę aby mnogo wypierało mysqla w zastosowaniach webowych, ale nie mam rzetelnej statystyki, piszę to tylko w oparciu o własne spostrzeżenia. Osobiście używam postgresa do zastosowań webowych, a to wcale nie znaczy, że postgres wypiera mysqla.

Pozdrawiam

W dupach im się poprzewracało, mysql stał się nudny, czy co?

Śmiem twierdzić że słaby z Ciebie programista skoro masz takie podejście. Nawet jeśli jesteś w stanie coś tam kodzić to nie widzisz szerszej perspektywy i nie pojmujesz że w świecie programowania (i w świecie ogólnie) zmiany są czymś normalnym i jeśli jest to ewolucja a nie rewolucja to nie ma w tym nic złego. Nie wiem skąd wśród programistów tyle twardogłowych konserwatystów, przecież to się wyklucza z ideą IT. Gdyby myśleć tak jak Ty to po dziś dzień wszyscy pisali byśmy w COBOLu i FOTRANie.

Poza tym wyolbrzymiasz, bazy SQL nadaj mają się dobrze.

drorat1 napisał(a):

Spotkałem się ostatnio z takim serwisem opartym o Node.js, Meteor.js oraz właśnie MongoDB.

Hmmm następny przypadek użycia, może faktycznie jakaś moda na mongo się zaczyna.

drorat1 napisał(a):

Mam tylko podstawową wiedzę z zakresu tej bazy, więc bardzo chciałbym również sam wiedzieć:

Żeby nie było nieporozumień, ja też mam minimalną wiedzę z mongo, aczkolwiek miałem okazję oglądać kilka ciekawych benchmarków.

drorat1 napisał(a):

1. Jaki jest zakres zastosowań tejże bazy i w czym wygrywa z MySQL czy tam PostgreSQL?

Trudno mi się wypowiadać, bo nie wiem czy mongo było dobrze skonfigurowane i dobrze zoptymalizowane w tych przypadkach które widziałem. Nie znam na tyle, aby mieć pewność. Co do czego jestem pewny:

1. W mnogo można zainstalować shardery teoretycznie na dowolnej ilości komputerów. Widziałem na własne oczy, jak z każdym komputerem czas trudnego zapytania spadał liniowo.
2. Baza jest zorienowana na dokument, co jest wadą i zaletą. Ze względu na to, że dziś bazy często zawierają dane o zmiennym rozmiarze (np. string od zera do 4096 bajtów), tę cechę można uznać w 90% za zaletę.
3. Mongo oparte jest na JS - z tego prosty wniosek, że w ciągu najbliższych 20 lat nie napiszą tak dobrych optymalizatorów jakie już są do sqla.
4. W postgresie wprowadzili arrays które można indeksować, czyli zalety dowolnych pól w mnogo poszły do lamusa. Jednak w przypadku gdy chcemy przechowywać w dokumencie dowolne pary (nazwa,wartość), to mongo to lepiej zaindeksuje i może szybciej wyszukać, bo bez joinów - no chyba że narzut JS wszystko zniweczy - byś musiał sam sprawdzić.
5. Rzekoma szybkość zapisu - póki co na oczy tego jeszcze nie widziałem, może w mongo nie wyłączyli dziennikowania gdy miałem okazję oglądać?

drorat1 napisał(a):

1. Czy nie ma to przypadkiem ścisłego związku z również chyba modnymi technologiami typu Angular.js, Metor.js, NodeJS?

Tutaj zupełnie nie mam wiedzy.

drorat1 napisał(a):

1. Czy też może jest to taki model biznesowy i te technologie są wybierane przez niektóre firmy zajmujące się realizacją webserwisów bazując na technologiach które mało kto zna, nie wiem może chodzi o ograniczenie albo pozbycie się konkurencji (tak żeby zapewnić sobie robotę przy dalszych pracach związanych z rozbudową serwisów)?

Być może jest to prawda. I pracownicy są bardziej lojalni, bo gdzie potrzebują ze znajomością nietypowych technologii?

drorat1 napisał(a):

1. Czy też może wygrywa tu potrzeba biznesowa a chodzi o większe serwisy i duży ruch?

</quote> Duży ruch nie, duży ruch obsłuży każda baza z replikacją. Jak już, to czasochłonne zapytania na ogromnych zbiorach danych. Ale aby uzyskać takie przyspieszenie, to trzeba bardzo dużej ilości komputerów, bo mongo jest skutecznie spowalniane przez JS. Jaki serwis stać na zakup np. 1000 komputerów - jest to koszt około 1mln dolarów. Fakt że zapytania na takim klastrze mogą działać np. 200-500 razy szybciej niż na mysqlu. Ja bym wolał zlecić napianie w C++ specjalistycznej bazy do serwisu i potem uruchomić serwis na 10 komputerach a nie na 1000.

Pozdrawiam

@artur_bredzki jak najbardziej, nigdy nie twierdziłem że Mongo jest złotym środkiem i wszystko powinno iść w tym kierunku. To się tyczy wszelkich technologii- jakiekolwiek nieuzasadnione użycie, a szczególnie na podstawie aktualnych trendów jest błędne a wręcz głupie. W poprzednim poście odnosiłem się jedynie do nastawienia autora tego wątku.

A PHP 7 porzuciło wsparcie MySQL? Jaki SQL teraz promowane jest z nowym PHP, czy to MongoDB?

Świetny Mleczarzh napisał(a):

A PHP 7 porzuciło wsparcie MySQL? Jaki SQL teraz promowane jest z nowym PHP, czy to MongoDB?

Nie porzyciło już w wersji 5.5 api mysql było depracated, pozostaje PDO lub mysqli
http://php.net/manual/en/mysqlinfo.api.choosing.php

https://pl.wikipedia.org/wiki/MongoDB

Nie wiem na ile dane w wiki są aktualne, ale jeśli MongoDB dalej nie wspiera w pełni UTF-8 i brakuje mu innych funkcji jak np. w MySQL to szkoda na niego czasu. Może być szybki ale lepiej wybrać coś wolniejszego i być pewnym, że da się zrobić to co planujesz.

O MongoDB trudno powiedzieć że jest to "technologia, którą mało kto zna". Może w Polsce, chociaż też wątpię.
Jak na razie, z tego co mi wiadomo:

• MongoDB nie jest najszybsze w swojej dziedzinie (Document Store). Ponoć lepsze jest Couchbase lub Cassandra (Column Store). Ale najszybsze nie zawsze jest najlepsze dla klienta. Zresztą "najlepsze" to bardzo ogólnikowe stwierdzenie.
• MongoDB nie wspiera transakcji (podobnie jak MyISAM), można ew. coś tam samemu wymyślać, ale będzie to pracochłonne: https://docs.mongodb.com/v3.2/core/write-operations-atomicity/
• MongoDB w odróżnieniu od baz relacyjnych bezproblemowo się skaluje (chociaż nie idealnie) na wiele komputerów,
• w bazach relacyjnych najbliższe rozwiązanie (sharding) wymaga ręcznego kodowania warunków lub użycia wspierającego to ORM-a: https://docs.jboss.org/hibernate/shards/3.0/reference/en/html_single/
• MongoDB wspiera bardzo dużą liczbę języków programowania
• MongoDB zapytuje się przy pomocy JSON-a a nie JavaScript-a, JavaScript to tylko jeden z wielu możliwych języków sterujących
• od MongoDB pochodzi litera M w stosie "MEAN"

O bazach NoSQL w zasadzie nie powinno się już pytać "dlaczego?" tylko raczej "gdzie?".
Lista takich rozwiązań jest długa: http://nosql-database.org/

@artur_bredzki

Mongo oparte jest na JS - z tego prosty wniosek, że w ciągu najbliższych 20 lat nie napiszą tak dobrych optymalizatorów jakie już są do sqla

Ale aby uzyskać takie przyspieszenie, to trzeba bardzo dużej ilości komputerów, bo mongo jest skutecznie spowalniane przez JS

Skąd Ty to wziąłeś? Mongo jest napisane w C/C++, JS jest tam wykorzystywany tylko do skryptowania: https://docs.mongodb.com/v3.0/core/server-side-javascript/

vpiotr napisał(a):

• MongoDB nie wspiera transakcji (podobnie jak MyISAM), można ew. coś tam samemu wymyślać, ale będzie to pracochłonne: https://docs.mongodb.com/v3.2/core/write-operations-atomicity/

Pytanie czy z tego właśnie powodu może się nadawać do rejestracji choćby płatności (za jakieś dajmy na to płatne usługi w serwisie) na koncie każdego zarejestrowanego użytkownika? Właściwie to chodzi o jakiekolwiek inne ważne dane. Tutaj chodzi mi o takie operacje jak commit albo rollback, w przypadku MySQL.

Wiadomo że w MySQL można składować dane sesyjne każdego użytkownika, np. w takiej tabel sessions i z silnikiem MyISAM (tak przynajmniej jest rozwiązane w założeniach przez FW w którym pracuję), stąd też jest pytanie jakiego typu dane tam w tym mongo składować?

1. Sesje?
2. Dane tymczasowe?
3. Cache?

Pytanie czy MongoDB może być np. wykorzystywane tylko jako świetne uzupełnienie dla MySQL w serwisie a nie jako baza podstawowa?

• MongoDB w odróżnieniu od baz relacyjnych bezproblemowo się skaluje (chociaż nie idealnie) na wiele komputerów,

Jak wyżej. Chodzi o to czy z tych powodu serwis może być oparty w całości o Mongo czy tez Mongo ma być jakimś uzupełnieniem?

• MongoDB zapytuje się przy pomocy JSON-a a nie JavaScript-a, JavaScript to tylko jeden z wielu możliwych języków sterujących

I z tego powodu też jest pytanie, czy wybór nie jest przypadkiem podyktowany tym jak się pracuje w tych frameworkach jak Meteor.js, Angular.js i o perspektywy (nie wiem, może łatwość implementacji)?

Z tego co wiem są firmy w Polsce, które robią na tym aplikacje od a do z, bez pomocy MySQL.

Nie wiem na ile to jest przemyślane z ich strony.
To co znalazłem, a chyba warto przeczytać:

https://neo4j.com/blog/acid-vs-base-consistency-models-explained/
https://msdn.microsoft.com/en-us/magazine/dn759436.aspx
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.187.8545&rep=rep1&type=pdf
http://www.dummies.com/programming/big-data/applying-consistency-methods-in-nosql/
https://spring.io/understanding/NoSQL

Aventus napisał(a):

@artur_bredzki jak najbardziej, nigdy nie twierdziłem że Mongo jest złotym środkiem i wszystko powinno iść w tym kierunku. To się tyczy wszelkich technologii- jakiekolwiek nieuzasadnione użycie, a szczególnie na podstawie aktualnych trendów jest błędne a wręcz głupie. W poprzednim poście odnosiłem się jedynie do nastawienia autora tego wątku.

Też piszę o nastawieniu autora. W typowych przypadkach autor ma rację, w 99% użycie mongo jest pomyłką, szpanerstwem, itd.

vpiotr napisał(a):

• MongoDB nie wspiera transakcji (podobnie jak MyISAM), można ew. coś tam samemu wymyślać, ale będzie to pracochłonne: https://docs.mongodb.com/v3.2/core/write-operations-atomicity/

Z tego co pamiętam, to wspiera transakcje w obrępie jednego dokumentu.

Pozdrawiam

Maciej Cąderek napisał(a):

Skąd Ty to wziąłeś? Mongo jest napisane w C/C++, JS jest tam wykorzystywany tylko do skryptowania: https://docs.mongodb.com/v3.0/core/server-side-javascript/

Właśnie o te 'tylko' chodzi.

drorat1 napisał(a):

Pytanie czy z tego właśnie powodu może się nadawać do rejestracji choćby płatności (za jakieś dajmy na to płatne usługi w serwisie) na koncie każdego zarejestrowanego użytkownika? Właściwie to chodzi o jakiekolwiek inne ważne dane. Tutaj chodzi mi o takie operacje jak commit albo rollback, w przypadku MySQL.

Na poziomie jednego dokumentu MongoDB daje gwarancje co do spójności danych. Jeśli uda Ci się tak zaprojektować bazę, aby taka spójność wystarczała, to będzie się nadawało.

drorat1 napisał(a):

Wiadomo że w MySQL można składować dane sesyjne każdego użytkownika, np. w takiej tabel sessions i z silnikiem MyISAM (tak przynajmniej jest rozwiązane w założeniach przez FW w którym pracuję), stąd też jest pytanie jakiego typu dane tam w tym mongo składować?

1. Sesje?
2. Dane tymczasowe?
3. Cache?

Normalnie można trzymać dowolne dane tak jak w bazach SQL.

drorat1 napisał(a):

Pytanie czy MongoDB może być np. wykorzystywane tylko jako świetne uzupełnienie dla MySQL w serwisie a nie jako baza podstawowa?

Myślę że zbyt mongo jest zbyt podobne do mysql aby używać w jednej aplikacji jednej i drugiej bazy - chyba że do jakiegoś importu/eksportu danych, ale to co innego.

drorat1 napisał(a):

Jak wyżej. Chodzi o to czy z tych powodu serwis może być oparty w całości o Mongo czy tez Mongo ma być jakimś uzupełnieniem?

Może być, ale w oparciu o moją minimalną wiedzę odnoszę wrażenie, że to się opłaca tylko gdy:

• trzeba szybko aplikację wykonać (nie można miesiącami dziargać w C++)
• nie da się uniknąć długotrwałych zapytań do bazy
• są pieniądze na wynajęcie dziesiątek lub setek komputerów.
  Moim zdaniem te warunki występują rzadko. Ale nie znam w pełni mongo, mogę się co do czegoś mylić.

• MongoDB zapytuje się przy pomocy JSON-a a nie JavaScript-a, JavaScript to tylko jeden z wielu możliwych języków sterujących

Rozróżnienie jest bez sensu, bo JSON jest przecież elementem JavaScriptu. Właśnie o to chodzi że JSON (ogólnie JavaScript) leci do bazy jako zapytanie. Pewnie mongo ma jakieś API i do C++, ale czy wykorzystywanie tego API nadal jest efektywną metodą budowania aplikacji?

drorat1 napisał(a):

I z tego powodu też jest pytanie, czy wybór nie jest przypadkiem podyktowany tym jak się pracuje w tych frameworkach jak Meteor.js, Angular.js i o perspektywy (nie wiem, może łatwość implementacji)?

Nie wiem nic na ten temat.

Pozdrawiam

JSON to podzbiór JavaScriptu, ale obecnie to są dwie różne rzeczy. JSON to format danych, JavaScript język programowania. Warto umieć odróżniać te dwie rzeczy.

Warto sprawdzić zanim się komuś zasugeruje że jak idiota nie rozróżnia podstawowych rzeczy.
Polecam przykład:
https://docs.mongodb.com/manual/tutorial/map-reduce-examples
Widzimy funkcje, pętle, zmienne - język JavaScript w całej obfitości, a nie tylko JSON.

artur_bredzki napisał(a):

JSON to podzbiór JavaScriptu, ale obecnie to są dwie różne rzeczy. JSON to format danych, JavaScript język programowania. Warto umieć odróżniać te dwie rzeczy.

Warto sprawdzić zanim się komuś zasugeruje że jak idiota nie rozróżnia podstawowych rzeczy.
Polecam przykład:
https://docs.mongodb.com/manual/tutorial/map-reduce-examples
Widzimy funkcje, pętle, zmienne - język JavaScript w całej obfitości, a nie tylko JSON.

Nie bądź taki ostry dla siebie. Map-reduce rzeczywiście używa funkcji w JS, reszta to JSON.

vpiotr napisał(a):

Nie bądź taki ostry dla siebie. Map-reduce rzeczywiście używa funkcji w JS, reszta to JSON.

Zwykłe find używa JS:
https://docs.mongodb.com/manual/reference/operator/query/where/

artur_bredzki napisał(a):

vpiotr napisał(a):

Nie bądź taki ostry dla siebie. Map-reduce rzeczywiście używa funkcji w JS, reszta to JSON.

Zwykłe find używa JS:
https://docs.mongodb.com/manual/reference/operator/query/where/

No tak, masz rację, tylko weź pod uwagę że sami autorzy tego oprogramowania odradzają ten operator (co ma związek z tym od czego ta dyskusja się zaczęła - że JavaScript w kontekście bazy danych słabo się optymalizuje):

$where evaluates JavaScript and cannot take advantage of indexes. Therefore, query performance improves when you express your query using the standard MongoDB operators (e.g., $gt, $in).
In general, you should use $where only when you can’t express your query using another operator. If you must use $where, try to include at least one other standard query operator to filter the result set. Using $where alone requires a collection scan.

vpiotr napisał(a):

artur_bredzki napisał(a):

vpiotr napisał(a):

Nie bądź taki ostry dla siebie. Map-reduce rzeczywiście używa funkcji w JS, reszta to JSON.

Zwykłe find używa JS:
https://docs.mongodb.com/manual/reference/operator/query/where/

No tak, masz rację, tylko weź pod uwagę że sami autorzy tego oprogramowania odradzają ten operator (co ma związek z tym od czego ta dyskusja się zaczęła - że JavaScript w kontekście bazy danych słabo się optymalizuje):

$where evaluates JavaScript and cannot take advantage of indexes. Therefore, query performance improves when you express your query using the standard MongoDB operators (e.g., $gt, $in).
In general, you should use $where only when you can’t express your query using another operator. If you must use $where, try to include at least one other standard query operator to filter the result set. Using $where alone requires a collection scan.

Ok, czyli zmieniasz to co poprzednio napisałeś, że mongo nie używa w zapytaniach js, na to, że można obyć się bez js, więc można równie łatwo napisać optymalizator do mongo jak do sqla. Na tyle nie znam mongo, aby wiedzieć czy da się obyć bez js. Po ilości operatorów można wnioskować że masz rację. Ale nawet jeśli teoretycznie można napisać dobry optymalizator do mongo, to pozostaje moja druga wątpliwość: czy napisali i czy włożyli w mongo tak dużo pracy jak w myqla czy postgresa. Kolejna wątpliwość dotyczy indeksów, ciekawe jak dobrze mongo wykorzystuje indeksy. Mongo ma np. fajną funkcję skip, ciekawe czy indeksy wspomagają tę funkcję, czy podobnie jak w popularnych bazach sql, nie wspomagają. Od razu wyjaśnię, funkcja skip to w przybliżeniu limit w mysqlu i offset w postgresie.

Pozdrawiam

Wygląda na to, że JavaScript to takie rozszerzenie funkcjonalności MongoDB. Powiedzmy jak język procedur składowanych dla baz relacyjnych.
Pewnie w większości wypadków można się bez tego obyć (używając zamiast niego wyrażeń typu $gt, $in), a na te kilka specjalnych okazji masz super-elastyczną składnię w postaci JavaScript-a. To się tyczy wszystkiego poza map-reduce. Do Map Reduce każdy przykład który znajduję opiera się o JavaScript.

Bo jak to ktos ladnie okreslil na tym forum "programisci rzucaja sie na nowe technologie jak szczerbaty na suchary".
http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/

A do tego dobrze przemyslana technologia jaka jest SQL jest juz od dawna passe (no i trzeba by sie jeszcze nauczyc programowania deklaratywnego zeby byc efektywnym w sqlu, co dla wielu jest ponad sily).

Mongo oparte jest na JS - z tego prosty wniosek, że w ciągu najbliższych 20 lat nie napiszą tak dobrych optymalizatorów jakie już są do sqla

Non sequitur. Z twojej przesłanki (Mongo oparte na JS) nie wynika wcale Twój wniosek (nie napiszą tak dobrych optymalizatorów).

Co ma język do jakości optymalizatora? Bardzo niewiele. Można napisać świetny optymalizator w JS i beznadziejny w C++.
O jakości optymalizatora decydują przede wszystkim umiejętności programistów i użyte algorytmy. Np. MySQL ma optymalizator napisany w C i obiektywnie przez długi czas był (a może nadal jest) to jeden z najsłabszych optymalizatorów oparty na regułach. W czasach, kiedy MySQL walczył aby efektywnie wykonać zapytania zawierające ledwie 2 złączenia, inne optymalizatory nie miały problemów z zapytaniami z 10 i więcej złączeniami i używały zaawansowanych metod kosztowych (nawet PostgreSQL) i to od wielu lat. Sam optymalizator nie musi być wcale bardzo szybki, musi za to dawać dobre plany zapytań, a to jest łatwiej uzyskać pisząc go w języku wysokiego poziomu.

Z kolei silnik składowania danych Mongo jest napisany w C++, oparty o pliki mapowane pamięciowo i nie ma tam ani jednej linijki w JS. Jest to swoją drogą beznadziejna decyzja projektowa, która powoduje, że MongoDB dostaje solidne bęcki praktycznie w każdym benchmarku, gdzie ilość danych przekracza rozmiar dostępnego RAMu. Nawet od baz napisanych w Javie :P

Na poziomie jednego dokumentu MongoDB daje gwarancje co do spójności danych. Jeśli uda Ci się tak zaprojektować bazę, aby taka spójność wystarczała, to będzie się nadawało.

Nie daje.
https://aphyr.com/posts/322-jepsen-mongodb-stale-reads

In this post, we’ll see that Mongo’s consistency model is broken by design: not only can “strictly consistent” reads see stale versions of documents, but they can also return garbage data from writes that never should have occurred

---

Odpowiadając na pytanie - dlaczego Mongo jest takie popularne:

1. Bo ma proste i dość spójne API. Zapytania w JS. Dane w JS. Wyniki zapytań w JS. JS każdy prawie zna, a jak nie zna, to w podstawowym zakresie może się w dzień nauczyć.
2. Bo ma dobrą i przyjazną początkującym dokumentację.
3. Bo można je szybko postawić na laptopie i od razu działa bez większych ceregieli.
4. Bo ma prosty, dynamiczny model danych. Minuta czytania i wiadomo o co chodzi. Znacznie prostszy niż RDBMSy.
5. Bo przez brak sztywnego schematu daje poczucie, że nie trzeba jakoś bardzo projektować modelu danych. Jak zabraknie jakiegoś pola czy trzeba będzie zmienić strukturę, to się zmieni później i Mongo wszystko łyknie.
6. Bo ma stosunkowo mało ograniczeń jeśli chodzi o wyszukiwanie względem innych NoSQLi. Nie tak jak w Cassandrze, gdzie trzeba pomyśleć np. o kolejności kolumn, bo później będzie cięzko wyszukiwać po czymś tam.
7. Bo jest dość szybkie o ile nie wychodzimy poza RAM.

Jednak jak się wejdzie w temat głębiej to się okazuje że:

1. Skalowanie Mongo to droga przez mękę.
2. Wydajność ssie dla dużych zestawów danych wychodzących znacznie poza RAM.
3. Większość gwarancji odnośnie spójności danych nie jest prawdziwa.
4. Dynamiczny schemat przy dużym projekcie może szybko doprowadzić do bałaganu.

Podsumowując - Mongo to jest taki jakby PHP baz danych.

Disclaimer: Pracuję przy Cassandrze, więc mogę być trochę nieobiektywny, choć próbowałem :D

Przypomniała mi się historia z MongoDB w social network Diaspora

http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/

@Krolik
Jak już jesteśmy przy NoSQL - masz jakąś opinię o ArangoDB?
Używam tego bo klient sobie zażyczył, używa się fajnie, ale nie wiem jak to się sprawdza na dłuższą metę.

Krolik napisał(a):

Non sequitur. Z twojej przesłanki (Mongo oparte na JS) nie wynika wcale Twój wniosek (nie napiszą tak dobrych optymalizatorów).

Mój wniosek był inny, a mianowicie że równie łatwo nie pisze się optymalizatorów do sqla co do js. Poza tym to jest już jest trochę nieaktualne w tym wątku, byś musiał przeczytać wszystkie posty, szczególnie z vpiotr. Zgodziliśmy się że optymalizowanie zapytania w JSON jest porównywalnie trudne do optymalizowania zapytania w SQLu.

Krolik napisał(a):

Co ma język do jakości optymalizatora?

Nie chodziło o jakość optymalizatora, ale to trudności napisania optymalizatora.

Krolik napisał(a):

Sam optymalizator nie musi być wcale bardzo szybki, musi za to dawać dobre plany zapytań, a to jest łatwiej uzyskać pisząc go w języku wysokiego poziomu.

W połowie zgodzę się z Tobą, często, może właśnie w połowie przypadków, jest tak jak napisałeś. Ale zwróć uwagę na dwie sprawy:

1. Jeśli zapytanie na kiepskim planie wykonuje się 1.0s, na dobrym planie 0.9s, a (wolny) optymalizator działa 0.3s, to sam rozumiesz że samo użycie optymalizatora już szkodzi.
2. Jeśli wolny optymalizator napiszemy np. w Pythonie, a taki sam wydajny w C++, to ten w C++ w tym samym czasie może wykonać około 100 razy więcej obliczeń, więc może lepiej zoptymalizować.

Krolik napisał(a):

Z kolei silnik składowania danych Mongo jest napisany w C++, oparty o pliki mapowane pamięciowo i nie ma tam ani jednej linijki w JS. Jest to swoją drogą beznadziejna decyzja projektowa, która powoduje, że MongoDB dostaje solidne bęcki praktycznie w każdym benchmarku, gdzie ilość danych przekracza rozmiar dostępnego RAMu. Nawet od baz napisanych w Javie :P

Nie mam szczegółowej wiedzy na temat Mongo, więc nie wiem czy dostaje lanie czy nie. Ale na pewno popełniasz kilka błędów:

1. Java jest językiem kompilowanym, bardzo wydajnym, a wąskim gardłem może być dostęp do danych w RAM lub dysku, więc napisanie 'nawet w javie' jest pomyłką
2. Proponuję eksperyment: Weź jakąś listę, wektor danych nawet w RAM, napisz jakiś bardziej skomplikowany warunek nawet w C++, potem uruchom fullscan i zobacz jaki będzie czas wykonania gdy ilość danych zajmie pamięć dzisiejszego mocnego komputera (np. 64-256GB). Potem odpowiedz sobie na pytanie, jak często taki czas oczekiwania na odpowiedź jest dopuszczalny. Wniosek będzie oczywisty: gdy dane przekraczają bufor ram, to dostawiamy kolejny sharder i mongo daje właśnie takie możliwości. Baza postgres niby też daje takie możliwości, ale map-reduce trzeba zrobić sobie samemu, a w mongo jest gotowe.

Krolik napisał(a):

Nie daje.
https://aphyr.com/posts/322-jepsen-mongodb-stale-reads
In this post, we’ll see that Mongo’s consistency model is broken by design: not only can “strictly consistent” reads see stale versions of documents, but they can also return garbage data from writes that never should have occurred

Ktoś kłamie, nie wiem kto:
http://student.agh.edu.pl/~chamot/bazy/
[
Załózmy, że kilka procesów na raz chce dodać wartość w tabeli 'groups'. Klient nie musi sie martwić o transakcyjność. MongoDB rozwiązuje ten problem. Każda operacja zmieniająca stan dokumentu usuwa go oraz wstawia nowy, zaktualizowany. System bazy danych dba o synchronizację tych dwóch operacji tak, by każdy klient widział te same dane.
]

Krolik napisał(a):

1. Bo ma proste i dość spójne API. Zapytania w JS. Dane w JS. Wyniki zapytań w JS. JS każdy prawie zna, a jak nie zna, to w podstawowym zakresie może się w dzień nauczyć.

Moim zdaniem SQL jest prostszy.

Krolik napisał(a):

1. Bo ma dobrą i przyjazną początkującym dokumentację.

Przypominam sobie czasy gdy miałem pierwszy kontakt z SQLem. Kupiłem jakąś książeczkę za parę zł i po kilku dniach całkiem sporo umiałem zrobić.

Krolik napisał(a):

1. Bo można je szybko postawić na laptopie i od razu działa bez większych ceregieli.

Z bazami SQL mam mniej problemów. Np. drivera mongodb do C++ nie udało mi się skompilować, pomimo że poświęciłem na to cały dzień.

Krolik napisał(a):

1. Bo ma prosty, dynamiczny model danych. Minuta czytania i wiadomo o co chodzi. Znacznie prostszy niż RDBMSy.

Dane zorganizowane w wiersze i kolumny też są proste.

Krolik napisał(a):

1. Bo przez brak sztywnego schematu daje poczucie, że nie trzeba jakoś bardzo projektować modelu danych. Jak zabraknie jakiegoś pola czy trzeba będzie zmienić strukturę, to się zmieni później i Mongo wszystko łyknie.

Do tabeli sqlowej też można dodać pole.

Krolik napisał(a):

1. Bo ma stosunkowo mało ograniczeń jeśli chodzi o wyszukiwanie względem innych NoSQLi. Nie tak jak w Cassandrze, gdzie trzeba pomyśleć np. o kolejności kolumn, bo później będzie cięzko wyszukiwać po czymś tam.

Nie znam casandry.

Krolik napisał(a):

1. Bo jest dość szybkie o ile nie wychodzimy poza RAM.

Nie widziałem dużo dobrych porównań, ale w tym co widziałem, to (na jednym sharderze) mongo raczej było wolniejsze niż postgresql.

Krolik napisał(a):

1. Skalowanie Mongo to droga przez mękę.

Nie widziałem dużych i skomplikowanych przykładów do skalowania, ale doinstalowanie shardera jest proste.

Krolik napisał(a):

1. Wydajność ssie dla dużych zestawów danych wychodzących znacznie poza RAM.

Jeśli wydajność jest ważna to w ogóle inne obliczenia niż w RAM odpadają, no chyba że mamy tylko proste zapytania i można zrobić bezpośredni skok do zaindeksowanego rekordu.

Krolik napisał(a):

1. Większość gwarancji odnośnie spójności danych nie jest prawdziwa.

No nie wiem, jakie jest źródło tej informacji?

Krolik napisał(a):

1. Dynamiczny schemat przy dużym projekcie może szybko doprowadzić do bałaganu.

Zgadzam się że może, ale nie musi.

Krolik napisał(a):

Podsumowując - Mongo to jest taki jakby PHP baz danych.

Jest analogia do dynamicznego typowania - zgadzam się.

Pozdrawiam

@Krolik co sprawiło,że uzyłeś cassandry? Wcinam się w dyskusje bo nie znam nikogo kto używa produkcyjnie NoSQL. Zakładam jednak, że zrobiłeś jakiś research, więc chciałbym "wykorzystać" Twoją wiedzę ;)
Bardziej interesuje mnie dlaczego NoSQL, bo tak na szybko przeglądając info o casandrze to zastanawiam się dlaczego nie jakiś RDBMS? Jakbyś mógł opisać czego ci brakuje w porównaniu do silników "SQL". Bez szczególnego wyróżniania i udowodniania wyzszości po prostu iteresują mnie doświadczenia z frontu.

@artur_bredzki nie schodźmy na tematy możliwości technicznych, wykorzystajmy, że są na tym forum osoby z doświadczeniem No SQL i nauczmy się czegoś nowego. (to piszę odnośnie naszej dyskusji NoSQL vs SQL ;))