Super robota panowie, doskonale przygotowany test wydajnościowy bardzo wnikliwa analiza wyników oraz doskonale zoptymalizowne środowisko (mimo że mongo było oszukane). Czekam na więcej.
Gdybyś miał 10-20 maszyn, na wszystkich zainstalował mongo - wtedy powinno być szybciej. Nie od aplikacji w której miałbyś 10-20 serwerów bazodanowych, ale masz skalowalność bez dodatkowej pracy, za darmo.
Jak dla mnie lepiej się przyłożyć i stworzyć dobry, skalowalny schemat SQL-owy na etapie projektowania (jeśli się da). To semi-automatyczne skalowanie sprawia że mongo jest bardzo wolne i nieoptymalne.
3. w porównaniu z SQL zużywa ogromne ilości zasobów (ID jest 16 bajtowe - mysql 4B, poza tym w każdym rekordzie trzeba zapisywać strukturę... następne zmarnowane kilkadziesiąt bajtów na rekord)
Żeby to szybko działało (i tak działa bardzo wolno w porównaniu z K/V storage czy bazami SQL) musisz mieć wszystkie dane w pamięci. Operacje SEEK są wolne, albo będziesz miał koszmarną wydajność albo zajedziesz im storage, chyba sam rozumiesz że za 10$ miesięcznie nie pozwolą nikomu ubić ich całej platformy.
Dlatego na pojedynczej maszynie normalny SQL będzie działał dużo szybciej i może przechować dużo więcej danych zanim się zaczną problemy.
Jeżeli chodzi o wydajność to mongo jest bardzo szybkie, potrzebujesz mieć odpowiednio pozakładane indeksy oraz odpowiednio dużo pamięci. Problem z wydajnością w prezentacji wynika najprawdopodobniej z drivera. To jest odczyt, jeżeli chodzi o zapis to MySQL nie ma szans jeżeli nie używasz opcji safe, oczywiście wiąże się to z ryzykiem wystąpienia konfliktów.
Teraz jeżeli chodzi o Amazon to robisz sobie raida z EBSów i masz wydajność (to dotyczy oczywiście też MySQL'a) no i sharding.
@kukems akurat odczytywałem po PRI KEY, pomimo tego było to 10-20x wolniejsze od tego samego zrealizowanego na mysql. Nie wiem czy to kwestia trzymania danych w JSON czy słabości samego rozwiązania bo serwery był na local (po TCP byłoby jeszcze wolniej). Zapis... no dobra zawsze będzie szybszy bo tak na prawdę to jest asynchroniczny i nie masz żadnej gwarancji że te dane w ogóle zostaną zapisane, więc coś za coś. Np. tyrant jest jakieś 2-3x szybszy niż mysql, mongo to masakra.
Super robota panowie, doskonale przygotowany test wydajnościowy bardzo wnikliwa analiza wyników oraz doskonale zoptymalizowne środowisko (mimo że mongo było oszukane). Czekam na więcej.
kukems 3 weeks ago
English title but no English subtitles...?
AnExplorer1000 2 months ago
@AnExplorer1000 hmm, what makes you think that the title is in english :)
mmgokce 1 month ago
@mmgokce OK, you got me with ''i'' but ''versus'' is certainly not a Polish word.
AnExplorer1000 1 month ago
@AnExplorer1000 there is a Poluck joke here somewhere
onjolt2 3 days ago
English subtitles please
krmmalik 3 months ago
Please add english subtitle.
m203cb 3 months ago
english please!...
ramstein74 3 months ago 7
Gdybyś miał 10-20 maszyn, na wszystkich zainstalował mongo - wtedy powinno być szybciej. Nie od aplikacji w której miałbyś 10-20 serwerów bazodanowych, ale masz skalowalność bez dodatkowej pracy, za darmo.
Jak dla mnie lepiej się przyłożyć i stworzyć dobry, skalowalny schemat SQL-owy na etapie projektowania (jeśli się da). To semi-automatyczne skalowanie sprawia że mongo jest bardzo wolne i nieoptymalne.
slawek1211 5 months ago
1. mongo jest niedojrzałe
2. działa dużo wolniej (zauważyłem to samo)
3. w porównaniu z SQL zużywa ogromne ilości zasobów (ID jest 16 bajtowe - mysql 4B, poza tym w każdym rekordzie trzeba zapisywać strukturę... następne zmarnowane kilkadziesiąt bajtów na rekord)
slawek1211 5 months ago
@slawek1211
Ad.1 lol
Ad.2 lol
Ad.3 Amazon EBS pricing:
$0.10 per GB-month of provisioned storage
kukems 3 weeks ago
@kukems
Żeby to szybko działało (i tak działa bardzo wolno w porównaniu z K/V storage czy bazami SQL) musisz mieć wszystkie dane w pamięci. Operacje SEEK są wolne, albo będziesz miał koszmarną wydajność albo zajedziesz im storage, chyba sam rozumiesz że za 10$ miesięcznie nie pozwolą nikomu ubić ich całej platformy.
Dlatego na pojedynczej maszynie normalny SQL będzie działał dużo szybciej i może przechować dużo więcej danych zanim się zaczną problemy.
slawek1211 3 weeks ago
@slawek1211
Jeżeli chodzi o wydajność to mongo jest bardzo szybkie, potrzebujesz mieć odpowiednio pozakładane indeksy oraz odpowiednio dużo pamięci. Problem z wydajnością w prezentacji wynika najprawdopodobniej z drivera. To jest odczyt, jeżeli chodzi o zapis to MySQL nie ma szans jeżeli nie używasz opcji safe, oczywiście wiąże się to z ryzykiem wystąpienia konfliktów.
Teraz jeżeli chodzi o Amazon to robisz sobie raida z EBSów i masz wydajność (to dotyczy oczywiście też MySQL'a) no i sharding.
kukems 3 weeks ago
@kukems akurat odczytywałem po PRI KEY, pomimo tego było to 10-20x wolniejsze od tego samego zrealizowanego na mysql. Nie wiem czy to kwestia trzymania danych w JSON czy słabości samego rozwiązania bo serwery był na local (po TCP byłoby jeszcze wolniej). Zapis... no dobra zawsze będzie szybszy bo tak na prawdę to jest asynchroniczny i nie masz żadnej gwarancji że te dane w ogóle zostaną zapisane, więc coś za coś. Np. tyrant jest jakieś 2-3x szybszy niż mysql, mongo to masakra.
slawek1211 3 weeks ago