@Krolik: ten wątek miał za zadanie poszerzenie informacji o MongoDB a Ty robisz z tego g... burzę.

1. "Zapytania w JS. Dane w JS. Wyniki zapytań w JS"

O różnicy między JSON a JS wyjaśnione jest wcześniej. Dla Ciebie specjalnie: przykład jak pracuje się z MongoDB w C++ (bez JS):
https://www.mongodb.com/blog/post/introducing-new-c-driver

przykład w Hibernate (też bez JS):
http://blog.eisele.net/2015/01/nosql-with-hibernate-ogm-part-one.html

1. "Bo jest dość szybkie o ile nie wychodzimy poza RAM." - co to znaczy? Chcesz powiedzieć, że ten DBMS nie obsługuje zbiorów większych niż RAM? Masz na to jakieś potwierdzenie?

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

Na końcu artykułu wskazane są dwa zgłoszenia do supportu MongoDB. Oba naprawione chyba, więc ten link to argument za czym?

1. "Dynamiczny schemat przy dużym projekcie może szybko doprowadzić do bałaganu.", czyli upraszczając "nie powinniśmy do dokumentów stosować Worda tylko Excela, bo Word ma dynamiczny schemat".

Wygląda jakbyś udawał, że nie wiesz że Cassandra (column) to nie ten sam typ DBMS-a co MongoDB (document).
Zamiast (jako specjalista w temacie) szerzyć informację na forum na temat różnic ciągniesz koc w swoją stronę.

1. "@vpiotr nie, nie wynika z tego, bo po pierwsze dokumentacja Mongo twierdzi, że to nie jest "eventually consistent data store", po drugie Mongo nie spełnia nawet warunków dla bycia "eventually consistent", ponieważ w większości trybów pracy możliwe jest utracenie potwierdzonego zapisu. "

To co dokumentacja twierdzi napisałem w komentarzu wyżej ("Na stronie projektu tego nie znajdziesz raczej"), jeśli niezbyt jasno to przepraszam.
Co do "po drugie" to jeśli chodzi Ci o zagadnienia z "aphyr.com" to patrz pkt. 3
Jeśli o coś innego to proszę o link.

Panczo napisał(a):

@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 ;))

Próbuję się czegoś dowiedzieć od bardziej doświadczonych kolegów :) Przedstawiam swoje opinie i albo ktoś skoryguje, albo nie. Moja opinia na temat mongo (właściwie na teamt obszaru zastosowania mongo) jest obecnie mniej-więcej taka jak już pisałem powyżej:

1. Nie ma czasu na pisanie swoich specjalistycznych baz danych.
2. Pojedyncze zapytanie wykonuje się np. 100 sekund, a dopuszczalny czas to np. 2 sekundy.
3. Są pieniądze na wynajęcie/zakup kilkudziesięciu - kilkuset komputerów.
   Jeśli wszystkie warunki są spełnione, to mongo jest dobrym rozwiązaniem dla projektu. Będę wdzięczny jeśli ktoś napisze że się mylę i dobrze uzasadni.

Pozdrawiam

P.S.
Bym zapomniał: nie widzę aby brak (złożonych) transakcji był problemem. Czy może ktoś podać konkretną-minimalną sytuację której w mongo nie da się rozwiązać z powodu braku (zlożonych) transakcji?

vpiotr napisał(a):

Dla Ciebie specjalnie: przykład jak pracuje się z MongoDB w C++ (bez JS):
https://www.mongodb.com/blog/post/introducing-new-c-driver

Przepraszam, ale nie jestem przekonany. W linku w którym podałeś jest przykład, a w tym przykładzie jest instrukcja:

col.find({})

Nie jestem pewny, ale ta klamerka {} może być zamieniana na JavaScript (ściśle JSON) i potem baza mongo może operować normanie na javascriptcie - czyli pośrednictwo JS może nadal być.

Swoją drogą, próbowałem kiedyś to skompilować i uruchomić pod Ubuntu (chyba Ubuntu w wersji 12)
https://mongodb.github.io/mongo-cxx-driver/mongocxx-v3/installation/
Nie udało mi się.

Pozdrawiam

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

Masz rację, że lepiej to nazywać operacją atomową. Ale zwróć uwagę, że istotą transakcji jest wlaśnie atomowość. Albo cała transakcja się udaje, albo nie. Więc spieramy się tylko o nazewnictwo, z punktu widzenia programisty mamy tak jakby transakcje w obrębie jednego dokumentu.

Do administratora:
Mam błąd gdy próbuję dodać komentarz. Gdy wklejam tutaj kod błędu, to post nie wysyła się.

Nie mogę komentarzy dodawać, jakiś błąd. :(

Sam "find" zwykle przykłady pokazują z JSON-em: http://www.slideshare.net/YnonPerek/mongodb-for-c-developers (od 23 slajdu), to operator $where akceptuje funkcje JavaScript (o ile driver na to pozwala). To co znalazłeś w tym przykładzie wygląda jak "find all". - vpiotr dzisiaj, 13:26

Tak, to jest find all. Chodzi o to, że zapytanie i tak i tak dociera do bazy w formacie bardzo podobnym lub takim samym jak json. Czyli ten driver ściśle nie udostępnia API w C++, ale udostepnia API w C++ do komunikowania się za pośrednictem JSON/BSON.

artur_bredzki napisał(a):

Nie mogę komentarzy dodawać, jakiś błąd. :(

Sam "find" zwykle przykłady pokazują z JSON-em: http://www.slideshare.net/YnonPerek/mongodb-for-c-developers (od 23 slajdu), to operator $where akceptuje funkcje JavaScript (o ile driver na to pozwala). To co znalazłeś w tym przykładzie wygląda jak "find all". - vpiotr dzisiaj, 13:26

Tak, to jest find all. Chodzi o to, że zapytanie i tak i tak dociera do bazy w formacie bardzo podobnym lub takim samym jak json. Czyli ten driver ściśle nie udostępnia API w C++, ale udostepnia API w C++ do komunikowania się za pośrednictem JSON/BSON.

Co tam pod spodem biega to mnie w zasadzie nie interesuje, ale możliwe że JSON/BSON.
Zajrzyj tutaj: https://github.com/mongodb/mongo-cxx-driver/tree/master/examples/mongocxx
w szczególności tu: https://github.com/mongodb/mongo-cxx-driver/blob/master/examples/mongocxx/aggregate.cpp

Cechy C++ są tu wykorzystane w minimalnym stopniu. Jedyne co masz charakterystyczne to budowanie struktur przy pomocy operatora

<<

, open_document, close_document - czyli możliwe że właśnie budowanie czegoś co potem staje się J(B)SON-em przed wysłaniem do serwera.

Mam podobny pogląd na te sprawy. Próbuję zrobić jakiś minimalny test. Udało mi się skompilować i zainstalować sterowniki do monog i postgresa. Za to nie mogę wyciągnąć inta z wyników zapytania. Bazują na tamtych przykładach:
https://mongodb.github.io/mongo-cxx-driver/mongocxx-v3/tutorial/

mongocxx::cursor cursor = collection.find(
  document{} << "i" << open_document <<
    "$gt" << 50 <<
    "$lte" << 100
  << close_document << finalize);
for(auto doc : cursor) {
  std::cout << bsoncxx::to_json(doc) << "\n";
}

Kto wie jak wyciągnąć jednego inta?

int sum = 0;
for(auto doc : cursor) {
  sum += doc["nazwa_pola"].get_int32(); // rzuca wyjątkiem
}

Pozdrawiam

podaj pełną treść komunikatu - vpiotr 12 minut temu

terminate called after throwing an instance of 'bsoncxx::v_noabi::exception'
what(): expected element type k_int32
The program has unexpectedly finished.

spróbuj użyć tak jak wyżej funkcji bsoncxx::to_json oraz element.type() - vpiotr 1 minuta temu

Z to_json działa bez zarzutu. WIdać że są same inty, więc niezgodność typów nie wchodzi w grę, chyba że to jest "int w stringu" i nie rzutuje automatycznie :/

Tak się nie kompiluje:

std::cout << doc["age"].type() << std::endl;

Nie ma przeciążonego operatora dla cout.

Aha, czyli to_string zwraca zwykły std::string - działa!
Jak się na niczym nie wyrżne, to za 30 minut wkleję najprostszy test mongo vs postgres.

Edit:

No to jest zaczątek kodu do porównywania mongo z postgresem.
Obie bazy wstawiają milion identycznych rekordów, a potem wyszukują tysiąc razy po nazwie.
Na razie żadnych indeksów, żadnych konfiguracji, itd.
Jakie czasy są u was?

Nie mogę wkleić kodu tutaj na forum, pojawia się jakiś błąd.
Więc daję linka:
http://pastebin.com/59xbvtgt

Pozdrawiam

Pierwszy update programu:
http://pastebin.com/r8FuRBhf

Program wygenerował takie oto wyjście:

test mong start...
171.277ms
sum_age = 49308
427.477ms
test pg start...
Opened database successfully: testm
Table created successfully
NOTICE:  relation "testcollection" already exists, skipping
194.207ms
sum_age = 49308
149.616ms

Jak to wyjście należy interpretować?
Mongo dodawało 1mln rekordów przez 171s, postgres przez 194s.
Mongo 1000 selectów wykonało przez 427 sekund, postgres przez 149s.
Suma kontrolna (sum_age) jest taka sama dla obu baz, czyli obie bazy (z dużym prawdopodobieństwem) pracowały na takich samych danych.
Wniosek: Postgres wyszukiwał prawie 3 razy szybciej.

Teraz bym musiał się upewnić, że Mongo ma dostatecznie dużo RAM, bo co do postgresa upewniłem się.

Pozdrawiam

tutaj wygrywa PG, teraz możesz zrobić drugi test - tym razem z sumami obsłużonymi w DBMSie. Przetwarzanie kursorowe jest zawsze gorsze. Jak to zrobić w Mongo - masz przykład ode mnie wyżej i jeszcze to: https://docs.mongodb.com/v3.2/reference/operator/aggregation/sum/ - vpiotr 1 godz. temu

Ok, zrobię. Z tego co pamiętam, na agregacjach mongo będzie jeszcze gorzej wypadało w porównaniu do postgresa.

@artur_bredzki plus ode mnie za dociekliwość, moje zdanie nt. testów znasz, ale śledzę uważnie to co robisz. - Panczo 31 minut temu

Za plusa dziękuję.

Każdy ma prawo do swojego zdania, ale jakieś obiektywne wnioski można wyciągnąć z testów, zwłaszcza gdy zrobi się sporo testów. Teraz widzimy że wyszukiwanie metodą fullscan po stringu jest wolniejsze. Oczywiście nie mamy 100% pewności czy nie istnieje jakaś opcja która wpłynie na wynik, albo że wynik się nie zmieni diametralnie gdy od czasu do czasu będą inserty. Ale mamy jakaś przesłankę, że postgres jest szybszy gdy trzeba przetworzyć wszystkie rekordy. Potem można zrobić test w którym drugi wątek od czasu do czasu doda lub usunię rekord - będzie kolejna nauka.

Pozdrawiam

P.S.
Admin wyłączył mi możliwość komentowania, czy to jakiś błąd mojej przeglądarki, czy tego serwisu? Nie mogę też wklejać długich listingów kodu.

artur_bredzki napisał(a):

Krolik napisał(a):

Co ma język do jakości optymalizatora?

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

Trudność napisania optymalizatora jest zależna głównie od semantyki języka zapytań oraz od tego co pod spodem wspiera baza danych, a nie od składni języka. Składnia to naprawdę najmniejszy problem. CQL cassandry jest składniowo bardzo podobny do SQLa (celowo), a optymalizacja jest trywialna w porównaniu z SQLem. Głównym powodem jest brak złączeń w Cassandrze. Domyślam się, że w Mongo będzie podobnie, bo Mongo też nie obsługuje złączeń, a złączenia (i podzapytania, i wykorzystanie perspektyw zmaterializowanych) są jednymi z najtrudniejszych elementów optymalizatora. Żadnej z tych rzeczy nie ma w Mongo, więc optymalizator ma je "z głowy".

artur_bredzki napisał(a):

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:

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.

A kto Ci każe przygotowywać plan zapytania za każdym razem?

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ć.

Tyle, że po pierwsze różnica między JS a C++ nie wynosi 100x a co najwyżej 10x, a po drugie przy braku złączeń to kompletnie nie ma znaczenia, bo liczba planów jaką musi rozważyć optymalizator jest zwykle w zakresie "jeden do kilkadziesiąt", z naciskiem na "kilka". W większości NoSQLi nie ma czegoś takiego jak wydzielony optymalizator, bo wyszukiwanie po kluczu głównym robi się zawsze tak samo. W zasadzie jedynym polem do popisu dla optymalizatora jest wybór odpowiedniego indeksu, ale tu zwykle też nie ma co optymalizować, tylko po prostu stosuje się heurystykę zachłanną typu "zacznij od warunku, który ma najlepszą selektywność i dla którego mamy jakiś indeks".

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:

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ą

Z tego sobie akurat zdaję sprawę. To było miało być troszkę ironiczne odniesienie do dyskusji czy JS przeszkadza w napisaniu szybkiej bazy.

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.

RAM jest drogi, znacznie droższy od SSD, a SSD jest z kolei znacznie droższe od HDD. Trzymanie wszystkich danych w RAMie to bezsensowne marnotrawstwo pieniędzy, no chyba że faktycznie nasz zbiór danych mieści się w kilkudziesięciu GB. Te dodatkowe shardery kosztują. Trzeba je kupić, mieć na nie miejsce, a następnie serwisować. No i prąd z gniazdka za darmo nie jest. Dlatego wydajność bazy danych dla zbiorów przekraczających wielkość RAMu jest nadal bardzo istotnym aspektem i jeszcze długo będzie.

BTW: "Fullscan" 256 GB danych w RAMie zajmie co najmniej kilka sekund, bez robienia czegokolwiek ciekawego z tymi danymi - tylko przesłanie ich z RAM do cache L1. W praktyce jeśli chcemy z tymi danymi coś zrobić, to raczej kilka minut. Jest to czas nieakceptowalny dla większości systemów baz danych, gdzie oczekiwane są odpowiedzi w czasie poniżej milisekundy, a nie w sekundach. Hurtowe przeglądanie danych jest interesujące tylko dla analityków.

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.
]

Czytałeś to w ogóle? Wiesz w ogóle kim jest autor tego bloga, który podlinkowałem i czym się zajmuje? Reputacja Aphyra (a dokładniej: Kyle Kingsbury, bo Aphyr to tylko psudo) miażdży reputację jakiegoś losowego tutoriala z netu, na dodatek pisanego dla wąskiej grupy odbiorców i to prawdopodobnie tylko na podstawie dokumentacji do Mongo. "System baz danych dba o synchronizację by każdy klient widział te same dane." - Bullshit, jakbym słyszał jakiegoś marketingowca. Może dba, ale mu to nie wychodzi, co Aphyr udowodnił. Aphyr stosuje naukową metodologię w swoich testach baz danych, a kod Jepsen jest otwarty i używany przez niektórych vendorów jako część oficjalnych testów (Cassandra regularnie przechodzi te testy przed każdym releasem). Jeśli tekst Cię nie przekonuje, że MongoDB ma problemy ze spójnością danych, to możesz wykonać wszystkie testy samodzielnie. W wyniku testów Jepsen w różnych bazach danych zostały poprawione dziesiątki błędów (nie tylko w Mongo, w Cassandrze również).

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.

Kwestia gustu.

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ń.

To że Ty miałeś problem nie oznacza, że inni mają. Mnie kiedyś postawienie Oracle zajęło 3 dni. Ogólnie jak gadam z ludźmi na różnych konferencjach, to nie mają problemów z postawieniem / używaniem Mongo na jednej maszynie. Schody są przy skalowaniu. Mamy dużo firm, które przeniosły się z Mongo na Cassandrę i jakoś nikt nie podnosił problemów, że "Mongo jest trudne".

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.

I jeśli tabela ma kilkadziesiąt TB, to będzie trwało to dzień, a wszystkie zapytania do tej tabeli w tym czasie nie będą działać, albo będą działać na 1/10 swojej wydajności, bo większość RDBMSów musi w takiej sytuacji przepisać całą tabelę na nowo. Poza tym w przypadku Mongo cała heca polega na tym, że nic nie trzeba robić z samą bazą. Wystarczy wrzucić nową wersję aplikacji.

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.

Nie widziałem niestety dobrych porównań mongo vs postgres. Teoretycznie nie ma powodów, aby baza danych typu MongoDB miała być wolniejsza, za to jest mnóstwo powodów dla których Postgres powinien być powolniejszy na jednym węźle. Ale możliwe, że Mongo ma jeszcze nadal jakieś problemy - nigdy nie należało do najszybszych NoSQLi, kiedyś miało global lock, który dość mocno negatywnie odbijał się na wydajności. Natomiast postgres nie ma szans z NoSQLami, które potrafią zapisywać/odczytywać z szybkością kilkadziesiąt-kilkaset tysięcy losowych wierszy na sekundę na jednym węźle i w milionach / s na klastrze przy bazach mających setki lub tysiące TB (AmazonDB, Cassandra, HBase itp). Nie ta skala. Postgres jest świetną bazą, ale transakcyjność ma olbrzymi wpływ na wydajność i skalowanie. Pamiętam, że jak mieliśmy 100 transakcji na sekundę z pojedynczego serwera, to był już szał i powód do świętowania.

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.

Cała sztuka właśnie polega na tym, aby tak zorganizować dane by nie robić innych operacji jak skoki do zaindeksowanych rekordów.
</quote>

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?

Podałem, ale widać nie przeczytałeś.
To jeszcze raz:
https://aphyr.com/posts/284-jepsen-mongodb
https://aphyr.com/posts/322-jepsen-mongodb-stale-reads

Krolik napisał(a):

artur_bredzki napisał(a):

Krolik napisał(a):

Co ma język do jakości optymalizatora?

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

Trudność napisania optymalizatora jest zależna głównie od semantyki języka zapytań oraz od tego co pod spodem wspiera baza danych, a nie od składni języka. Składnia to naprawdę najmniejszy problem.

Tak jak pisałem, to już jest nieaktualne w tym wątku.

Krolik napisał(a):

CQL cassandry jest składniowo bardzo podobny do SQLa (celowo), a optymalizacja jest trywialna w porównaniu z SQLem. Głównym powodem jest brak złączeń w Cassandrze. Domyślam się, że w Mongo będzie podobnie, bo Mongo też nie obsługuje złączeń, a złączenia (i podzapytania, i wykorzystanie perspektyw zmaterializowanych) są jednymi z najtrudniejszych elementów optymalizatora. Żadnej z tych rzeczy nie ma w Mongo, więc optymalizator ma je "z głowy".

Pod tym względem na pewno autorzy Mongo mieli zadanie uproszczone. Ale zlączenia to zapewne nie wszystko.

Krolik napisał(a):

artur_bredzki napisał(a):

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:

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.

A kto Ci każe przygotowywać plan zapytania za każdym razem?

Dane w bazie ulegają zmianom, nawet jeśli zapytanie jest identyczne, to zapamiętany plan szybko traci aktualność.

Krolik napisał(a):

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ć.

Tyle, że po pierwsze różnica między JS a C++ nie wynosi 100x a co najwyżej 10x, a po drugie przy braku złączeń to kompletnie nie ma znaczenia, bo liczba planów jaką musi rozważyć optymalizator jest zwykle w zakresie "jeden do kilkadziesiąt", z naciskiem na "kilka". W większości NoSQLi nie ma czegoś takiego jak wydzielony optymalizator, bo wyszukiwanie po kluczu głównym robi się zawsze tak samo. W zasadzie jedynym polem do popisu dla optymalizatora jest wybór odpowiedniego indeksu, ale tu zwykle też nie ma co optymalizować, tylko po prostu stosuje się heurystykę zachłanną typu "zacznij od warunku, który ma najlepszą selektywność i dla którego mamy jakiś indeks".

Nie mierzyłem czasów wykonania JS, ale myślę że jest dużo wolniejsza niż 100 razy. Po drugie nie wierzę że napisanie optymalizatora jest łatwe. Mongo pisali zapewne programiści mający sporą wiedzę, a z kilku prostych testów już wynika, że postgres wygrywa nawet 3 krotnie. Jakby było łatwe, to by Mongo działało szybko, zwłaszcza że 'złączenia mają z głowy'.

Krolik napisał(a):

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:

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ą

Z tego sobie akurat zdaję sprawę. To było miało być troszkę ironiczne odniesienie do dyskusji czy JS przeszkadza w napisaniu szybkiej bazy.

Ok.

Krolik napisał(a):

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.

RAM jest drogi, znacznie droższy od SSD, a SSD jest z kolei znacznie droższe od HDD. Trzymanie wszystkich danych w RAMie to bezsensowne marnotrawstwo pieniędzy, no chyba że faktycznie nasz zbiór danych mieści się w kilkudziesięciu GB. Te dodatkowe shardery kosztują. Trzeba je kupić, mieć na nie miejsce, a następnie serwisować. No i prąd z gniazdka za darmo nie jest. Dlatego wydajność bazy danych dla zbiorów przekraczających wielkość RAMu jest nadal bardzo istotnym aspektem i jeszcze długo będzie.

BTW: "Fullscan" 256 GB danych w RAMie zajmie co najmniej kilka sekund, bez robienia czegokolwiek ciekawego z tymi danymi - tylko przesłanie ich z RAM do cache L1. W praktyce jeśli chcemy z tymi danymi coś zrobić, to raczej kilka minut. Jest to czas nieakceptowalny dla większości systemów baz danych, gdzie oczekiwane są odpowiedzi w czasie poniżej milisekundy, a nie w sekundach. Hurtowe przeglądanie danych jest interesujące tylko dla analityków.

Generalnie klaster złożony z kilkuset komputerów jest drogi. 100 mocnych komputerów to jakieś 300-500tys pln. Jeśli coś ma działać wydajnie, to poza prostymi przypadkami HDD i nawet SSD odpadają. Co do fullskanu to chodziło mi o jakiś bardziej zaawansowany warunek, przynajmniej taki który nie jest łatwo indeksowalny, bo jeśłi można zaindeksować, to trzymanie w ram jest naprawdę bez sensu.

Krolik napisał(a):

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.
]

Czytałeś to w ogóle? Wiesz w ogóle kim jest autor tego bloga, który podlinkowałem i czym się zajmuje? Reputacja Aphyra (a dokładniej: Kyle Kingsbury, bo Aphyr to tylko psudo) miażdży reputację jakiegoś losowego tutoriala z netu, na dodatek pisanego dla wąskiej grupy odbiorców i to prawdopodobnie tylko na podstawie dokumentacji do Mongo. "System baz danych dba o synchronizację by każdy klient widział te same dane." - Bullshit, jakbym słyszał jakiegoś marketingowca. Może dba, ale mu to nie wychodzi, co Aphyr udowodnił. Aphyr stosuje naukową metodologię w swoich testach baz danych, a kod Jepsen jest otwarty i używany przez niektórych vendorów jako część oficjalnych testów (Cassandra regularnie przechodzi te testy przed każdym releasem). Jeśli tekst Cię nie przekonuje, że MongoDB ma problemy ze spójnością danych, to możesz wykonać wszystkie testy samodzielnie. W wyniku testów Jepsen w różnych bazach danych zostały poprawione dziesiątki błędów (nie tylko w Mongo, w Cassandrze również).

Może masz rację. W jakiej konkretnie sytuacji uaktywni się problem Mongo ze spójnością danych?

Krolik napisał(a):

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.

Kwestia gustu.

No tak.

Krolik napisał(a):

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ń.

To że Ty miałeś problem nie oznacza, że inni mają. Mnie kiedyś postawienie Oracle zajęło 3 dni. Ogólnie jak gadam z ludźmi na różnych konferencjach, to nie mają problemów z postawieniem / używaniem Mongo na jednej maszynie. Schody są przy skalowaniu. Mamy dużo firm, które przeniosły się z Mongo na Cassandrę i jakoś nikt nie podnosił problemów, że "Mongo jest trudne".

Zeszło mi cały dzień i nie miałem nawet drivera do mongo gotowego. Na drugi dzień owszem sie udało. Z postgresem zajmuje mi to 5 minut... Driver do mongo nawet się nie kompiluje przy użyciu standardowych narzędzi jakie są na linuxie - wiedziałeś o tym? Trzeba pobrać najnowszą wersję cmake, której nie ma jeszcze w repozytorium... I to nie jedyny problem.

Krolik napisał(a):

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.

I jeśli tabela ma kilkadziesiąt TB, to będzie trwało to dzień, a wszystkie zapytania do tej tabeli w tym czasie nie będą działać, albo będą działać na 1/10 swojej wydajności, bo większość RDBMSów musi w takiej sytuacji przepisać całą tabelę na nowo. Poza tym w przypadku Mongo cała heca polega na tym, że nic nie trzeba robić z samą bazą. Wystarczy wrzucić nową wersję aplikacji.

RDBMS się od dawna odgrażają, że trzymają każdą kolumnę osobno, więc nie powinno być problemów o jakich mówisz. Chyba że to tylko mit.

Krolik napisał(a):

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.

Nie widziałem niestety dobrych porównań mongo vs postgres. Teoretycznie nie ma powodów, aby baza danych typu MongoDB miała być wolniejsza, za to jest mnóstwo powodów dla których Postgres powinien być powolniejszy na jednym węźle. Ale możliwe, że Mongo ma jeszcze nadal jakieś problemy - nigdy nie należało do najszybszych NoSQLi, kiedyś miało global lock, który dość mocno negatywnie odbijał się na wydajności. Natomiast postgres nie ma szans z NoSQLami, które potrafią zapisywać/odczytywać z szybkością kilkadziesiąt-kilkaset tysięcy losowych wierszy na sekundę na jednym węźle i w milionach / s na klastrze przy bazach mających setki lub tysiące TB (AmazonDB, Cassandra, HBase itp). Nie ta skala. Postgres jest świetną bazą, ale transakcyjność ma olbrzymi wpływ na wydajność i skalowanie. Pamiętam, że jak mieliśmy 100 transakcji na sekundę z pojedynczego serwera, to był już szał i powód do świętowania.

Jak to potrafią odczytywać kilkadziesiąt-kilkaset tysięcy losowych wierszy na sekundę? Jeśli mówimy o HDD to ciężko 100 wierszy na sekundę odczytać i to dowolnemu oprogramowaniu.

Krolik napisał(a):

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.

Cała sztuka właśnie polega na tym, aby tak zorganizować dane by nie robić innych operacji jak skoki do zaindeksowanych rekordów.

A jeśli takie zaindeksowanie nie jest możliwe?

Krolik napisał(a):

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?

Podałem, ale widać nie przeczytałeś.
To jeszcze raz:
https://aphyr.com/posts/284-jepsen-mongodb
https://aphyr.com/posts/322-jepsen-mongodb-stale-reads

Hmmm, będę musiał spojrzeć. Bym wolał jakąś konkretną sytuację w której uaktywni się problem Mongo ze spójnością danych. Ale... mongo gwarantuje tylko atomowość zapisu dokumentu. Czyli co może się stać? Zapisuję dokument, w połowie zapisu pada zasilanie i po restarcie mam połowę starego dokumentu i połowę nowego? Nie wierzę żeby Mongo miało taki problem. Czy może inaczej: Dwa wątki piszą do tego samego dokumentu, połowa danych jest z jednego wątku, druga połowa z drugiego? Też mi się nie chce wierzyć aby miało takie problemy.

Pozdrawiam

nie wiem czy w ogóle jest opcja, wyłczeniakomentowania, ale tu faktycznie brakuje kogoś ktozna się na mongo i podpowie jak da mu boosta.. - Panczo wczoraj, 23:05

Może ktoś z nas odszuka jakieś ciekawe opcje konfiguracyjne, albo ktoś za jakiś czas odgrzebie ten wątek i coś dopowie. Z doświadczeń na postgresie wiem, że cuda mogą zdizałać jedynie indeksy i lepszy sprzęt (np. SSD i dużo RAM). Manipulacja innymi opcjami nie przyspiesza go tak bardzo. Myślę więc, że w Mongo też nie ma wiele cudownych opcji które może ustwić tylko wybitny specjalista.

Pozdrawiam

Ciąg dalszy testów.
Zanim będą agregacje, sprawdziłem wyszukiwanie po incie. Wyszukiwanie po incie, w przeciwieństwie do poprzedniego wyszukiwania po stringu, znacznie cześciej zwraca więcej niż jeden rekord. Więc też zostało lekko przetestowane przesyłanie danych i wydajność interfejsu - co jest ważne, bo w zwykłej pracy też trzeba korzystać z interfejsów.

Link do nowej wersji kodu:
http://pastebin.com/0tYPchz5

Wyniki na moim sprzęcie:

test mong start...
159.979s
sum_age = 1022250006
462.415s
test pg start...
Opened database successfully: testm
Table created successfully
NOTICE:  relation "testcollection" already exists, skipping
184.672s
sum_age = 1022250006
148.391s

Czyli postgres w tym teście jest 3.11 razy szybszy :D

Prośba, rzucicie okiem na ten kod, może coś skopałem? Jak każdy programista popełniam czasami błędy.

Pozdrawiam

Kolejny test.
Link do źródła:
http://pastebin.com/iQt5Gx2D

Wyniki:

test mong start...
533.208s
24.5435s
sum_age = 29904645759
11.3278s
test pg start...
Opened database successfully: testm
Table created successfully
609.409s
38.1475s
sum_age = 29904645759
15.3295s

Test polega na wstawieniu 3mln rekordów. Wydłużyłem napisy do 20 znaków w tym teście. Potem obie bazy zakładają indeks na pole tekstowe. W końcu obie bazy 60tys razy wyszukują rekordy po zaindeksowanym polu.

Mongo ( jak zwykle ) trochę szybciej wstawia rekordy. Mongo też trochę szybciej zakłada indeks. I wyszukuje też minimalnie szybciej. Oczywiście te uwagi tyczą się tego testu. Podsumowując: w końcu mamy jakieś wyszukiwanie w którym Mongo, co prawda niewiele, ale jest szybsze.

Pozdrawiam

23% to wcale nie tak niewiele, zważywszy że nie ma w tym teście jakieś wielkiej magii. Ciekaw jestem agregatów. - vpiotr 5 minut temu

W sumie 23% może oznaczać dużą różnicę, zależy do czego porównywać. Ja porównałem do poprzednich testów gdzie mongo było wolniejsze 300%, więc te 23% wydało mi się mało :)

Byłem teraz ciekawy, czy obie bazy są na tyle sprytne, aby wykorzystać indeks złożony do wyszukiwania po jednym polu. Obie bazy mają indeks na dwa pola (name,sname) a wyszukują po jednym polu (name).
Poza tym zmniejszyłem długość napisów, więc może się zdarzać, że jest więcej niż jeden rekord w wynikach wyszukiwania.

Kod źródłowy:
http://pastebin.com/Ba8WnbmM
Nie ufajcie mi na słowo że kod jest poprawny, sami sprawdźcie.

Wyniki

test mong start...
483.463s
21.7648s
sum_age = 5148170964253
43.5673s
test pg start...
Opened database successfully: testm
Table created successfully
544.366s
46.5662s
sum_age = 5148170964253
67.1479s

Widzimy że Mongo było szybsze w każdej operacji. Czy różnica jest duża, czy mała, niech każdy sam oceni.

Pozdrawiam

Jak to potrafią odczytywać kilkadziesiąt-kilkaset tysięcy losowych wierszy na sekundę? Jeśli mówimy o HDD to ciężko 100 wierszy na sekundę odczytać i to dowolnemu oprogramowaniu.

Pisałem o zapisach i odczytach. Dla zapisów jak najbardziej możliwe, bo zapisy nawet przypadkowych rowków da się zrobić aby na dysk szły sekwencyjnie. Dla odczytów możliwe jeśli zbiór roboczy mieści się w cache bazy (RAM) lub dane są na SSD. Przy czym nie oznacza to, że wszystkie dane muszą mieścić się w RAM / SSD. Niektóre bazy potrafią też dane pakować, więc możliwa jest sytuacja taka, że surowe dane nie mieszczą się w RAM / SSD, ale po spakowaniu już jak najbardziej się mieszczą. Jeden rdzeń nowoczesnego CPU potrafi rozpakowywać dane spakowane LZ4 z szybkością > 2 GB/s.

Zcentralizowany RDBMS ma generalnie trudniej z kilku powodów:

1. Konieczność sprawdzania przy zapisie, czy nie powtarza się klucz główny - czyli każdy INSERT pod spodem jest poprzedzony odczytem z indeksu.
2. Konieczność upewnienia się, że dane zostały fizycznie zapisane na dysk (fsync). NoSQL może wysłać dane do kilku replik i prawdopodobieństwo, że wszystkie padną na raz w kilka sekund, jest znikome, więc można robić fsync np. co 10 sekund a nie co transakcję lub kilka transakcji.
3. Bookkeeping związany z transakcjami ACID. Odczyty / zapisy powodują zakładanie blokad. To zajmuje pamięć i może powodować blokowanie wątków / wycofywanie transakcji, a to kosztuje i to niemało. Np. zawieszenie wątku lub procesu i przerzucenie rdzenia CPU na inny wątek to licząc koszt utracenia cache L1 koszt rzędu 100 tys. - 1 mln cykli CPU (czyli w skrajnych przypadkach nawet milisekundy).
4. Konieczność trzymania starych danych na potrzeby ACID. Bardzo długo jedną z głównych bolączek Postgresa było VACUUM.
5. Wszelkie sprawdzanie integralności danych (klucz obcy - klucz główny) czego NoSQLe zwykle nie robią.

To wszystko razem może ale nie musi opowodować gorszej wydajności na jednym serwerze. Zwykle RDBMSy względem baz NoSQL nadrabiają dojrzałością - w końcu teoretyczne podstawy tych baz opracowano w latach 70-tych albo i wcześniej, a NoSQLe są nowe i robią często bardzo głupie rzeczy.

BTW: Porównywanie takiego Postgresa z Mongo na jednym serwerze jest o tyle zabawne, że filozofie twórców tych baz są zupełnie różne i zupełnie inne cele im przyświecały.
Priorytety PostgreSQL (od najważniejszego):

1. Dane użytkownika to świętość. Nigdy nie zgubimy danych.
2. Dane mają być spójne, a system zawsze poprawnie działać.
3. Jeśli się da, postaramy się aby było szybko.
4. Jeśli jest już w miarę szybko, to jako bonus zrobimy aby było łatwo i przyjemnie dla admina.

Priorytety MongoDB:

1. JS jest teraz cool.
2. Ma być szybko. Bardzo szybko. I "webscale" cokolwiek to jest.
3. Jak zrobimy 1. i 2. to pomyślimy jak nie gubić danych.

Oczywiście prawdziwa zabawa zaczyna się na wielu serwerach.

Jeśli jeden serwer nie wystarcza, to w takim Postgresie walimy głową w ścianę i przepisujemu aplikację aby używała mniej złączeń, ewentualnie kupujemy mega-wypasiony-serwer za 50 tys. zł. Ostatecznie jednak jak ten mega serwer nie wyrobi to i tak skończy się na "shardach" i dostaniemy coś w rodzaju poor-man-NoSQL na Postgresie (piszę z własnego doświadczenia). W przypadku (dobrego) NoSQL dostawiamy po prostu więcej maszyn, bo aplikację mamy na to od początku gotową.

Podobnie jeśli nasz scentralizowany serwer PostgreSQL padnie, to o 2:00 w nocy dzwonimy po admina, aby przełączył na zapasowy (hot standby) i modlimy się aby system wstał. W przypadku (dobrego) NoSQL po prostu wymieniamy serwer bezstresowo (nie dotyczy Mongo) w poniedziałek rano, bo nawet jak do poniedziałku siądzie drugi z dziesięciu, to nic się nie stanie.

Krolik napisał(a):

Jak to potrafią odczytywać kilkadziesiąt-kilkaset tysięcy losowych wierszy na sekundę? Jeśli mówimy o HDD to ciężko 100 wierszy na sekundę odczytać i to dowolnemu oprogramowaniu.

Pisałem o zapisach i odczytach. Dla zapisów jak najbardziej możliwe, bo zapisy nawet przypadkowych rowków da się zrobić aby na dysk szły sekwencyjnie.

Operacje na danych owszem można sprowadzić jedynie do zapisów sekwencyjnych, ale nie wiem czy można zakutalizować indeksy jedynie poprzez sekwencyjne zapisy, chyba nie?

Krolik napisał(a):

Dla odczytów możliwe jeśli zbiór roboczy mieści się w cache bazy (RAM) lub dane są na SSD. Przy czym nie oznacza to, że wszystkie dane muszą mieścić się w RAM / SSD. Niektóre bazy potrafią też dane pakować, więc możliwa jest sytuacja taka, że surowe dane nie mieszczą się w RAM / SSD, ale po spakowaniu już jak najbardziej się mieszczą. Jeden rdzeń nowoczesnego CPU potrafi rozpakowywać dane spakowane LZ4 z szybkością > 2 GB/s.

Czyli nie mówimy już o HDD, tylko o SSD i RAM :)

Krolik napisał(a):

Zcentralizowany RDBMS ma generalnie trudniej z kilku powodów:

1. Konieczność sprawdzania przy zapisie, czy nie powtarza się klucz główny - czyli każdy INSERT pod spodem jest poprzedzony odczytem z indeksu.

Tak, ale z drugiej strony RDBMS nie wymusza definiowania unikalnych pól lub krotek.

Krolik napisał(a):

1. Konieczność upewnienia się, że dane zostały fizycznie zapisane na dysk (fsync).

Nie jestem pewny, ale fsync chyba można zrobić raz na N transakcji. Natomiast trzeba mieć pewność, że
logi do pliku dziennika są zapisywane w tej samej kolejności w jakiej zlecił to RDBMS.

Krolik napisał(a):

NoSQL może wysłać dane do kilku replik i prawdopodobieństwo, że wszystkie padną na raz w kilka sekund, jest znikome,

Jeśli komputery mają to samo źródło zasilania, to padają wszystkie równocześnie, nawet jak jest ich sto :) Dobra
baza musi umieć pracować i w takich warunkach.

Krolik napisał(a):

więc można robić fsync np. co 10 sekund a nie co transakcję lub kilka transakcji.

No nie jestem pewny, ale coś mi się zdaje, że sync wystarczy raz na N transakcji.

Krolik napisał(a):

1. Bookkeeping związany z transakcjami ACID. Odczyty / zapisy powodują zakładanie blokad. To zajmuje pamięć i może powodować blokowanie wątków / wycofywanie transakcji, a to kosztuje i to niemało. Np. zawieszenie wątku lub procesu i przerzucenie rdzenia CPU na inny wątek to licząc koszt utracenia cache L1 koszt rzędu 100 tys. - 1 mln cykli CPU (czyli w skrajnych przypadkach nawet milisekundy).

Generalnie zgadzam się, ale opracowano wiele algorytmów lockless - więc tutaj też bym był ostrożny że baza musi coś blokować.

Krolik napisał(a):

1. Konieczność trzymania starych danych na potrzeby ACID. Bardzo długo jedną z głównych bolączek Postgresa było VACUUM.

Czy te dane normalnie w dzienniku nie mogą być przechowywane? Myślę że tak.

Krolik napisał(a):

1. Wszelkie sprawdzanie integralności danych (klucz obcy - klucz główny) czego NoSQLe zwykle nie robią.

Można wyłączyć w relacyjnych.

Krolik napisał(a):

To wszystko razem może ale nie musi opowodować gorszej wydajności na jednym serwerze. Zwykle RDBMSy względem baz NoSQL nadrabiają dojrzałością - w końcu teoretyczne podstawy tych baz opracowano w latach 70-tych albo i wcześniej, a NoSQLe są nowe i robią często bardzo głupie rzeczy.

Tu się zgadzam całkowicie, mam duże obawy że NoSQL nie są zbyt dojrzałe.

Krolik napisał(a):

BTW: Porównywanie takiego Postgresa z Mongo na jednym serwerze jest o tyle zabawne, że filozofie twórców tych baz są zupełnie różne i zupełnie inne cele im przyświecały.
Priorytety PostgreSQL (od najważniejszego):

1. Dane użytkownika to świętość. Nigdy nie zgubimy danych.

Ale jeśli jest potwierdzenie zapisu w Mongo, to też danych się nie zgubi.

Krolik napisał(a):

1. Dane mają być spójne, a system zawsze poprawnie działać.

Jeśli ktoś chce spójności w mongo, to musi semafor założyć samemu. Pytanie czy warto bawić się w Mongo plus semafory, jeśli bazy relacyjne robią to same. Coż, programista zawsze będzie wiedział lepiej, że czasami można bezpiecznie obyć się bez semaforów, wyłączy je i uzyska większą wydajność. Poza tym poprawność działania jest wysokim priorytetem każdego oprogramowania. Nie zgodzę się że twórcy mongo mają gdzieś poprawność działania.

Krolik napisał(a):

1. Jeśli się da, postaramy się aby było szybko.

NoSQL nie możę przekładać szybkości nad poprawność działania, co komu po bazie która niepoprawnie działa? Nikt by tego nie używał.

Krolik napisał(a):

1. Jeśli jest już w miarę szybko, to jako bonus zrobimy aby było łatwo i przyjemnie dla admina.

Hmmm A mongo dba bardziej o wygodę admina niż o szybkość czy poprawność? Przepraszam, ale nie wierzę.

Krolik napisał(a):

Priorytety MongoDB:

1. JS jest teraz cool.

Czyli w mongo Twoim zdaniem najważniejszy jest marketing i to javoscriptowy? Zapędziłeś się. :D

Krolik napisał(a):

1. Ma być szybko. Bardzo szybko. I "webscale" cokolwiek to jest.
2. Jak zrobimy 1. i 2. to pomyślimy jak nie gubić danych.

Dopóki nie zobaczę, to nie uwierzę, że twórcy mongo świadomie zaakceptowali gubienie danych. A że ma błędy to jak już pisałem wyżej, też się obawiam.

Krolik napisał(a):

Oczywiście prawdziwa zabawa zaczyna się na wielu serwerach.

Jeśli jeden serwer nie wystarcza, to w takim Postgresie walimy głową w ścianę i przepisujemu aplikację aby używała mniej złączeń, ewentualnie kupujemy mega-wypasiony-serwer za 50 tys. zł. Ostatecznie jednak jak ten mega serwer nie wyrobi to i tak skończy się na "shardach" i dostaniemy coś w rodzaju poor-man-NoSQL na Postgresie (piszę z własnego doświadczenia). W przypadku (dobrego) NoSQL dostawiamy po prostu więcej maszyn, bo aplikację mamy na to od początku gotową.

Tutaj się zgadzam całkowicie. I oczywiście nie chodzi o sytuacje gdy jest dużo zapytań, tylko gdy są czasochłonne zapytania - wtedy mongo powinno 'jedynie' za koszt zakupu sprzętu działać lepiej niż inne bazy.

Krolik napisał(a):

Podobnie jeśli nasz scentralizowany serwer PostgreSQL padnie, to o 2:00 w nocy dzwonimy po admina, aby przełączył na zapasowy (hot standby) i modlimy się aby system wstał. W przypadku (dobrego) NoSQL po prostu wymieniamy serwer bezstresowo (nie dotyczy Mongo) w poniedziałek rano, bo nawet jak do poniedziałku siądzie drugi z dziesięciu, to nic się nie stanie.

Dlaczego nie dotyczy mongo? Chcę zmusić na własnym sprzęcie mongo do padu z którego się nie podniesie, podajcie mi instrukcję jak to mam zrobić.

Pozdrawiam

Kolejna wersja.

http://pastebin.com/bECyyrvc

Kod robi to samo co poprzednio, ale zaniepokoiła mnie kolejność wyszukiwania danych, więc zmieniłem na losową. Oczywiscie obie bazy danych mają tę samą losową kolejność.

Wyniki dla miliona rekordów:

test mong start...
160.838s
7.34536s
sum_age = 578659386420
6.20209s
test pg start...
Opened database successfully: testm
Table created successfully
183.393s
12.4854s
sum_age = 578659386420
8.74779s

Mongo wyszukuje szybciej 1.41 razy.

Wyniki dla 3mln rekordów:

test mong start...
493.996s
21.4062s
sum_age = 5148170964253
45.5369s
test pg start...
Opened database successfully: testm
Table created successfully
571.225s
45.471s
sum_age = 5148170964253
69.4376s

Mongo wyszukuje szybciej 1.52 razy

Może Mongo ma lepszy indeks, wyszukuje szybciej na większej ilości danych.

Pozdrawiam

Usunąłem unikalny klucz z postgresa, chciałem zobaczyć ile to przyspieszy.
Ten zabieg przyspieszył go o 1.02 razy - chyba niewiele. Mongo nadal wstawia
dane szybciej, a i pamiętajmy że mongo też dodaje unikalny klucz.
Tutaj cały kod:
http://pastebin.com/ze8iJB6X

Wyniki:

test mong start...
513.759s
21.5358s
sum_age = 5148170964253
43.9492s
test pg start...
Opened database successfully: testm
Table created successfully
558.05s
45.5798s
sum_age = 5148170964253
72.0245s

Pozdrawiam

artur_bredzki napisał(a):

Krolik napisał(a):

Jak to potrafią odczytywać kilkadziesiąt-kilkaset tysięcy losowych wierszy na sekundę? Jeśli mówimy o HDD to ciężko 100 wierszy na sekundę odczytać i to dowolnemu oprogramowaniu.

Pisałem o zapisach i odczytach. Dla zapisów jak najbardziej możliwe, bo zapisy nawet przypadkowych rowków da się zrobić aby na dysk szły sekwencyjnie.

Operacje na danych owszem można sprowadzić jedynie do zapisów sekwencyjnych, ale nie wiem czy można zakutalizować indeksy jedynie poprzez sekwencyjne zapisy, chyba nie?

Można. Zależy jaką mają strukturę.
Pierwszy lepszy przykład z brzegu: https://pdfs.semanticscholar.org/6fbf/c4fe76e152e4d371930a0069cf204e482528.pdf
A jako drugi przykład: w Cassandrze indeksy są niczym innym jak SSTable'ami, więc jako LSM zapisy są sekwencyjne.

Krolik napisał(a):

Zcentralizowany RDBMS ma generalnie trudniej z kilku powodów:

1. Konieczność sprawdzania przy zapisie, czy nie powtarza się klucz główny - czyli każdy INSERT pod spodem jest poprzedzony odczytem z indeksu.

Tak, ale z drugiej strony RDBMS nie wymusza definiowania unikalnych pól lub krotek.

Klucz główny jest opcjonalny? To jakaś nowość. Możliwe, że da się nagiąć niektóre bazy tak aby w tabeli nie było klucza głównego, ale na pewno będzie to wbrew ogólnie przyjętym zasadom modelowania danych relacyjnych.

Krolik napisał(a):

NoSQL może wysłać dane do kilku replik i prawdopodobieństwo, że wszystkie padną na raz w kilka sekund, jest znikome,

Jeśli komputery mają to samo źródło zasilania, to padają wszystkie równocześnie, nawet jak jest ich sto :) Dobra
baza musi umieć pracować i w takich warunkach.

Na to są UPSy. Raczej wszystkie na raz nie padną .Byle nie podpinać całej serwerowni na jednym UPSie ;).
Ale oczywiscie dobra baza musi umieć pracować bez tego, ale wydajność mocno dostanie w kość.

Krolik napisał(a):

więc można robić fsync np. co 10 sekund a nie co transakcję lub kilka transakcji.

No nie jestem pewny, ale coś mi się zdaje, że sync wystarczy raz na N transakcji.

Jeśli jesteś gotów stracić N transakcji to tak. Choć, w sumie, pewnie masz rację. Przy jednej replice i asynchronicznym hot-standby to i tak nie ma znaczenia bo zawsze dysk może paść totalnie, więc jak masz stracić to i tak stracisz to co się nie zdążyło zreplikować, nawet mając fsync co transakcję.

Krolik napisał(a):

1. Konieczność trzymania starych danych na potrzeby ACID. Bardzo długo jedną z głównych bolączek Postgresa było VACUUM.

Czy te dane normalnie w dzienniku nie mogą być przechowywane? Myślę że tak.

Może mogą, może nie, w Postgresie jednak są trzymane razem w tabeli "rozpychając ją od środka". Inne RDBMSy mają na to specjalne miejsce (np. Oracle).
Problemem jest zapewne to, że ten obszar musi dawać się łatwo indeksować / wyszukiwać tak samo jak stan bieżący, a zwykły dziennik raczej tego nie zapewnia. Tzn. dopóki transakcja nie doszła do COMMIT, to zmienione dane nie mogą wpływać na wyszukiwanie w innych transakcjach.

Krolik napisał(a):

To wszystko razem może ale nie musi opowodować gorszej wydajności na jednym serwerze. Zwykle RDBMSy względem baz NoSQL nadrabiają dojrzałością - w końcu teoretyczne podstawy tych baz opracowano w latach 70-tych albo i wcześniej, a NoSQLe są nowe i robią często bardzo głupie rzeczy.

Tu się zgadzam całkowicie, mam duże obawy że NoSQL nie są zbyt dojrzałe.

Na pewno są mniej dojrzałe, bo są krócej, ale nie należy tego odczytywać jako "nie nadają się na produkcję". Jeśli Netflix, Spotify, eBay, Apple, Walmart, Facebook, Google używają NoSQLi do swoich serwisów o krytycznym znaczeniu, do musi coś w tym być.

Krolik napisał(a):

BTW: Porównywanie takiego Postgresa z Mongo na jednym serwerze jest o tyle zabawne, że filozofie twórców tych baz są zupełnie różne i zupełnie inne cele im przyświecały.
Priorytety PostgreSQL (od najważniejszego):

1. Dane użytkownika to świętość. Nigdy nie zgubimy danych.

Ale jeśli jest potwierdzenie zapisu w Mongo, to też danych się nie zgubi.

Owszem, chyba że zapis potwierdził nam master, który myślał, że jest primary, ale nie był już primary w chwili zatwierdzania, a rzeczywisty master primary zrobi nam później rollback :D

Krolik napisał(a):

1. Jeśli się da, postaramy się aby było szybko.

NoSQL nie możę przekładać szybkości nad poprawność działania, co komu po bazie która niepoprawnie działa? Nikt by tego nie używał.

Nie chodzi o przekładanie szybkości nad poprawność działania, a o takie zdefiniowanie zasad co jest poprawne, a co nie, aby dało się uzyskać lepszą wydajność / skalowalność / dostępność. Spójność w sensie ACID jest bardzo restrykcyjna. W rzeczywistości najczęściej programiści mówiąc "spójność" potrzebują spójności na poziomie "linearizable" a nie w sensie "strict serializable". Często wystarcza też spójność ewentualna, która ma wiele zalet nad silniejszymi formami spójności bo pozwala na lepszą dostępność w przypadku awarii komuniakcji i mniejsze opóźnienia. Zresztą nawet w RDBMSach większość ustawia tylko zwykły "read committed" a nie "repeatable read" czy "serializable". Są pewne rzeczy, których nie da się przeskoczyć - tzn. nie da się zrobić systemu o wysokiej dostępności, odporności na awarie w komunikacji, rozległego geograficznie, liniowo skalowalnego i do tego dającego ACID.

Krolik napisał(a):

Priorytety MongoDB:

1. JS jest teraz cool.

Czyli w mongo Twoim zdaniem najważniejszy jest marketing i to javoscriptowy? Zapędziłeś się. :D

Krolik napisał(a):

1. Ma być szybko. Bardzo szybko. I "webscale" cokolwiek to jest.
2. Jak zrobimy 1. i 2. to pomyślimy jak nie gubić danych.

dopóki nie zobaczę, to nie uwierzę, że twórcy mongo świadomie zaakceptowali gubienie danych. A że ma błędy to jak już pisałem wyżej, też się obawiam.
</quote>

Nie, świadomie może nie. Prędzej przez brak kompetencji czy właśnie kierowanie się innymi priorytetami (np. napchanie wielu ficzerów zamiast pracy nad podstawami). Mongo ma trochę.... jakby to powiedzieć, kiepską reputację jeśli chodzi o gubienie danych czy ich spójność.

We wczesnych wersjach domyślnie było skonfigurowane tak, że nie gwarantowało utrwalenia danych na dysku, w celu wygrywania benchmarków:
http://pastebin.com/raw/FD3xe6Jt

Z tego co słyszałem większość tych problemów to już na szczęśnie przeszłość, jednak niesmak pozostał. No i nadal nie przechodzi testów Jepsen.
No i teraz jak to napisałem już 10Gen nie przyjdzie do mnie z ofertą pracy za $200K rocznie, widzisz co narobiłeś? :D

Kolejny test. Oto źródło:
http://pastebin.com/ZfGWfgM2
Sprawdźcie czy indeksy w obu bazach są 'takie same'.

Zmieniłem losowe napisy. Ponadto założyłem indeks na jedno pole a wyszukiwanie po dwóch polach (mowa o polach tekstowych). Sprytny optymalizator powinien wiedzieć, że pomimo iż indeks nie jest idealny do zapytania, to nadal opłaca się z niego korzystać. Jak sobie poradziły z tym zadaniem obie bazy?

test mong start...
479.227s
20.3888s
sum_age = 32062992062
66.963s
test pg start...
Opened database successfully: testm
Table created successfully
568.955s
69.3073s
sum_age = 32062992062
128.442s

Mongo jak zwykle ciut szybciej wstawia dane. Ponadto około 2 razy szybciej wyszukuje! Indeks mongo założyło ponad 3 razy szybciej, ale to (chyba) nie jest zbyt ważne.

Pozdrawiam

Kolejny eksperyment.
http://pastebin.com/ZtU3MqJy

Wszystko jak powyżej, ale indeksy są założone przed dodawaniem, więc sprawdzamy szybkość dodawania przy założonych indeksach.
Wyniki:

test mong start...
0.000671196s
603.09s
sum_age = 32062992062
56.6714s
test pg start...
Opened database successfully: testm
Table created successfully
0.0871107s
799.701s
sum_age = 32062992062
132.696s

Mongo 600s, postgres 800s. W wyszukiwaniu czas się jeszcze bardziej rozjechał, mongo 56s, postgres 132s - w tym przypadku już nikt nie będzie miał wątpliwości że mongo jest dużo szybsze.

Pozdrawiam

I kolejny raz porównujesz rzeczy nieporównywalne... W postgreSQL masz np. BIGSERIAL (sekwencer), PRIMARY KEY oraz NOT NULL w trzech polach. Na każdym z tych constraintów na pewno jest narzut. - Marcin.Miga dzisiaj, 12:40

Było już to wyjaśnione i uzasadnione w tym wątku. Powtórzę z grubsza. W mongo klucz jest dłuższy, też nie może być null i też nie może się powtarzać i też jest indeks na id. Ponadto był test w którym primary key w postgresie był wyłączony i nie przyspieszyło to postgresa zbyt dużo, zaledwie o 2%. Jakby ktoś nie wierzył, to wklejam statystyki kolekcji:

db.testcollection.stats();
{
        "ns" : "test.testcollection",
        "count" : 1000000,
        "size" : 112000000,
        "avgObjSize" : 112,
        "numExtents" : 12,
        "storageSize" : 174735360,
        "lastExtentSize" : 50798592,
        "paddingFactor" : 1,
        "paddingFactorNote" : "paddingFactor is unused and unmaintained in 3.0. It remains hard coded to 1.0 for compatibility only.",
        "userFlags" : 1,
        "capped" : false,
        "nindexes" : 1,
        "totalIndexSize" : 32458720,
        "indexSizes" : {
                "_id_" : 32458720  <-- tutaj
        },
        "ok" : 1
}

Pozdrawiam

Krolik napisał(a):

artur_bredzki napisał(a):

Krolik napisał(a):

Jak to potrafią odczytywać kilkadziesiąt-kilkaset tysięcy losowych wierszy na sekundę? Jeśli mówimy o HDD to ciężko 100 wierszy na sekundę odczytać i to dowolnemu oprogramowaniu.

Pisałem o zapisach i odczytach. Dla zapisów jak najbardziej możliwe, bo zapisy nawet przypadkowych rowków da się zrobić aby na dysk szły sekwencyjnie.

Operacje na danych owszem można sprowadzić jedynie do zapisów sekwencyjnych, ale nie wiem czy można zakutalizować indeksy jedynie poprzez sekwencyjne zapisy, chyba nie?

Można. Zależy jaką mają strukturę.
Pierwszy lepszy przykład z brzegu: https://pdfs.semanticscholar.org/6fbf/c4fe76e152e4d371930a0069cf204e482528.pdf
A jako drugi przykład: w Cassandrze indeksy są niczym innym jak SSTable'ami, więc jako LSM zapisy są sekwencyjne.

Zanim zacznę czytać powiedz mi, co nazywasz zapisami sekwencyjnymi. Dla mnie zapis sekwencyjny to jest zapis kolejnych bajtów pod kolejne adresy pamięci, bez np. cofania głowicy na poprzedni adres. Aby był sens rozmawiania o sekwencyjnym zapisie, to musi być przynajmniej 50MB zapisywanych pod ciągłymi adresami i ewentualnie dopiero po tym skok głowicy w 'losowe miejsce' na dysku.

Zcentralizowany RDBMS ma generalnie trudniej z kilku powodów:

1. Konieczność sprawdzania przy zapisie, czy nie powtarza się klucz główny - czyli każdy INSERT pod spodem jest poprzedzony odczytem z indeksu.

Tak, ale z drugiej strony RDBMS nie wymusza definiowania unikalnych pól lub krotek.

Klucz główny jest opcjonalny? To jakaś nowość. Możliwe, że da się nagiąć niektóre bazy tak aby w tabeli nie było klucza głównego, ale na pewno będzie to wbrew ogólnie przyjętym zasadom modelowania danych relacyjnych.

To chyba żart. Raczej większość baz nie wymuszała klucza głównego. Postgres na pewno nie wymusza, kilka postów wyżej wkleiłem kod z przykładem tworzenia tabeli bez klucza głównego. No i przy okazji sprawdziłem że unikalny klucz główny spowlnia wstawianie w postresie o jakieś 2%.

Krolik napisał(a):

Krolik napisał(a):

NoSQL może wysłać dane do kilku replik i prawdopodobieństwo, że wszystkie padną na raz w kilka sekund, jest znikome,

Jeśli komputery mają to samo źródło zasilania, to padają wszystkie równocześnie, nawet jak jest ich sto :) Dobra
baza musi umieć pracować i w takich warunkach.

Na to są UPSy. Raczej wszystkie na raz nie padną .Byle nie podpinać całej serwerowni na jednym UPSie ;).
Ale oczywiscie dobra baza musi umieć pracować bez tego, ale wydajność mocno dostanie w kość.

Nie wiem o ile to spowalnia bazy, myślę że nie powinno więcej niż dwukrotnie spowalniać operacji dodawania, modyfikacji i usuwania - ponieważ taki efekt uzyskuje się poprzez podwójny zapis. Myślę że to samo spowolnienie dotyczy nosql z powodu atomowości na poziomie dokumentu - też musi dwa razy zapisać na wypadek awarii zasilania.

Krolik napisał(a):

Krolik napisał(a):

więc można robić fsync np. co 10 sekund a nie co transakcję lub kilka transakcji.

No nie jestem pewny, ale coś mi się zdaje, że sync wystarczy raz na N transakcji.

Jeśli jesteś gotów stracić N transakcji to tak. Choć, w sumie, pewnie masz rację. Przy jednej replice i asynchronicznym hot-standby to i tak nie ma znaczenia bo zawsze dysk może paść totalnie, więc jak masz stracić to i tak stracisz to co się nie zdążyło zreplikować, nawet mając fsync co transakcję.

Tak, oczywiście chodziło o to, że kosztem ryzyka N ostatnich transakcji.

Krolik napisał(a):

Krolik napisał(a):

1. Konieczność trzymania starych danych na potrzeby ACID. Bardzo długo jedną z głównych bolączek Postgresa było VACUUM.

Czy te dane normalnie w dzienniku nie mogą być przechowywane? Myślę że tak.

Może mogą, może nie, w Postgresie jednak są trzymane razem w tabeli "rozpychając ją od środka". Inne RDBMSy mają na to specjalne miejsce (np. Oracle).
Problemem jest zapewne to, że ten obszar musi dawać się łatwo indeksować / wyszukiwać tak samo jak stan bieżący, a zwykły dziennik raczej tego nie zapewnia. Tzn. dopóki transakcja nie doszła do COMMIT, to zmienione dane nie mogą wpływać na wyszukiwanie w innych transakcjach.

Moje wyobrażenie o optymalnym rozwiązani tego problemy bylo takie, że dane trzymamy na dysku w pliku dziennika, a wyniki zapytań z innych transakcji korygujemy w oparciu o kopię tych danych w pamięci RAM. Ale może nie brnijmy w dalsze szczegóły w tym wątku. Faktem jest, że RDBMS umie cofnąć zmiany w kilku rekordach w kilku tabelach w przypadku awarii, a mongo umie tylko w jednym dokumencie.

Krolik napisał(a):

Krolik napisał(a):

To wszystko razem może ale nie musi opowodować gorszej wydajności na jednym serwerze. Zwykle RDBMSy względem baz NoSQL nadrabiają dojrzałością - w końcu teoretyczne podstawy tych baz opracowano w latach 70-tych albo i wcześniej, a NoSQLe są nowe i robią często bardzo głupie rzeczy.

Tu się zgadzam całkowicie, mam duże obawy że NoSQL nie są zbyt dojrzałe.

Na pewno są mniej dojrzałe, bo są krócej, ale nie należy tego odczytywać jako "nie nadają się na produkcję". Jeśli Netflix, Spotify, eBay, Apple, Walmart, Facebook, Google używają NoSQLi do swoich serwisów o krytycznym znaczeniu, do musi coś w tym być.

Ok, nie odebrałem tego jako kiepskie. Niedojrzałe znaczy dla mnie... 'niedokończone ale działają' i można na tym postawić aplikację.

Krolik napisał(a):

Krolik napisał(a):

BTW: Porównywanie takiego Postgresa z Mongo na jednym serwerze jest o tyle zabawne, że filozofie twórców tych baz są zupełnie różne i zupełnie inne cele im przyświecały.
Priorytety PostgreSQL (od najważniejszego):

1. Dane użytkownika to świętość. Nigdy nie zgubimy danych.

Ale jeśli jest potwierdzenie zapisu w Mongo, to też danych się nie zgubi.

Owszem, chyba że zapis potwierdził nam master, który myślał, że jest primary, ale nie był już primary w chwili zatwierdzania, a rzeczywisty master primary zrobi nam później rollback :D

Hmmm to może masz rację. A kiedy dochodzi do takiej sytuacji, że ten myśli że jest primary, a tamten robi rollback?

Krolik napisał(a):

Krolik napisał(a):

1. Jeśli się da, postaramy się aby było szybko.

NoSQL nie możę przekładać szybkości nad poprawność działania, co komu po bazie która niepoprawnie działa? Nikt by tego nie używał.

Nie chodzi o przekładanie szybkości nad poprawność działania, a o takie zdefiniowanie zasad co jest poprawne, a co nie, aby dało się uzyskać lepszą wydajność / skalowalność / dostępność. Spójność w sensie ACID jest bardzo restrykcyjna.

Rozumiem.

Krolik napisał(a):

W rzeczywistości najczęściej programiści mówiąc "spójność" potrzebują spójności na poziomie "linearizable" a nie w sensie "strict serializable".

Dla mnie system jest spójny jeśli:

1. są poprawnie wydzielone atomowe bloki instrukcji
2. efekt IO wszystkich bloków atomowych jest albo kompletny, albo żaden.
   Nie wiem czy to jest spójność linearizable czy strict serializable.

Krolik napisał(a):

Często wystarcza też spójność ewentualna, która ma wiele zalet nad silniejszymi formami spójności bo pozwala na lepszą dostępność w przypadku awarii komuniakcji i mniejsze opóźnienia.

Nie wiem co to jest spójność ewentualna i dlaczego pozwala na lepszą dostępność.

Krolik napisał(a):

Zresztą nawet w RDBMSach większość ustawia tylko zwykły "read committed" a nie "repeatable read" czy "serializable".

Często nie przeszkadzają brudne odczyty itd, często programista wie, że nie dojdzie do problemów z powodu mniejszej izolacji, czasami można tak zaprojektować system, aby wystarczyło read commited.

Krolik napisał(a):

Są pewne rzeczy, których nie da się przeskoczyć - tzn. nie da się zrobić systemu o wysokiej dostępności, odporności na awarie w komunikacji, rozległego geograficznie, liniowo skalowalnego i do tego dającego ACID.

Bym to ujął ciut inaczej: nie da się tanim kosztem zrobić systemu o wysokiej dostępności, odporności, itd. Dla niektórych systemów (oczywiście nie wszystkich) można zaprojektować specjalistyczną strukturę danych i system będzie odporny, szybki, itd - ale to są zazwyczaj bardzo drogie i czasochłonne rozwiązania.

Krolik napisał(a):

dopóki nie zobaczę, to nie uwierzę, że twórcy mongo świadomie zaakceptowali gubienie danych. A że ma błędy to jak już pisałem wyżej, też się obawiam.

Nie, świadomie może nie. Prędzej przez brak kompetencji czy właśnie kierowanie się innymi priorytetami (np. napchanie wielu ficzerów zamiast pracy nad podstawami). Mongo ma trochę.... jakby to powiedzieć, kiepską reputację jeśli chodzi o gubienie danych czy ich spójność.

W to już mogę uwierzyć że woleli szybko dodawać nowe bajery zamiast dopracować stare - to w ogóle zbyt częsta praktyka w IT.

Krolik napisał(a):

We wczesnych wersjach domyślnie było skonfigurowane tak, że nie gwarantowało utrwalenia danych na dysku, w celu wygrywania benchmarków:
http://pastebin.com/raw/FD3xe6Jt

Z tego co słyszałem większość tych problemów to już na szczęśnie przeszłość, jednak niesmak pozostał. No i nadal nie przechodzi testów Jepsen.
No i teraz jak to napisałem już 10Gen nie przyjdzie do mnie z ofertą pracy za $200K rocznie, widzisz co narobiłeś? :D

Nie wiedziałem że jestem taki niedobry.

co wy takie posty dziwnie długie piszecie. co sie dzieje - karolinaa 23 minuty temu

Miło Karolina że masz zdolność przekazywania skomplikowanych treść w krótkich słowach, mnie tego zawsze brakowało :)