Skocz do zawartości
Gość Kamikadze

Duże bazy mysql

Polecane posty

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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. :-(

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość patrys
Jak myślicie - zamiana będzie wydajniejszym rozwiązaniem?

 

będzie.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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 przez Mackos (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

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 przez xorg (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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 :unsure: ).

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Ś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ć)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

@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 przez elcct (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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 :P

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

Edytowano przez Mackos (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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

 

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

 

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto

Zarejestruj nowe konto, to proste!

Zarejestruj nowe konto

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się


×