MongoDB dla sporej ilości danych

[gutek 23]

Obecnie korzystam z mysql i póki co jest mi dobrze (sharding po stronie aplikacji) ale chciałbym sprawdzić jak może wyglądać praca na bazie nosql dla tego samego projektu i mam kilka pytań na które albo znalazłem odpowiedź nie koniecznie mnie zadowalającą (mało konkretną) albo jej nie znalazłem w sieci.

 

Pytania będą za chwilę najpierw chciałbym opisać sytuację:

- mam na kilku serwerach bazy danych o łącznej pojemności około 1,5 TB tj napisałem sharding mysql jest po stronie aplikacji która odpowiednio rozdziela dane po między serwerami.

- select i insert śmigają bez problemu ale przy kasowaniu większej ilości danych bez optymalizacji tabeli nie mogę odzyskać powierzchni na dysku a przy tabelach np. 20 gb optymalizacja to problem, nie mam partycjonowania tabel bo sporo mnie kosztuje rozmiar indeksu unikalnego który musiałby objąć więcej kolumn dla poprawnego partycjonowania.

- sam sprzęt nie stanowi problemu

 

Z mongo bawię się ale na mniejszych rozmiarach tzn kilka gb łącznie i trudno mi wyciągnąć odpowiednie wnioski tym bardziej, że sporo czasu zajmuje mi obecna praca więc mongo jest bardziej dorywczo w wolnych chwilach a uzupełnienie mongo danymi żeby zrobić odpowiednie testy może zająć sporo czasu..

 

Jakie mam wątpliwości co do mongo:

1) jak się zachowuje pojedyncza instancja w przypadku skasowania większej liczby danych czy rozmiar na dysku zostaje zwolniony bez dodatkowych czasochłonnych operacji ? Jak to będzie w przypadku shardingu, gdy kasujemy sporo danych?

2) czy przy rozmiarze kolekcji np 20 gb można szybko wykonać dobry backup? (pomijamy replikację póki co)

3) czy ktoś z Was ma sharding bez replikacji ? co w przypadku awarii instancji z pozostałymi danymi na innych instancjach, mam aplikację która może sobie pozwolić na wyłączenie (awarię) np pojedynczej instancji o ile jest możliwe przywrócenie danych dla konkretnego uszkodzonego elementu shardingu

4) czy ważna jest kolejność np. wyłączania serwerów, które wchodzą w skład shardingu ?

5) w mysql mam w wielu wierszach puste komórki (kolumny muszą być dla wybranych wierszy uzupełnione) wg tego co czytałem to mongo dzięki temu że nie ma określonej struktury może zaoszczędzić sporo miejsca (dysk, ram) bo tych komórek po prostu nie będzie, czy tak ?

6) jak szybko może wykonać się odtworzenie backupu kolekcji np. o rozmiarze 20 gb ?

 

Byłbym wdzięczny za odpowiedź osób które mają doświadczenie z mongo ale o większych rozmiarach muszę znaleźć dobre rozwiązanie, bo oczekuje w tym roku podwojenia ilości danych

[Misiek08 285]

Ja jak zawsze z pytaniem lekko offtopowym - musi być Mongo? Jest Couchbase, Aerospike i kilka innych, które też dają sobie radę.

 

Z Mongo jest tak, że działa fajnie, ale tylko jak przekopiesz całą dokumentację i ustawisz wszystkie potrzebne opcje. Swego czasu domyślne wartości prowadziły do sytuacji, że klient potwierdzał zapis danych zanim zostały potwierdzone przez serwer bazy. Oczywiście w skrajnym przypadku, ale dało się do takiej sytuacji doprowadzić przy słabej sieci.

Edytowano Luty 27, 2016 przez Misiek08 (zobacz historię edycji)

[gutek 23]

Wybrałem mongo ze wzgledu na jego "prostą" obsługę, właśnie testuje różne warianty żeby przekonać się samemu co i jak przy ilości 0,5T danych..

 

Póki co daje mi do myślenia pewien przykład rozwiązania struktury pomiędzy mysql a mongo tzn w mysql muszę zastosować pewien podziała danych na odrębne tabele ze względu na ich ilość i specyfikę, a w mongo przerobiłem schemat bazy i np. w kolekcji mam połączone wiele tabel na zasadzie to co było w różnych tabelach i dotyczyło konkretnego elementu teraz stanowi w mongo jego poddokument (child), dzięki czemu niby powinno być mniej indeksów i teoretycznie mniej zajętej przestrzeni, bo korzystam do wyszukania z indeksu dla dokumentu po czym przeglądam wg potrzeb jego poddokumenty (tu mam dodane dane z różnych tabel) itp, Obecnie wgrywają się dane, ciekaw jestem wydajności dla takiego rozwiązania.. Nie zawsze potrzebuje pobierać poddokumenty i tu mnie ciekawi jak będzie z prędkością i co w przypadku przeszukania tylko poddokumentów po konkretnym polu dla np. 500 mln wartości tak aby wyświetlić dokumenty (parent)..

[Pan Kot 1535]

w mysql muszę zastosować pewien podziała danych na odrębne tabele

 

Nigdy nie powinno być czegoś takiego, w skrajnym przypadku ultra dużych danych możesz przeznaczyć oddzielną tabelę do tymczasowego zapisywania kluczy głównych wierszy, którymi jesteś zainteresowany, i potem z nich robić where. Dzieląc dane na kilka tabel łamiesz co najmniej kilka postaci normalnych i prowadzisz do degradacji wydajności. MySQL wie lepiej jak sobie radzić z dużą ilością danych, zadaniem administratora jest odpowiedni dobór indeksów pod najczęściej wykonywane zapytania, oraz niwelowanie złych zapytań takich jak joiny na innych polach niż te indeksowane.

 

Generalnie moje zdanie raczej nie będzie jakoś specjalnie użyteczne, ale zauważyłem, że nie ma dużej różnicy w wydajności między bazami SQL, a NoSQL, oczywiście wtedy kiedy testujemy obydwa rozwiązania należycie. Te dwa typy się nieco różnią i w zależności od swojej wiedzy, umiejętności, jak i doboru oprogramowania możesz mieć zarówno wzrost jak i degradację wydajności.

 

Przykładowo pod słowem "MySQL" kryje się najczęściej wersja Oraclowa, która dużo pozostawia do życzenia. Postgres, Percona czy MariaDB radzą sobie o wiele lepiej. Podobnie jest z NoSQL, chociaż tutaj akurat nie jestem w stanie powiedzieć co teraz jest najszybsze.

 

Warto się zastanowić czy rzeczywiście jest sens inwestować w NoSQL swój czas, zamiast przejrzeć co można by poprawić z aktualnym setupem. Przykładowo, sam miałem SQLkę, która wykonywała się dobre 8-9 sekund, bo bazowała na znalezieniu konkretnych userów spełniających warunki X. Zmieniłem SQLkę odwracając ją, czyli ze wszystkich userów odejmuję tych nie spełniających warunków X, i wydajność wzrosła dziesięciokrotnie, a SQLka zwraca te same wyniki.

 

NoSQL jest fajny, miło się na niego programuje, ale póki co zostaję przy swoich doświadczeniach i stwierdzam, że odpowiednio zoptymalizowany SQL, zarówno po stronie aplikacji, bazy, jak i serwera - będzie szybszy, a w najgorszym przypadku porównywalny do rozwiązań NoSQL. Sam wielokrotnie próbowałem się przekonać, robiąc benchmarki, próbując sobie wmówić, że programowanie pod NoSQL jest łatwiejsze, szybsze i bardziej przenośne... I suma sumarum nie udało mi się do niego przekonać. Nie mam żadnych dobrych argumentów dlaczego NIE używać NoSQL, ale argumentów ZA również mi brakuje, toteż stwierdzam że skoro już masz aplikację działającą na SQL, to warto się zastanowić nad poprawą tego co działa wolniej, aniżeli rezygnacji z tego na rzecz czegoś co niekoniecznie może działać szybciej. Nie ma nic gorszego niż strata czasu na coś, z czego nie ma żadnego pożytku.

 

Oczywiście to tylko moje 3 grosze, jestem pewny że znajdą się osoby, które będą usilnie twierdziły, że NoSQL przebija pod każdym względem SQL, tak samo jak i Ci co stwierdzą, że SQL > NoSQL pod każdym względem - ja staram się być obiektywny i sam robić testy, a niestety z nich żadnych dobrych argumentów nie wyciągnąłem.

Edytowano Luty 28, 2016 przez Archi (zobacz historię edycji)

[gutek 23]

 

Nigdy nie powinno być czegoś takiego, w skrajnym przypadku ultra dużych danych możesz przeznaczyć oddzielną tabelę do tymczasowego zapisywania kluczy głównych wierszy, którymi jesteś zainteresowany, i potem z nich robić where. Dzieląc dane na kilka tabel łamiesz co najmniej kilka postaci normalnych i prowadzisz do degradacji wydajności. MySQL wie lepiej jak sobie radzić z dużą ilością danych, zadaniem administratora jest odpowiedni dobór indeksów pod najczęściej wykonywane zapytania, oraz niwelowanie złych zapytań takich jak joiny na innych polach niż te indeksowane.

 

W przypadku gdy miałem w jednej tabeli 500 mln wierszy i 1 tabela zajmowała około 300 gb wydajność była "średnia", a wyobraź sobie optymalizację 1 tabeli, wówczas blokuje na sporą część dnia a może i dłużej całą tabelę.. W sytuacji kiedy podzieliłem dane na kilka tabel mam kilka korzyści:

1) indeks mieści się w ramie (indeks pojedynczej tabeli)

2) w przypadku optymalizacji tabeli blokuje tylko konkretną tabelę i w tym czasie aplikacja z niej nie korzysta ale system pracuje dalej

3) zwiększyłem dzięki temu wydajność widać to po statystykach zapytań.

 

Do samego Mongo też nie jestem przekonany ale martwi mnie przyrost danych, mongo lepiej poradzi sobie z shardingiem niż mysql, które wg mnie wogóle sobie nie radzi:) cały podział danych na serwery realizuje aplikacja.

 

PS. Odnosząc się do polecanych percona, mariadb czy innych ja na działanie (prędkość, jakość) oryginalnego mysql nie narzekam, z wydajności jestem zadowolony

Edytowano Luty 28, 2016 przez gutek (zobacz historię edycji)

[Pan Kot 1535]

Locki na całą tabelę masz tylko wtedy, gdy serwer SQL nie może sobie poradzić inaczej, przykładowo:

UPDATE tabela SET kolumna1=1 WHERE kolumna2=2

Jeśli na kolumnie2 założony jest indeks to tylko te wiersze, gdzie warunek jest spełniony będą zablokowane, w przeciwnym wypadku - cała tabela. Dlatego zamiast dzielić wspólne dane na wiele tabel, wystarczy pozakładać odpowiednie indeksy po warunkach where.

 

Tak jak mówiłem, zadaniem administratora jest odpowiednie indeksowanie, a nie łamanie postaci normalnych poprzez rozrzucanie tych samych danych na kilka tabel. I do tego też nawiązuję pisząc wyżej - jak się człowiek zna, to nie będzie miał większych problemów, a wydajność zarówno SQL jak i NoSQL będzie zbliżona. Jakbyś nie znał mechanizmu lockowania w MySQL to w przypadku zmiany możesz odczuć większą wydajność bo np. NoSQL może out of the box realizować blokady zupełnie inaczej, co nie zmienia faktu że w MySQL też można to efektywnie zrobić. Nie upieram się, że wydajność rozwiązania A jest lepsza niż rozwiązania B czy vice versa, jedynie twierdzę że zmiana SQL na NoSQL w imię zasady "bo tam jest szybciej" nie ma żadnego pokrycia z rzeczywistością, a obydwa rozwiązania zastosowane optymalnie dadzą podobne rezultaty.

Edytowano Luty 28, 2016 przez Archi (zobacz historię edycji)

[gutek 23]

na administracji mysql to ja się znam, rozumiem blokady itp ale w przypadku blokowania tabeli mam na myśli np polecenie optimize table, wykonaj takie polecenie dla tabeli o rozmiarze np 50g lub większej.. tylko dla tego to podzieiłem, by łatwiej odzyskiwać miejsce na dysku, bo regularnie są kasowane dane w sporej ilości, indeks również gdy nie mieści się w ramie to kiepsko. mongo mnie interesowało głównie ze względu na prosty sharding, wówczas sklejam kilka serwerów z jedną kolekcją i mam najlepsze z rozwiązań w jednej tabeli, gdzie nie boli mnie ram, cpu i dysk.. w mysqlu za sharding odpowiada aplikacja która sama dzieli dane wg kryteriów co ma swoje plusy i minusy ale po wykonanych testach i pracy przez 3 lata sprawdza się dużo lepiej.

Edytowano Luty 28, 2016 przez gutek (zobacz historię edycji)

[niepozwole 20]

MongoDB na przełomie lat przeszło naprawdę sporo zmian. Pracuję z tą bazą od przeszło wersji 2.4 (lub nawet 2.2). Przyznam początki były ciężkie, sporo rzeczy nie działało albo działało inaczej niż przedstawiała to dokumentacja. Początkowo sam sharding również był drzazgą w oku, dane trzeba było podzielić praktycznie "ręcznie" wykorzystując pre splitting. Po wprowadzeniu dzielenia danych po hashu sam sharding jest praktycznie bezbolesny. Dodatkowo od wersji 3.2 nowy silnik wiredTiger staje się używalny (wcześniej było to jeszcze mocno niezgrane). Jeśli w Twoim środowisku jest zarówno sporo zapisów jak i odczytów to polecam zainwestować w dyski SSD (są bardzo pomocne przy sporej liczbie operacji zapisu). Dyski SSD do odczytów nie mają aż takiego znaczenia, ponieważ większość z Twojego aktualnego working seta i tak wyląduje w ramie. Także jeśli masz chęci i siły to polecam spróbować, nie taki diabeł straszny jak go malują.