O ile są wolniejsze lub szybsze bazy SQLowe od baz NOSQLowych? Jakby wziąć np. Mongo i MYSQLA do tego samego zadania, to która baza wypadnie szybciej i o ile?
z góry dzięki.
pozdro.
0
4
O ile są wolniejsze lub szybsze bazy SQLowe od baz NOSQLowych
Nie są.
4
Wybitny Kaczor napisał(a):
O ile są wolniejsze lub szybsze bazy SQLowe od baz NOSQLowych? Jakby wziąć np. Mongo i MYSQLA do tego samego zadania, to która baza wypadnie szybciej i o ile?
Bazy SQL są to transakcyjne bazy ogólnego przeznaczenia, bazy NoSQL są to bazy wyspecjalizowane do obsługi specyficznych zadań (mamy bazy dokumentowe, grafowe, klucz wartość, i wiele innych zapewne).
Bez podania konkretnego zadania nie da się ich porównać bo ich przeznaczenie jest zupełnie inne, co implikuję że bazę danych się dobiera do zadania, a nie na odwrót.
0
Wybitny Kaczor napisał(a):
O ile są wolniejsze lub szybsze bazy SQLowe od baz NOSQLowych? Jakby wziąć np. Mongo i MYSQLA do tego samego zadania, to która baza wypadnie szybciej i o ile?
z góry dzięki.
pozdro.
Ale jak chcesz porównywać? Jeśli w Mongo dasz 1000 sharderów to rząd przyspieszenia może wynosić właśnie 1000, bo mysql nie ma takich możliwości. Przy czym w Mongo ma trudniejszy w optymalizacji język (javascript) i (trochę zgaduję) włożyli mniej pracy w dopieszczenie optymalizatora zapytań, więc Mongo może być szybsze np. 300 razy albo 500. Oczywiście jeśli Twoja baza ma raptem 10 rekordów to przyspieszenia nie zauważysz, mam nadzieję że rozmawiamy o sensownych porównaniach.
Pozd
0
Shalom napisał(a):
O ile są wolniejsze lub szybsze bazy SQLowe od baz NOSQLowych
Nie są.
Dlaczego nie są?
1
Porównywanie wydajności silników baz danych nie jest zadaniem trywialnym. O ile dobrze pamiętam to ms i oracle zastrzegają w EULA ze nie można dowolnie robić i publikować testów porównawczych.
Mnie kojarzy się dość mocno dyskusja rozpoczęta na jakimś angielskim forum. W skrócie ktoś przeszedł z Ms SQL na postgresSQL bo ms mulił, a psql outofbox dzialal szybciej. Wiec wysnuł wniosek psql jest lepszy...
Po kilku poradach dba specjalizujących się w bazach ms, osiągnął lepszą wydajność niż psql.
Tu nie można wysnuć wniosku że mssql lepszy od psql, tylko co najwyżej że warto znać produkt którego się używa....
To jeden z wielu przykładów.
Z drugiej strony porównywanie baz NoSQL z bazami "sql" mija się z celem, bo uzywa się je w innych scenariuszach. Tu raczej temat czy dobrze się dobralo narzędzie do problemu.
0
Panczo napisał(a):
Z drugiej strony porównywanie baz NoSQL z bazami "sql" mija się z celem, bo uzywa się je w innych scenariuszach.
Rzadko te scenariusze są aż różne, w końcu jedno i drugie to baza do składowania danych.
W takim przykładowym Mongo można wydzielić shardery w teoretycznie dowolnej ilości, a w bazach sql (o ile się nie mylę)
nie ma takiej możliwoś. Oznacza to, że zapytanie na Mongo czy Hadoop na dużych zbiorach danych może działać
np. 5000 razy szybciej niż na postgresie, mysqlu, mssqlu, sqlite, itd.
0
@artur_bredzki ale potwierdzasz to co napisałem wcześniej. Bazę danych się dostraja. Jeżeli nie będę znał shardingu to mogę dojść do wniosku, że po przekroczeniu jakiegoś pułapu baza mongo jest nie wydajna...
0
Panczo napisał(a):
@artur_bredzki ale potwierdzasz to co napisałem wcześniej. Bazę danych się dostraja. Jeżeli nie będę znał shardingu to mogę dojść do wniosku, że po przekroczeniu jakiegoś pułapu baza mongo jest nie wydajna...
Potwierdzam że bazy się dostraja, ale to niewiele wnosi do tematu porównania wydajności.
Bazy nosql, przynajmniej takie jak mongo i hadoop, można dostrajać w sposób który jest (o ile wiem) całkowicie niedostępny dla
takich baz sql jak sqlite, mysql,mssql, postgres,oracle. Niedostępny sposób dostrajania o jakim piszę, to zrównoleglenie na
wielu komputerach.
Generalnie bazy sql są bardziej dopracowane, więcej pracy włożnono w dopracowanie sposobu przechowywania danych,
optymalizowanie zapytań, indeksowanie, itd. Inaczej ma się sprawa w przypadku nosql, bazy takie jak mongo i hadoop
nie są nawet uznawane za stabilne. Na przypadkach jedno-wątkowych zapewne bazy sql będą szybsze, tak też
wynika z kilku bardzo prostych testów jakie wykonałem. Jednak gdy takie mongo zainstalujemy np. na 5tys komputerów
to jak to w ogóle porównywać? Może się mylę, mże któraś z wymienionych przeze mnie baz danych ma możliwość
przetwarzania równoległego, może oracle - z tą bazą miałem najmniej do czynienia. Ale jeśli nie mają takich możliwości, to
mongo będzie (w przybliżeniu) tyle razy wydajniejsze, ile mamy sprzętu.
Pozdrawiam
0
Nie można za bardzo porównać baz danych, tym bardziej nosql z sql'owymi. Każda baza ma swoje mocne i słabsze strony i zależnie od projektu i znajomości danego oprogramowania powinno się ją wybierać. Mając tabelkę z prostą strukturą śmiem twierdzić że sql wygra. Natomiast jeśli w w tabeli w bazie nosql mieli byśmy wszystkie dane a w sql trzeba by było zrobić pierdyliard join'ów to nosql by wygrał (co też zależy od samego zapytania i optymalizacji bazy ale zakładam że w obydwu przypadkach wszystko jest dobrze zrobione).
0
artur_bredzki napisał(a):
Potwierdzam że bazy się dostraja, ale to niewiele wnosi do tematu porównania wydajności.
No nie zgodzę się, ze nic nie wnosi, w końcu porównania robi sie w takich samych warunkach, aby były miarodajne.
Co mi z porównania mysql-a z mongo rozsianym na kilku serwerach.
Ja może jestem starej daty, ale mnie uczono, że najpierw należy się zająć poprawą software, a później skalować sprzętowo. Nie jestem specjalistą od baz NoSQL, ale mam wrażenie, ze tu jest podobnie.
Przejaskrawiając, mozna by zaimplementować system z hierarchicznymi danymi w bazie mongoDB, pytanie brzmi po co? I tu wracam do tezy, że narzędzia wybiera sie do konkretnego problemu i porównywanie baz SQL vs noSQL, można potraktować jako ciekawostkę...
1
Panczo napisał(a):
Ja może jestem starej daty, ale mnie uczono, że najpierw należy się zająć poprawą software, a później skalować sprzętowo. Nie jestem specjalistą od baz NoSQL, ale mam wrażenie, ze tu jest podobnie.
Jesteś starej daty. Przykładowo - jeśli przez cały dzień pracy uda Ci się zmniejszyć zużycie pamięci programu na serwerze o 8GiB to czy będziesz z siebie dumny? Pewnie tak... a biznesowo jest to takie sobie.
W końcu tyle ramu to koszt jakieś 250 PLN. A dzień pracy programisty.... koszt firmy miedzy 500PLN a 4000PLN . Oczywiście jak coś bedzie chodzić długo - to przez rok, ze względu na zużycie prądu, koszty chmury - może się ten dzień zwrócić.
Ale ja nawet jak sam sobie pisze to po prostu czasem biegne do sklepu po nowy RAM - nie mam czasu na pierd... - szkoda tylko, że poprzednia generacja notebooków utknęła na 16gb, a tyle to mi posortowanie 13 integerów zajmuje (Permutation Sortem :-)).
0
NickOver napisał(a):
Nie można za bardzo porównać baz danych, tym bardziej nosql z sql'owymi.
Można porównywać pod wieloma względami.
NickOver napisał(a):
Każda baza ma swoje mocne i słabsze strony i zależnie od projektu i znajomości danego oprogramowania powinno się ją wybierać.
Owszem. Ale jeśli baza, albo grupa baz, się nie skaluje, to są jej słabe strony.
NickOver napisał(a):
Mając tabelkę z prostą strukturą śmiem twierdzić że sql wygra.
I tu są indeksy i tu. I tu i tu można wyszukiwać po indeksie, po bit-mapie lub fullscanem. I tu i tu programiści mogą dać ciała i nie zaimplementować wykorzystania indeksu w jakiejś sytuacji. Jednak jeśli obie implementacje co do funkcjonalności i jakości są podobne, to wygra ta, która dobrze się paralelizuje. Myślę, że w mongo jest niewiele gorszej jakości niż popularne bazy sql. Więc przez skalowanie będzie wygrywało - oczywiście nie w przypadku gdy szukamy jednego rekordu i obie bazy mają dobre indeksy.
</quote> To jest wieloaspektowe. Same JOINY mogą (odwrotnie niż piszesz) pomóc w optymalizacji zapytania. Ale Mongo może zadziać szybciej bez tej optymalizacji dzięki zrównolegleniu.NickOver napisał(a):
Natomiast jeśli w w tabeli w bazie nosql mieli byśmy wszystkie dane a w sql trzeba by było zrobić pierdyliard join'ów to nosql by wygrał (co też zależy od samego zapytania i optymalizacji bazy ale zakładam że w obydwu przypadkach wszystko jest dobrze zrobione).
0
Panczo napisał(a):
artur_bredzki napisał(a):
Potwierdzam że bazy się dostraja, ale to niewiele wnosi do tematu porównania wydajności.
No nie zgodzę się, ze nic nie wnosi, w końcu porównania robi sie w takich samych warunkach, aby były miarodajne.
Co mi z porównania mysql-a z mongo rozsianym na kilku serwerach.
A co mi z tego, że mysql działa 2 razy szybciej, jeśli dokupienie 10 komputerów nic go nie przyspieszy?
Panczo napisał(a):
Ja może jestem starej daty, ale mnie uczono, że najpierw należy się zająć poprawą software, a później skalować sprzętowo. Nie jestem specjalistą od baz NoSQL, ale mam wrażenie, ze tu jest podobnie.
W przypadku zgrubnych optymalizacji, które nie wymagają dużego nakładu pracy, prawdą jest to co napisałeś. Ale pisanie swojej specjalistycznej bazy w C++ to robi się tylko wtedy, gdy z serwerowni znikną chociaż z 3 szafy.
Panczo napisał(a):
Przejaskrawiając, mozna by zaimplementować system z hierarchicznymi danymi w bazie mongoDB, pytanie brzmi po co? I tu wracam do tezy, że narzędzia wybiera sie do konkretnego problemu i porównywanie baz SQL vs noSQL, można potraktować jako ciekawostkę...
Ale w drugą stronę też to działa: jeden system można wykonać w oparciu o wiele różnych baz danych. Porównując działanie systemu na różnych bazach będziemy mieli ciekawe porównanie baz danych.
Pozdrawiam
1
Do wszystkich którzy tak zachwalają skalowanie sprzętowe i twierdz, że mam podejście starej daty;)
Skalowanie sprzętowe w pewnych określonych przypadkach jest jak najbardziej ok. Zawsze jednak trzeba zacząć od przyczyny problemu.
Obrazowo i jaskrawie, jak mam dziurę w dachu i kapie mi woda do pokoju, to mogę skupić się na podstawianiu coraz większych misek, a nawet zrobienia systemu odprowadzania wody kapiącej z sufitu, tylko to nie będzie optymalizacja.
Trzeba pamiętać,że bazy danych nie działają jako osobny byt i problemy nie wynikają z ułomności silnika tylko jego wykorzystanie przez np. aplikacje. Zawsze możnadodać RAM-u, węzeł klastra itd. problemem będzie jak to nie rozwiąże problemu.
I tak skalowanie sprzętowe nie jest rozwiązaniem na wszystkie problemy i dokładanie/rozbudowa sprzętów nie zawsze pomaga, najważniejsza jest diagnoza problemu.
Kilka przykładów z branży:
-
Jak przyszedł boom na nasza-klasa.pl okazalo się, że jedyna serwerowania która to pociągnie to był Amazon (mogę się mylić co do marki ale chyba to był amazon). Co się okazało mimo mozliwości technicznych, około pół roku programiści zmieniali kod aby wykorzystać dobrodziejstwo skalowania...
-
Kiedyś zostałem poproszony o sprawdzenie dlaczego aplikacja wolno działa, bo wypasiony serwer pododawali ile się ramu i procków a jest wolno.
Diagnoza:baza miala ponad 9 GB a postawiona była na MS SQL Express (ograniczenie na RAM i procesory) -
Kiedyś sprawdzałem mulącą bazę, znowu wypasiony sprzęt.
Diagnoza: baza nie miała, żadnych indeksów -
Byłem trzecim z kolei gościem wezwanym do optymalizacji bo baza zwalniła. Sprawa juz rozchodziła się o zakup nowego serwera, bo stary rozbudowany do granic.
Diagnoza: uszkodzony dysk macierzy, kontroler przeszedł w tryb protected i maksymalnie zwolnił działanie.
Mógłbym tak długo, wiem że pamięć i sprzęt jest coraz tańszy, ale to nie zwalnia od myślenia nad przyczynami. Widzę jednak ostatnio sporo "specjalistów" którzy jedyne co potrafią zaproponować to rozbudowę sprzętową, bez analizy tego co tak naprawdę jest problemem.
0
artur_bredzki napisał(a):
A co mi z tego, że mysql działa 2 razy szybciej, jeśli dokupienie 10 komputerów nic go nie przyspieszy?
Przyspieszy MySQL też da się skalować sprzętowo.
artur_bredzki napisał(a):
W przypadku zgrubnych optymalizacji, które nie wymagają dużego nakładu pracy, prawdą jest to co napisałeś. Ale pisanie swojej specjalistycznej bazy w C++ to robi się tylko wtedy, gdy z serwerowni znikną chociaż z 3 szafy.
Pisząc o warstwie programowej nie piszę o pisaniu własnej db, a diagnozowaniu przyczyn problemu.
artur_bredzki napisał(a):
Ale w drugą stronę też to działa: jeden system można wykonać w oparciu o wiele różnych baz danych. Porównując działanie systemu na różnych bazach będziemy mieli ciekawe porównanie baz danych.
Będzie ciekawe, ale IMO tylko ciekawe, bo cel determinuje narzędzie, nie na odwrót.
1
jarekr000000 napisał(a):
Panczo napisał(a):
Ja może jestem starej daty, ale mnie uczono, że najpierw należy się zająć poprawą software, a później skalować sprzętowo. Nie jestem specjalistą od baz NoSQL, ale mam wrażenie, ze tu jest podobnie.
Jesteś starej daty. Przykładowo - jeśli przez cały dzień pracy uda Ci się zmniejszyć zużycie pamięci programu na serwerze o 8GiB to czy będziesz z siebie dumny? Pewnie tak... a biznesowo jest to takie sobie.
W końcu tyle ramu to koszt jakieś 250 PLN. A dzień pracy programisty.... koszt firmy miedzy 500PLN a 4000PLN . Oczywiście jak coś bedzie chodzić długo - to przez rok, ze względu na zużycie prądu, koszty chmury - może się ten dzień zwrócić.
Ale ja nawet jak sam sobie pisze to po prostu czasem biegne do sklepu po nowy RAM - nie mam czasu na pierd... - szkoda tylko, że poprzednia generacja notebooków utknęła na 16gb, a tyle to mi posortowanie 13 integerów zajmuje (Permutation Sortem :-)).
Kiedyś na studiach (tzn. gdzieś w 2009/10 musiało to być) na jakimś seminarium koleś tłumaczył, że u nich w firmie nie optymalizują, bo jak im spada wydajność, to po prostu kupują kolejnego poleasingowego PII 400MHz na giełdzie komputerowej koło klubu Stodoła, i on im obsługuje dodatkowe 5k żądań na sekundę. Technologia to oczywiście PHP.
Tak mi się tylko przypomniało.
0
Panczo napisał(a):
Do wszystkich którzy tak zachwalają skalowanie sprzętowe i twierdz, że mam podejście starej daty;)
Ja o czym innym piszę, ciut bardziej w temacie wątku, mam nadzieję że to jest jasne.
Panczo napisał(a):
Skalowanie sprzętowe w pewnych określonych przypadkach jest jak najbardziej ok. Zawsze jednak trzeba zacząć od przyczyny problemu.
To tak jak z porównaniem dwóch samochodów, sprawdzamy który jak szybko jeździ, jednak zawsze trzeba zacząć od wejścia do samochodu i
odpalenia silnika. Zakładamy że problem już jest zdiagnozowany.
Panczo napisał(a):
Obrazowo i jaskrawie, jak mam dziurę w dachu i kapie mi woda do pokoju, to mogę skupić się na podstawianiu coraz większych misek, a nawet zrobienia systemu odprowadzania wody kapiącej z sufitu, tylko to nie będzie optymalizacja.
Przykład który podałeś nie jest dobrą analogią do skalowania. Kapie woda z sufitu. Bez skalowania: podstawiam sztywną tacę ze szklankami. Obojętnie ile szkalnek stoi na tacy, to po napełnieniu jednej muszę podejść i coś zrobić. Ze skalowaniem podstawiam tacę która automatycznie się obraca i podstawia kolejną szklankę.
Panczo napisał(a):
Trzeba pamiętać,że bazy danych nie działają jako osobny byt i problemy nie wynikają z ułomności silnika tylko jego wykorzystanie przez np. aplikacje. Zawsze możnadodać RAM-u, węzeł klastra itd. problemem będzie jak to nie rozwiąże problemu.
To mi się kojarzy z bazą postgresql: baza dobrze się zrównolegla, ale w aplikacji zrównoleglenie w całości zrób se sam.
Panczo napisał(a):
I tak skalowanie sprzętowe nie jest rozwiązaniem na wszystkie problemy i dokładanie/rozbudowa sprzętów nie zawsze pomaga, najważniejsza jest diagnoza problemu.
W ogóle nie ma jednego lekarstwa na wszystkie problemy.
Panczo napisał(a):
- Jak przyszedł boom na nasza-klasa.pl okazalo się, że jedyna serwerowania która to pociągnie to był Amazon (mogę się mylić co do marki ale chyba to był amazon). Co się okazało mimo mozliwości technicznych, około pół roku programiści zmieniali kod aby wykorzystać dobrodziejstwo skalowania...
Bo robili to ręcznie (z tego co czytałęm w C++), a nie skorzystali z bazy która oferuje skalowanie.
Panczo napisał(a):
Kiedyś zostałem poproszony o sprawdzenie dlaczego aplikacja wolno działa, bo wypasiony serwer pododawali ile się ramu i procków a jest wolno.
Diagnoza:baza miala ponad 9 GB a postawiona była na MS SQL Express (ograniczenie na RAM i procesory)Kiedyś sprawdzałem mulącą bazę, znowu wypasiony sprzęt.
Diagnoza: baza nie miała, żadnych indeksówByłem trzecim z kolei gościem wezwanym do optymalizacji bo baza zwalniła. Sprawa juz rozchodziła się o zakup nowego serwera, bo stary rozbudowany do granic.
Diagnoza: uszkodzony dysk macierzy, kontroler przeszedł w tryb protected i maksymalnie zwolnił działanie.
To taka optymalizacja na poziomie gimnazujm ;-)
Panczo napisał(a):
Mógłbym tak długo, wiem że pamięć i sprzęt jest coraz tańszy, ale to nie zwalnia od myślenia nad przyczynami. Widzę jednak ostatnio sporo "specjalistów" którzy jedyne co potrafią zaproponować to rozbudowę sprzętową, bez analizy tego co tak naprawdę jest problemem.
To że akurat rozmawiamy o skalowaniu, nie oznacza, że umiemy zaproponować tylko skalowanie.
Pozdrawiam
0
Panczo napisał(a):
artur_bredzki napisał(a):
A co mi z tego, że mysql działa 2 razy szybciej, jeśli dokupienie 10 komputerów nic go nie przyspieszy?
Przyspieszy MySQL też da się skalować sprzętowo.
Mogę poprosić jakiegoś linka do tutoriala o skalowaniu MySQL?
Pozdrawiam
0
@artur_bredzki nie jestem specem od MySQL, to że wiem, ze można go skalować nie znaczy że wiem jak ;) Ale aby nie być gołosłownym: http://www.oracle.com/us/products/mysql/scaling-web-databases-461055.pdf
Co do pozostałej wypowiedzi do mojego posta to chciałem zwrócić tylko uwagę, że jak już coś się porównuje to robi się to w określonych warunkach dla każdej z baz.
Dlatego należy odrzucić opowiadanie o możliwościach skalowania, bo to do niczego nie prowadzi, mogę porównywać np mondeo z insignią, ale ktoś mi zarzuci, ze wybrałem nie najlepszy silnik, albo że zamiast benzyny mogłem do testów wybrać diesla itd.
Dlatego stoję na stanowisku, że bezpośrednie porównywanie silników jest ciekawe, ale nie do końca miarodajne. Im więcej rozmawiam z ludźmi którzy pozjadali zęby na DBA tym bardziej jestem przekonany, że najważniejsza jest wiedza o produkcie który się używa
0
Panczo napisał(a):
@artur_bredzki nie jestem specem od MySQL, to że wiem, ze można go skalować nie znaczy że wiem jak ;) Ale aby nie być gołosłownym: http://www.oracle.com/us/products/mysql/scaling-web-databases-461055.pdf
No właśnie ja też nie wiem jak, a w przypadku postgresa wręcz wiem że nie można (o ile nie napisze się samemu, o ile ktoś nie napisze i się nie skopiuje, itd). W przypadku mongo skalowałem i widziałem jak inny skalują - więc jakieś minimum wiem aby się wypowiadać. Kiedyś napaliłem się i czytałem podobny materiał do postgresa o skalowaniu, ostatecznie jednak z artykułu wynikło, że właśnie trzeba samemu sobie zrobić skalowanie. Spróbuję się wczytać w tekst który podałeś - zobaczymy.
Panczo napisał(a):
Co do pozostałej wypowiedzi do mojego posta to chciałem zwrócić tylko uwagę, że jak już coś się porównuje to robi się to w określonych warunkach dla każdej z baz.
To oczywiste.
Panczo napisał(a):
Dlatego należy odrzucić opowiadanie o możliwościach skalowania, bo to do niczego nie prowadzi, mogę porównywać np mondeo z insignią, ale ktoś mi zarzuci, ze wybrałem nie najlepszy silnik, albo że zamiast benzyny mogłem do testów wybrać diesla itd.
Dlaczego nie widzisz innej możliwości porównywania baz danych? Idąc za Twoim przykładem, trzeba mysqla odpalić na 2xi7 i 64GB RAM, a mongo na Atom 1GB RAM. Można zrobić test uczciwy, obie bazy na tych samych danych, obie na tym samym sprzęcie, obie stuningowane pod dany test.
Panczo napisał(a):
Dlatego stoję na stanowisku, że bezpośrednie porównywanie silników jest ciekawe, ale nie do końca miarodajne. Im więcej rozmawiam z ludźmi którzy pozjadali zęby na DBA tym bardziej jestem przekonany, że najważniejsza jest wiedza o produkcie który się używa
To też oczywiste że najważniejsza jest wiedza o produkcie. I ta wiedza nie wyklucza miarodajności testów. To troche tak, jakbym powiedział Ci: pojedź samochodem na drugi koniec Europy. Ty byś mi odpowiedział, że to nie jest możliwe, bo musisz coś jeść, pić i spać przez tyle czasu. Ja nie mówię, że masz pojechać bez snu, jedzenia i picia :) Tak samo jak nie mówię, że wiedza nie jest ważna. Po prostu zawężam rozmowę do testów i porównań baz danych.
Wyobraź sobie że masz jakiś system. W ramach tego systemu mam np. 10 czasochłonnych zapytań. Projektujesz bazę pod np. 2 silniki sql i 1 no-sql. Optymalizujesz każdą bazę, zakładasz indeksy, jeśli baza umożliwia - dokupujesz sprzętu. Wychodzi Ci, że na jednym silniku wszystkie zapytania działają najszybciej. Dlaczego nie skorzystrać z nauki jaką dał ten test i nie użyć właśnie tego najszybszego silnika?
Pozdrawiam
0
artur_bredzki napisał(a):
Panczo napisał(a):
@artur_bredzki nie jestem specem od MySQL, to że wiem, ze można go skalować nie znaczy że wiem jak ;) Ale aby nie być gołosłownym: http://www.oracle.com/us/products/mysql/scaling-web-databases-461055.pdf
No właśnie ja też nie wiem jak, a w przypadku postgresa wręcz wiem że nie można (o ile nie napisze się samemu, o ile ktoś nie napisze i się nie skopiuje, itd). W przypadku mongo skalowałem i widziałem jak inny skalują - więc jakieś minimum wiem aby się wypowiadać. Kiedyś napaliłem się i czytałem podobny materiał do postgresa o skalowaniu, ostatecznie jednak z artykułu wynikło, że właśnie trzeba samemu sobie zrobić skalowanie. Spróbuję się wczytać w tekst który podałeś - zobaczymy.
Strasznie trudno przebrnąć przez marketingowy bełkot, mało technicznych informacji, a przykładu to chyba żadnego nie ma.
Tabelę umie podzielić na węzły - fajnie. Ale czy w ogole można wykonać joina na podzielonych tabelach?
Nie widzę tam takich możliwości jakie ma mongo.
Pozdrawiam
0
artur_bredzki napisał(a):
Dlaczego nie widzisz innej możliwości porównywania baz danych? Idąc za Twoim przykładem, trzeba mysqla odpalić na 2xi7 i 64GB RAM, a mongo na Atom 1GB RAM. Można zrobić test uczciwy, obie bazy na tych samych danych, obie na tym samym sprzęcie, obie stuningowane pod dany test.
Mam wrażenie, ze kręcimy się w kółko ;) Zwracam uwagę, że porównuje dwa silniki: no to biorę serwer na którym testuje (lub dwa bliźniacze) i TYLKO na jednej konfiguracji sprzętowej testuje bazę. Dlatego rozmowa o skalowaniu sprzętowym nie ma sensu (w tym kontekście). Oczywiście możemy rozmawiać o możliwościach, ale to NIE JEST związane z testem. I tylko to staram się zaznaczyć. Nie odbieram nikomu prawa do skalowania, ale warunki brzegowe moją być TAKIE SAME dla wszystkich.
artur_bredzki napisał(a):
Wyobraź sobie że masz jakiś system. W ramach tego systemu mam np. 10 czasochłonnych zapytań. Projektujesz bazę pod np. 2 silniki sql i 1 no-sql. Optymalizujesz każdą bazę, zakładasz indeksy, jeśli baza umożliwia - dokupujesz sprzętu. Wychodzi Ci, że na jednym silniku wszystkie zapytania działają najszybciej. Dlaczego nie skorzystrać z nauki jaką dał ten test i nie użyć właśnie tego najszybszego silnika?
To nie jest prosta zależność wolno/szybko. Przykład: powiedzmy, że mam silnik SQL (nazwijmy go X) i silnik non SQL (nazwijmy go Y). Y nie wspiera kluczy obcych, ale jest niebywale wydajny w insertach. X jest wolniejsze, ale narzut dodatkowych zapytań do Y w celu zapewniania integralnosci niwelują tą róznicę.
Gdzieś kiedyś czytałem, ze jak już optymalizujemy to nie patrzymy na benchmarki, bo na tym etapie jest już za późno.
Co do skalowalności mySQL to gdzieś mi sie obiło dawno temu o uszy, ze to działa i to od osoby zaznajomionej z tematem. Jednak tu musiałby się jakiś specjalista wypowiedzieć...
0
Panczo napisał(a):
artur_bredzki napisał(a):
Dlaczego nie widzisz innej możliwości porównywania baz danych? Idąc za Twoim przykładem, trzeba mysqla odpalić na 2xi7 i 64GB RAM, a mongo na Atom 1GB RAM. Można zrobić test uczciwy, obie bazy na tych samych danych, obie na tym samym sprzęcie, obie stuningowane pod dany test.
Mam wrażenie, ze kręcimy się w kółko ;) Zwracam uwagę, że porównuje dwa silniki: no to biorę serwer na którym testuje (lub dwa bliźniacze) i TYLKO na jednej konfiguracji sprzętowej testuje bazę. Dlatego rozmowa o skalowaniu sprzętowym nie ma sensu (w tym kontekście). Oczywiście możemy rozmawiać o możliwościach, ale to NIE JEST związane z testem. I tylko to staram się zaznaczyć. Nie odbieram nikomu prawa do skalowania, ale warunki brzegowe moją być TAKIE SAME dla wszystkich.
Nie rozumiem. Chyba nie chcesz powiedzieć, że testy skalowania nie mają sensu na jednej maszynie?
Panczo napisał(a):
artur_bredzki napisał(a):
Wyobraź sobie że masz jakiś system. W ramach tego systemu mam np. 10 czasochłonnych zapytań. Projektujesz bazę pod np. 2 silniki sql i 1 no-sql. Optymalizujesz każdą bazę, zakładasz indeksy, jeśli baza umożliwia - dokupujesz sprzętu. Wychodzi Ci, że na jednym silniku wszystkie zapytania działają najszybciej. Dlaczego nie skorzystrać z nauki jaką dał ten test i nie użyć właśnie tego najszybszego silnika?
To nie jest prosta zależność wolno/szybko. Przykład: powiedzmy, że mam silnik SQL (nazwijmy go X) i silnik non SQL (nazwijmy go Y). Y nie wspiera kluczy obcych, ale jest niebywale wydajny w insertach. X jest wolniejsze, ale narzut dodatkowych zapytań do Y w celu zapewniania integralnosci niwelują tą róznicę.
Gdzieś kiedyś czytałem, ze jak już optymalizujemy to nie patrzymy na benchmarki, bo na tym etapie jest już za późno.
Oczywiście wynik testu nie musi być taki piękny jaki dla przykładu podałem. Nie musi być tak, że mamy N problematycznych zapytań i na jednym z silników wszystkie N zapytań działaja szybciej.
Może być 10 cieżkich zapytań, 2 mogą dziać najszybciej na silniku X, 3 na silniku Y, 5 na Z, przy czym te 5 zapytań z Z rzadziej się wywołuje niż te 2 z X, a te 3 z Z jeszcze nie wiadomo jak często, bo to będzie zależało od użytkowników. Pewnie że wyniki testów nie muszą w sposób oczywisty wskazywać na najlepszy silnik do danego zastosowania.
Panczo napisał(a):
Co do skalowalności mySQL to gdzieś mi sie obiło dawno temu o uszy, ze to działa i to od osoby zaznajomionej z tematem. Jednak tu musiałby się jakiś specjalista wypowiedzieć...
Wierzę że mysql umie rozbić dane z jednej tabeli na N węzłów. Ale jak na takiej strukturze można wydajnie zrobić JOIN? W pewnym sensie i postgres się paralelizuje, bo ma replikację - tyle że to trochę za mało. Co mi po replikacji, jeśli zapytanie trwa 1000s, a mam maksymalnie 1-2s na wykonanie zapytania?
Pozdrawiam
0
Artur wróćmy do meritum, odłożę dywagacje na temat metodyki przeprowadzania testów.
Moje zdanie jest takie:
Warto śledzić i sprawdzać, w wolnej chwili nawet dociekać co jest lepsze/gorsze. Z bazami to jest jednak tak, że żaden test/porównanie nie da mi odpowiedzi na pytanie czy MOJE bazy będą wydajniejsze na innym silniku czy nie. Bo porównania nie porównują moich danych i struktur tylko jakieś problemy które mnie nie dotyczą. Wiedza z takich testów to ciekawostka, bo nie uwzględnia mojego środowiska itd.
Nie neguje wyników testów, ale tez na ślepo nie wyciągam wniosków. Dla przykładu co sensownego mozna powiedziec o takim "benchmarku": https://github.com/reoxey/benchmark
Mozna też zapoznać sie z tym https://blog.michaelckennedy.net/2010/04/29/mongodb-vs-sql-server-2008-performance-showdown/ i poczytać komentarze pod postem.
Reasumując sam przymierzam się do uzycia jakiejś bazy No SQL ale nie produkcyjnie tylko w hobbistycznym projekcie, bo chcę poznać z czym to się je i nawet jakbyś mi gwarantował, ze jest 100% szybszy od ms SQL (bo akurat tego używam najcześciej) to nie przejdę na technologie której nie znam...
0
Panczo napisał(a):
Artur wróćmy do meritum, odłożę dywagacje na temat metodyki przeprowadzania testów.
Moje zdanie jest takie:
Warto śledzić i sprawdzać, w wolnej chwili nawet dociekać co jest lepsze/gorsze.
A żeby wiedzieć co jest szybsze/wolniejsze to trzeba uruchomić test i zmierzyć czas. Każdy producent bazy powie o swojej że jest najlepsza, czytanie niewiele wniesie.
Panczo napisał(a):
Z bazami to jest jednak tak, że żaden test/porównanie nie da mi odpowiedzi na pytanie czy MOJE bazy będą wydajniejsze na innym silniku czy nie. Bo porównania nie porównują moich danych i struktur tylko jakieś problemy które mnie nie dotyczą. Wiedza z takich testów to ciekawostka, bo nie uwzględnia mojego środowiska itd.
Nie zgodzę się.
Po pierwsze nie można powiedzieć że 'żadne', ponieważ właśnie test na Twojej oryginalnej strukturze, ewentualnie ze zmianami wprowadzonymi specjalnie pod testowany silnik, będzie testem wręcz idealnym. Po drugie, jeśli zrobisz setki mini testów na wielu bazach, to potem nabierzesz intuicji w wyborze dobrej bazy dla konkretnego zadania. Oczywiście nie ma prostego wzrou matematycznego do którego podstawisz zadanie i otrzymasz najlepszą bazę. Ale po takim treningu na testach nabierzesz bardzo dobrego wyczucia co w jakich sytuacjach zazwyczaj działa szybciej i z dużym prawdopodobieństwem wybierzesz najlepszy silnik do zadania. Oczywiście takich testów ani takigo doświadczenia nie zdobywa się przez miesiąc, ale przez lata. Żeby nie było nieporozumień - ja nie mam takiego doświadczenia, może mam minimalne w postgresie i absolutnie minimalne w mongo.
Panczo napisał(a):
Nie neguje wyników testów, ale tez na ślepo nie wyciągam wniosków. Dla przykładu co sensownego mozna powiedziec o takim "benchmarku": https://github.com/reoxey/benchmark
Mozna też zapoznać sie z tym https://blog.michaelckennedy.net/2010/04/29/mongodb-vs-sql-server-2008-performance-showdown/ i poczytać komentarze pod postem.
Z jednego prostego testu faktycznie nie da się wyciągnąć wniosków, ani nabrać doswiadczenia. Ale tak jak pisałem wyżej, ze 100 różnych testów można takie wnioski wyciągać.
Panczo napisał(a):
Reasumując sam przymierzam się do uzycia jakiejś bazy No SQL ale nie produkcyjnie tylko w hobbistycznym projekcie, bo chcę poznać z czym to się je i nawet jakbyś mi gwarantował, ze jest 100% szybszy od ms SQL (bo akurat tego używam najcześciej) to nie przejdę na technologie której nie znam...
Też często wybieram coś co jest gorsze, ale lepiej znam. Nie oznacza to wcale, że testowanie i porównywanie baz danych jest bezcelowe.
Pozdrawiam