MongoDB

niestety nie ma jednoznacznej odpowiedzi na twoje pytanie. to tak jak bys sie spytal czy lepsza jest java czy c albo windows vs linux.
podaj przypadek uzycia i co wlasciwie chcesz przyspieszyc, o ile i dlaczego. w innym wypadku nie ma sobie co zawracac glowy (chyba ze robisz to w celach edukacyjnych).

Właśnie ja pytam o sensowne przykłady użycia. Oczekuję takich przykładowych odpowiedzi. Mieliśmy taką i taką aplikację na takiej bazie. Były takie i takie problemy. Przeszliśmy na MongoDB. Te problemy zniknęły, ale za to takie się pojawiły.

To najpierw zadaj sensowne pytanie, bo to za bardzo nie jest...
Nie da się wprost porównać bazy relacyjnej do NoSQL. Mają różne zastosowania a u ich podstaw leżą zupełnie rożne wymagania.

Skoro nie potrzebujesz w bazie danych transakcji zgodnej z ACID (np. MongoDB nie wspiera two-phase-commit), bez wsparcia dla triggerów i kluczy obcych, bez złączeń, itd. itp. to MongoDB jest dla Ciebie.
Jeśli potrzebujesz dynamicznego schematu bazy danych, bardzo dobrej skalowalności poziomej, obsługi danych zorientowanej na dokumenty, to MSSQL nie jest dla Ciebie.

Przy tradycyjnym podejściu relacyjnym, MSSQL i inne bazy relacyjne będą szybsze i wygodniejsze.
Przy skomplikowanym modelu danych zorientowanym na dokument oraz dynamicznie zmieniającym się schemacie danych, to NoSQL będzie wygodniejszy i szybszy.

wloochacz napisał(a):

Jeśli potrzebujesz (...) bardzo dobrej skalowalności poziomej (...) to MSSQL nie jest dla Ciebie.

Mongo też nie. Nie każdy NoSQL jest wydajny i skalowalny.

Mongo jest jak PHP. Jest oparte na prostej koncepcji, łatwo zacząć zabawę na własnym laptopie, ma niezłą dokumentację, jest popularne, no i nie czepia się takich drobiazgów jak typy danych. Byle gimnazjalista może postawić Mongo i napisać prostą aplikację.

Wszystko jest pięknie do postawienia serwisu produkcyjnie. Wtedy nagle okazuje się, że Mongo nie gwarantuje nawet niezgubienia danych potwierdzonych jako zapisane, konfiguracja Mongo na wielu serwerach już nie jest wcale taka prosta jak na jednym laptopie, wydajność ssie jak tylko dane przestaną mieścić się w RAM, a do tego wcale się nie skaluje tak jak obiecano w ulotce reklamowej.

https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads

Jakiej skalowalności się spodziewać? WIem że nie ma na to pytanie precyzyjnej i jednoznacznej odpowiedzi, ale chodzi mi o
jakieś szacunki, byle te szacunki były poparte praktyką (nie teorią z dokumentacji).

Mam np. tabelę w porządnej sqlowej bazie. Tabela ma około 20 istotnych pól. Istotne pola to te, po których następuje wyszukiwanie i
indeksowanie. Do tego tabela ma kilka długich pól tekstowych, są w nich dane które tylko są wyświetlane, nie robię na nich
żadnych operacji typ LIKE, REGEXP czy choćby substring. Powiedzmy że złączeń tabel też nie ma.

Dodanie miliona losowych danych do tej tabeli trwa około 40 minut na laptopie. Powiedzmy że teraz to samo chcę zrobić na
MongoDB zainstalowanym na 20 komputerach. Czego się spodziewać? Ile rekordów na ten milion średnio zginie? Ile razy
czas zapisu powinien się skrócić?

Potem wyszukiwanie. Obecnie, na bazie sql, gdy w bazie mam 5mln testowych rekordów i gdy cała baza jest
zbuforowana w RAM, to zapytania typu:
select * from table where pole1=123 and pole2=342 and pole3 <= 1937323 order by pole3 limit 30;
trwa od 3 do 15 ms.
Nawet gdy warunek zawiera dużo operatorów and i or to zapytanie wyrabia się najczęściej w 20ms.

Jednak gdy mam zapytanie typu:
select * from table where pole1=123 and pole2 in ( lista od 10 do 100 intigerów ) and pole3 <= 1937323 order by pole3 limit 30;
To zapytanie trwa już bardzo długo, rzędu 0.5 do 20s, najczęściej 1-4 sekundy.

Gdybym zrobił analogiczne zapytanie na MongoDB skonfigurowanym na 20 komputerach to można spodziewać się
przyspieszenia chociaż 10 razy?

P.S.
Gdy w mojej bazie SQL zabraknie RAM to zapytania też trwają bardzo długo.

Do poczytania use case użycia MongoDB, o tym jak gość w prosty sposób zoptymalizował sobie apkę:
https://medium.com/unboxd/how-i-built-an-app-with-500-000-users-in-5-days-on-a-100-server-77deeb238e83#.z1yo1ms5c

TLDR: Apka na MongoDB + Moongoose mu muliła, myślał, że to Moongoose (nakładka na MongoDB) ale okazało się, że musiał dodać wskaźnik lean() na Moongoose, więc morał z tego, że trzeba czytać dokumentację narzędzi, a nie winić narzędzie od razu (tak samo i z MongoDB, MySQL etc. czasem winimy narzędzie, a często po prostu nie umiemy korzystać z danych narzędzi...).

Także zrobił gość bardzo prostą i w sumie durną optymalizację - czyli stworzył dodatkowe kolekcje dla często pobieranych dokumentów, takich jak "all "snaps, most liked snaps, newest snaps, newest valid " i to też mu podobno pomogło zoptymalizować apkę. Czyli wniosek z tego taki, że czasem zamiast zmieniać technologie wystarczy dokonać prostej optymalizacji w ramach danej technologii...

Jakiej skalowalności się spodziewać?

Ale skalowalności do czego? Masz jakiś konkretny use case? Zapytania "coś tam from pole" to nie use case, tylko szczegół implementacyjny...

LukeJL napisał(a):

Do poczytania use case użycia MongoDB, o tym jak gość w prosty sposób zoptymalizował sobie apkę:
https://medium.com/unboxd/how-i-built-an-app-with-500-000-users-in-5-days-on-a-100-server-77deeb238e83#.z1yo1ms5c

Dzięki, spojrzę.

LukeJL napisał(a):

TLDR: Apka na MongoDB + Moongoose mu muliła, myślał, że to Moongoose (nakładka na MongoDB) ale okazało się, że musiał dodać wskaźnik lean() na Moongoose, więc morał z tego, że trzeba czytać dokumentację narzędzi, a nie winić narzędzie od razu (tak samo i z MongoDB, MySQL etc. czasem winimy narzędzie, a często po prostu nie umiemy korzystać z danych narzędzi...).

Czasami owszem nieumiejętnie korzysta się z narzędzi. Teraz mam w bazie jedną istotną/dużą tabelę. Wrzuciłem do testów około
5-6mln rekordów. Jest w tej tabeli około 5gb danych. Bazie przydzieliłem 6GB ram, na lapku jest 12GB ram, system plików jest buforowany.
Wykonałem altertable żeby dodać kolumnę do tej tabeli. Zapytanie trwało 700sekund. No cóż, nie często się doaje kolumny, można
przeżyć. Potem jednak dałem:
update table1 t set nowe_pole = (select pole from table2 where t.id_obce = id);
table2 jest mała, ma 900 rekordów.
Czyli trzeba na dysku zapisać około 20MB danych i około 5 mln razy poszukać wartości w małej tabelce.
Zapytanie trwało 31884s, po czym przerwałem bo mnie ku#$%ca wzięła.
Chętnie bym się dowiedział i zrozumiał co znowu zrobiłem źle. Dlaczego baza sql przez 10godzin ciągłej
pracy nie jest w stanie zapisać 20MB danych na dysku?

LukeJL napisał(a):

Także zrobił gość bardzo prostą i w sumie durną optymalizację - czyli stworzył dodatkowe kolekcje dla często pobieranych dokumentów, takich jak "all "snaps, most liked snaps, newest snaps, newest valid " i to też mu podobno pomogło zoptymalizować apkę. Czyli wniosek z tego taki, że czasem zamiast zmieniać technologie wystarczy dokonać prostej optymalizacji w ramach danej technologii...

Czasami się udaje coś takiego. Zwykle tylko wtedy, gdy są małe wymagania wobec aplikacji.

Jakiej skalowalności się spodziewać?

Ale skalowalności do czego? Masz jakiś konkretny use case? Zapytania "coś tam from pole" to nie use case, tylko szczegół implementacyjny...</quote>
Jeju, nikt na forum nie wrzuci 100 stron dokumentacji, ani nikt za free nie będzie tago nalizował. SQL bardzo precyzyjnie wyraża
co trzeba przyspieszyć. Nie napisałem coś tam from pole, tylko podałem przykładowe warunki i opisałem że jest jedna istotna
tabela. Chciałbym wiedzieć czy odpowiednik takiego selecta w ogóle może się szybciej wykonać na MongoDB i jaki to jest
rząd wielkości np. na 20 komputerach.

artur_bredzki napisał(a):

Potem jednak dałem:
update table1 t set nowe_pole = (select pole from table2 where t.id_obce = id);
table2 jest mała, ma 900 rekordów.
Czyli trzeba na dysku zapisać około 20MB danych i około 5 mln razy poszukać wartości w małej tabelce.
Zapytanie trwało 31884s, po czym przerwałem bo mnie ku#$%ca wzięła.
Chętnie bym się dowiedział i zrozumiał co znowu zrobiłem źle. Dlaczego baza sql przez 10godzin ciągłej
pracy nie jest w stanie zapisać 20MB danych na dysku?

Nie skorzystałeś z FROM w UPDATE.

UPDATE table1 SET nowe_pole=x.pole FROM table2 x WHERE x.id_obce=table1.id

Marcin.Miga napisał(a):

artur_bredzki napisał(a):

Potem jednak dałem:
update table1 t set nowe_pole = (select pole from table2 where t.id_obce = id);
table2 jest mała, ma 900 rekordów.
Czyli trzeba na dysku zapisać około 20MB danych i około 5 mln razy poszukać wartości w małej tabelce.
Zapytanie trwało 31884s, po czym przerwałem bo mnie ku#$%ca wzięła.
Chętnie bym się dowiedział i zrozumiał co znowu zrobiłem źle. Dlaczego baza sql przez 10godzin ciągłej
pracy nie jest w stanie zapisać 20MB danych na dysku?

Nie skorzystałeś z FROM w UPDATE.

UPDATE table1 SET nowe_pole=x.pole FROM table2 x WHERE x.id_obce=table1.id

A więc...

gdy nieumiejetnie uzywa sie sql to nieumiejetne uczywanie no-sql nie sprawi ze magicznie wszystko przyspieszy. twoja baza jest bardzo mala, mysle ze najprawdopodobniej jest zle zaprojektowana i stad problemy. dwie sprawy:

• przejscie na mongodb nie przyspieszy odczytu danych z dysku
• zadna baza automagicznie nie dobiera dobrej struktury tablic i indeksow
• nie mozna w nieskonczonosc dodawac hardware zamiast po prostu napisac cos po ludzku ;)

katelx napisał(a):

gdy nieumiejetnie uzywa sie sql to nieumiejetne uczywanie no-sql nie sprawi ze magicznie wszystko przyspieszy. twoja baza jest bardzo mala, mysle ze najprawdopodobniej jest zle zaprojektowana i stad problemy. dwie sprawy:

• przejscie na mongodb nie przyspieszy odczytu danych z dysku
• zadna baza automagicznie nie dobiera dobrej struktury tablic i indeksow
• nie mozna w nieskonczonosc dodawac hardware zamiast po prostu napisac cos po ludzku ;)

Po takich uwagach czuję się ekspertem z MongoDB.