Duże bazy mysql

[LANcaster (kotkowicz.pl) 52]

U klienta mamy bazy po kilkaset milionów rekordów - dla przykładu jedna baza ma tabelę z 600mln rekordów, oraz kilka kolejnych po 20-60mln. Łącznie 120GB danych. Kolejna baza na tym serwerze ma dwie tabele 350/430mln rekordów (łącznie 160GB) oraz kilka mniejszych po 60-120mln. Wszystkie bazy zajmują 954GB i wciąż rosną.

 

Całość działa całkiem sprawnie na Percona MySQL. Alternatywnie testujemy Apache Hadoop, jakikolwiek NoSQL odpada.

[Gość Kamikadze]

Projekt bazy już mam zobaczymy jak to będzie śmigać

[Misiek08 285]

U klienta mamy bazy po kilkaset milionów rekordów - dla przykładu jedna baza ma tabelę z 600mln rekordów, oraz kilka kolejnych po 20-60mln. Łącznie 120GB danych. Kolejna baza na tym serwerze ma dwie tabele 350/430mln rekordów (łącznie 160GB) oraz kilka mniejszych po 60-120mln. Wszystkie bazy zajmują 954GB i wciąż rosną.

 

Całość działa całkiem sprawnie na Percona MySQL. Alternatywnie testujemy Apache Hadoop, jakikolwiek NoSQL odpada.

Testowaliście może TokuDB?

[LANcaster (kotkowicz.pl) 52]

Testowaliście może TokuDB?

TokuDB zapowiadało się fajnie - niestety z uwagi na regularne robienie Hot Backupów, musielibyśmy wziąć Enterprise Edition, co przy 12 serwerach bazodanowych kosztowałoby 30k USD rocznie. :-(

[Gość AceDude]

@micrus - nie, działają, ale uruchamiane z konsoli trwają po parę godzin. Prosty DELETE trwający całą noc naprawdę mnie boli. No ale cóż, jak będę miał czas się tym zająć, "pochwalę się" szczegółami tutaj na forum.

 

@LANcaster - imponujące.

[behemoth 230]

W poprzedniej firmie używaliśmy Postgresa przy bazach, które miały ponad 2TB z powodzeniem

[Mackos 0]

Hej a ja jeszcze się podepnę pod temat bo mam niemal identyczne pytanie.
Kwestia jest tego typu że archiwizuje sobie logi z sieci reklamowej (kliknięcia, wyświetlenia itd) w MySQL z silnikiem Archive.
Ale jednak trochę mi to wadzi i zastanawiam się czy nie podpiąć do tego zadania MongoDb.
Obecna MySQL ma ok 15 kolumn typ int, bigint i varchar...
Jak myślicie - zamiana będzie wydajniejszym rozwiązaniem? Później na podstawie tych danych są opracowywane raporty.

[Gość patrys]

Jak myślicie - zamiana będzie wydajniejszym rozwiązaniem?

 

będzie.

[Mackos 0]

A wielkościowo te pliki z MongoDb są mniejsze niż z Archive ? Przy załóżmy 1mln rekordów?

I pytanie nr2, czemu Apache Hadoop miałoby być armatą na wróble - jeśli spodziewam się większego ruchu to nie lepiej od razu coś takiego zamontować?

Edytowano Marzec 4, 2014 przez Mackos (zobacz historię edycji)

[Misiek08 285]

Jeżeli ogarniesz Hadoopa to czemu nie. Z tego co widziałem to instalacje używają Hadoopa kiedy przypływ danych jest konkretny, liczony nawet w GB/s. Mając 1mln rekordów nawet jeśli każdy to 1M to masz ledwo 1000GB danych, a skoro od jakiegoś czasu się zastanawiasz to znaczy, że idzie to powoli. Spróbuj Mongo.

[Mackos 0]

Ok Misiek08 dzięki za ugryzienie tematu. Czyli Hadoop jest bardziej skomplikowany w obsłudze niż standardowy apache?
Nie będzie później większych problemów z migracją z apache2 na Hadoop?

[maniack 403]

.

Edytowano Wrzesień 13, 2017 przez maniack (zobacz historię edycji)

[elcct 159]

Jeżeli przewidujesz, że projekt będzie obsługiwać dużą ilość danych, najlepiej przygotować go na tę okoliczność od razu - zaoszczędzi to czasu i problemów (brak konieczności migracji, możliwość wcześniejszego wykrycia potencjalnych błędów)

 

Jeśli chodzi o mongo, to zależy wszystko jakie to są dane i jak planujesz je przetwarzać. Weź pod uwagę, że mongo np. blokuje całą bazę danych przy niektórych operacjach np. map-reduce, a to znaczy, że na czas wykonania operacji jest brak dostępu do danych.

 

Mongo nadaje się głównie do małych i prostych baz danych, gdzie operacje na danych będą trwały krótko.

[Mackos 0]

Jeśli chodzi o mongo, to zależy wszystko jakie to są dane i jak planujesz je przetwarzać. Weź pod uwagę, że mongo np. blokuje całą bazę danych przy niektórych operacjach np. map-reduce, a to znaczy, że na czas wykonania operacji jest brak dostępu do danych.

 

Mongo nadaje się głównie do małych i prostych baz danych, gdzie operacje na danych będą trwały krótko.

Okej, a INSERT ok. 1-5/sekunde to proste czy nie?

Do tego SELECTY mniej więcej w tej samej ilości dla jednej tabeli, selecty które są potrzebne do generowania raportów.

To zostać przy MySQL w takim wypadku?

[xorg 693]

 

Okej, a INSERT ok. 1-5/sekunde to proste czy nie?

Czas wykonywania zapytania zalezny jest od sprzetu, konfiguracji, konstrukcji bazy, wiec to wrozenie z fusow

Edytowano Marzec 5, 2014 przez xorg (zobacz historię edycji)

[Mackos 0]

ajć sorki trochę źle to napisałem.
Średnio request wywołujący insert do bazy, będzie wywoływany co 1 sekunde (przy pesymistycznych założeniach). Oczywiście memcache i inne też będą działały w międzyczasie.

Po prostu się zastanawiam co będzie lepszym rozwiązaniem, jak narazie jest MySQL i daje radę - ale nie wiem czy nie da się tego ulepszyć (Archive jest trochę uciążliwe, a InnoDB no cóż sporo miejsca zajmuje ).

[elcct 159]

Średnio request wywołujący insert do bazy, będzie wywoływany co 1 sekunde (przy pesymistycznych założeniach).

 

Co zrobisz jak mongo będzie wykonywać jakąś długą operację (np. trwającą 5 sekund) i przez ten czas nic nie wrzucisz do bazy, bo będzie zablokowana?

 

Jeżeli będziesz próbował dalej wrzucać to jedno czy więcej zapytań na sekundę, to kolejka zapytań się będzie zapychać i baza w końcu padnie (czy też po prostu nie będzie odpowiadać)

[Mackos 0]

elcct, jakie rozwiązanie byś dla moich potrzeb zaproponował?

[Misiek08 285]

@elcct - tylko pamiętaj o tym, że lock'i z Mongo to nie takie zwykłe lock'i. Taki write-lock jest zdejmowany po np. 300-1000 mikrosekundach, więc dopóki nie ma więcej niż 500-700req/s (zostawiamy margines 300) to wg teorii nic się nie zamuli.

[elcct 159]

@elcct - tylko pamiętaj o tym, że lock'i z Mongo to nie takie zwykłe lock'i. Taki write-lock jest zdejmowany po np. 300-1000 mikrosekundach, więc dopóki nie ma więcej niż 500-700req/s (zostawiamy margines 300) to wg teorii nic się nie zamuli.

 

W dokumentacji nic takiego nie widziałem - "lock" jest tak długo aż zostanie wykonana operacja zapisu. Spotkałem się z tym, że przy bazie tylko z kilkunastoma milionami dokumentów jeden insert/upsert trwał nawet kilka minut (mocny serwer, tylko z mongo)

elcct, jakie rozwiązanie byś dla moich potrzeb zaproponował?

 

Wszystko zależy od tego jakie konkretnie masz dane i co chcesz z nimi robić.

Edytowano Marzec 5, 2014 przez elcct (zobacz historię edycji)

[Mackos 0]

Elcct napisałem nieco wcześniej to ma być odpowiednik obecnej bazy MySQL:

Obecna MySQL ma ok 15 kolumn typ int, bigint i varchar...

 

Czyli mamy spór w pełni nierozwiązany

No i pytanie - w Mongo write-locki są na całą tabelę czy na rekord?

Edytowano Marzec 6, 2014 przez Mackos (zobacz historię edycji)

[elcct 159]

Elcct napisałem nieco wcześniej to ma być odpowiednik obecnej bazy MySQL:

 

Czyli mamy spór w pełni nierozwiązany

 

No i pytanie - w Mongo write-locki są na całą tabelę czy na rekord?

 

Mongo służy przede wszystkim do przechowywania dokumentów gdzie jeden dokument może zawierać "pod-dokumenty" np. dokument zawierający artykuł, może również zawierać komentarze, zdjęcia itd gdzie ich struktura nie musi być z góry narzucona. I w tym mongo stanowi przewagę nad tradycyjną relacyjną bazą danych, bo do wybrania tych wszystkich danych dot. artykułu wystarczy jedno proste zapytanie, a w przypadku MySQL, zwykle oznaczałoby to kilka - kilkanaście zapytań, aby wybrać takie same dane.

 

Jeżeli posiadasz prostą tabelę, która nie ma relacji MySQL powinien lepiej dać radę.

 

Mongo blokuje całą bazę danych - blokowanie tabeli ciągle jest w planach (od 4 lat...).