Mysql: Praca z 192 bilionami rekordów… (Tak, 192 biliony)

39

Oto pytanie ...

Biorąc pod uwagę 192 biliony rekordów, jakie powinny być moje rozważania?

Moją główną troską jest szybkość.

Oto tabela ...

    CREATE TABLE `ref` (
  `id` INTEGER(13) AUTO_INCREMENT DEFAULT NOT NULL,
  `rel_id` INTEGER(13) NOT NULL,
  `p1` INTEGER(13) NOT NULL,
  `p2` INTEGER(13) DEFAULT NULL,
  `p3` INTEGER(13) DEFAULT NULL,
  `s` INTEGER(13) NOT NULL,
  `p4` INTEGER(13) DEFAULT NULL,
  `p5` INTEGER(13) DEFAULT NULL,
  `p6` INTEGER(13) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY (`s`),
  KEY (`rel_id`),
  KEY (`p3`),
  KEY (`p4`)
    );

Oto pytania ...

SELECT id, s FROM ref WHERE red_id="$rel_id" AND p3="$p3" AND p4="$p4"

SELECT rel_id, p1, p2, p3, p4, p5, p6 FROM ref WHERE id="$id"

INSERT INTO rel (rel_id, p1, p2, p3, s, p4, p5, p6)
VALUES ("$rel_id", "$p1", "$p2", "$p3", "$s", "$p4", "$p5", "$p6")

Oto kilka notatek ...

  • WYBÓR będzie wykonywany znacznie częściej niż WSTAW. Czasami jednak chcę dodać kilkaset rekordów na raz.
  • Pod względem obciążenia nie będzie nic przez wiele godzin, a może kilka tysięcy zapytań naraz.
  • Nie sądzę, że mogę już normalizować (potrzebuję wartości p w kombinacji)
  • Baza danych jako całość jest bardzo relacyjna.
  • To będzie jak dotąd największy stół (następny największy to około 900 tys.)

AKTUALIZACJA (08.11.2010)

Co ciekawe, dostałem drugą opcję ...

Zamiast 192 trylionów mógłbym zapisać 2,6 * 10 ^ 16 (15 zer, co oznacza 26 biliardów) ...

Ale w tej drugiej opcji musiałbym przechowywać tylko jeden bigint (18) jako indeks w tabeli. To wszystko - tylko jedna kolumna. Chciałbym więc po prostu sprawdzić, czy istnieje wartość. Czasami dodając rekordy, nigdy ich nie usuwając.

Dlatego myślę, że musi istnieć lepsze rozwiązanie niż mysql do przechowywania liczb ...

Biorąc pod uwagę tę drugą opcję, powinienem ją wziąć lub trzymać się pierwszej ...

[edytuj] Właśnie otrzymałem wiadomość o przeprowadzonych testach - 100 milionów wierszy z tą konfiguracją zwraca zapytanie w 0,0004 sekundy [/ edit]

Sarah
źródło
7
W jakim stopniu używasz do tego MySQL? Czy możesz być przekonany do przejścia na inną dbms, jeśli ktoś poda solidne argumenty?
WheresAlice
3
Bilion jak w 10 ^ 12 czy jak w 10 ^ 18?
andol
15
Przy 192 bilionach rekordów powinieneś mieć budżet, który pozwala zadawać pytania osobom odpowiedzialnym za MySQL, a nie niektórym forom dyskusyjnym.
Remus Rusanu,
5
Z bazą danych o tak dużym (i oczywiście przyzwoitym budżecie), dlaczego nie skorzystać z rozwiązania Oracle i SQL Server, które zostało sprawdzone z łatwością obsługi dużych baz danych?
Jim B,
5
Pamiętaj, aby informować nas o tym podczas wdrażania. Z pewnością byłbym zainteresowany. Możesz także napisać to na highscalability.com
Tom O'Connor,

Odpowiedzi:

30

Oszacowanie pQd na 7PB wydaje się rozsądne, a to dużo danych dla RDBMS. Nie jestem pewien, czy kiedykolwiek słyszałem o kimś, kto robi 7PB z jakimkolwiek współdzielonym systemem dyskowym, nie mówiąc już o MySQL. Zapytanie o ten wolumen danych z dowolnym systemem dysku współdzielonego będzie niezwykle wolne. Najszybszy sprzęt SAN osiąga maksymalną prędkość 20 GB / s, nawet w przypadku dużych zapytań przesyłanych strumieniowo. Jeśli możesz sobie pozwolić na sprzęt SAN tej specyfikacji, możesz zmusić się do użycia czegoś bardziej odpowiedniego do pracy niż MySQL.

W rzeczywistości staram się wymyślić scenariusz, w którym możesz mieć budżet na podsystem dyskowy o tej specyfikacji, ale nie na lepszą platformę DBMS. Nawet przy użyciu dysków o pojemności 600 GB (największego obecnie na rynku 15-litrowego dysku dla przedsiębiorstw) masz do dyspozycji około 12 000 fizycznych dysków do przechowywania 7PB. Dyski SATA byłyby tańsze (a przy dyskach 2 TB potrzebujesz około 1/3 liczby), ale nieco wolniej.

SAN tej specyfikacji od dużego dostawcy, takiego jak EMC lub Hitachi, kosztowałby wiele milionów dolarów. Ostatnim razem, gdy pracowałem ze sprzętem SAN od jednego z głównych dostawców, koszt transferu miejsca na IBM DS8000 wynosił ponad 10 000 £ / TB, bez uwzględnienia ulgi inwestycyjnej dla kontrolerów.

Naprawdę potrzebujesz współużytkowanego systemu niczym, takiego jak Teradata lub Netezza, do tak dużej ilości danych. Odłamki w bazie danych MySQL mogą działać, ale polecam specjalnie zbudowaną platformę VLDB. Współużytkowany system niczego pozwala również na użycie znacznie tańszego dysku z bezpośrednim dołączaniem do węzłów - spójrz na platformę Sun X4550 (thumper), aby zobaczyć jedną możliwość.

Musisz także pomyśleć o swoich wymaganiach dotyczących wydajności.

  • Jaki jest dopuszczalny czas wykonywania zapytania?
  • Jak często będziesz sprawdzać swój zestaw danych?
  • Czy większość zapytań można rozwiązać za pomocą indeksu (tj. Czy będą patrzeć na niewielki ułamek - powiedzmy: mniej niż 1% - danych), czy też muszą wykonać pełne skanowanie tabeli?
  • Jak szybko dane będą ładowane do bazy danych?
  • Czy Twoje zapytania wymagają aktualnych danych, czy może żyjesz z okresowo odświeżaną tabelą raportów?

Krótko mówiąc, najsilniejszym argumentem przeciwko MySQL jest to, że robisz backflipy, aby uzyskać przyzwoitą wydajność zapytań w stosunku do 7PB danych, jeśli jest to w ogóle możliwe. Ta ilość danych naprawdę umieszcza cię na terytorium „nic wspólnego”, aby stworzyć coś, co pozwoli na dość szybkie zapytanie, i prawdopodobnie będziesz potrzebować platformy, która od samego początku została zaprojektowana do działania typu „nic wspólnego”. Same dyski będą przewyższać koszty każdej rozsądnej platformy DBMS.

Uwaga: Jeśli podzielisz operacyjne i baz danych raportowanie, niekoniecznie musisz używać tej samej platformy DBMS dla obu. Zdobycie szybkich wstawek i raportów poniżej drugiej sekundy z tej samej tabeli 7PB będzie co najmniej technicznym wyzwaniem.

Biorąc pod uwagę twoje komentarze, że możesz żyć z pewnym opóźnieniem w raportowaniu, możesz rozważyć oddzielne systemy przechwytywania i raportowania i może nie być konieczne przechowywanie wszystkich 7PB danych w operacyjnym systemie przechwytywania. Rozważ platformę operacyjną, taką jak Oracle (MySQL może to zrobić z InnoDB) do przechwytywania danych (ponownie, koszt samych dysków przewyższy koszt DBMS, chyba że masz wielu użytkowników) oraz platformę VLDB, taką jak Teradata, Sybase IQ, RedBrick, Netezza (uwaga: zastrzeżony sprzęt) lub Greenplum do raportowania

ConcernedOfTunbridgeWells
źródło
1
@ConcernedOfTunbridgeW - zawsze mogą iść w ten sposób: blog.backblaze.com/2009/09/01/... - dużo więcej zabawy niż SAN, potrzeba tylko ~ 120-130 4U skrzynek ... ale nie jestem pewien, czy biznes ”byłby szczęśliwy ....
pQd
Zasadniczo Sun Thumper przy ograniczonym budżecie i tak naprawdę przykład opcji dla węzła w systemie współdzielonego braku danych. Jestem pewien, że widziałem też inne opcje, ale nie wiem, gdzie. Pytanie nie dotyczy raczej tego, jaki sprzęt, ale jaką platformę bazy danych.
ConcernedOfTunbridgeWells
Jednak zapaleni obserwatorzy zauważą, że każdy rodzaj skrzynki opartej na bezpośrednim dołączaniu jest o wiele, znacznie tańszy na TB niż cokolwiek opartego na sieci SAN, co jest co najmniej jednym znaczącym argumentem na korzyść czegoś zaprojektowanego do pracy na platformie „nic wspólnego” .
ConcernedOfTunbridgeWells
@ConcernedOfTunbridgeWells i możesz uruchamiać wszystkie te zapytania / konserwację i cokolwiek innego równolegle na wielu [poza tym wymagających zasilania] urządzeniach.
pQd
1
@ConcernedOfTunbridgeWells - aby odpowiedzieć na pytania ... Potrzebuję około 500 zapytań, aby wrócić w ciągu sekundy, jeśli to możliwe. Będę to robił tylko kilkaset razy dziennie. Gdy zapytanie jest uruchomione, pełna tabela musi zostać przeskanowana. Również INSERT mają niższy priorytet niż SELECT, więc nie musi być nigdzie w pobliżu. Mogę poczekać kilka godzin, aż „nowe” dane wejdą do bazy danych.
Sarah,
16

odłamek tego. w tym rozmiarze posiadanie jednej dużej instancji jest samobójstwem - pomyśl o możliwych przywracaniu kopii zapasowych, uszkodzeniach przestrzeni tabel, dodawaniu nowych kolumn lub innych procesach „utrzymania domu” - wszystko to jest niemożliwe do wykonania w rozsądnym czasie na taką skalę.

proste obliczenia z tyłu obwiedni - przy założeniu 32-bitowych liczb całkowitych dla wszystkich kolumn z wyjątkiem 64-bitowego identyfikatora; brak uwzględnionych wskaźników:

8 * 4B + 8B = 40B na wiersz [i to jest bardzo optymistyczne]

192 tryliony rzędów 40B daje prawie 7 PB

może uda ci się przemyśleć całość, podsumować informacje w celu szybkiego raportowania i przechowywać skompresowane rekordy dla określonych przedziałów czasowych, gdy ktoś będzie musiał zagłębić się w głębsze szczegóły.

pytania, na które należy odpowiedzieć:

  • jaki jest dopuszczalny czas przestoju w przypadku awarii / ponownego uruchomienia systemu?
  • jakie są dostępne przestoje, gdy trzeba odzyskać kopię zapasową lub wycofać serwer z produkcji w celu zaplanowanej konserwacji.
  • jak często i gdzie chcesz wykonać kopię zapasową?

losowe linki - prędkość wstawek:

pQd
źródło
Zgadzam się - 7PB jest dość ciężki. Chciałbym to przemyśleć i znaleźć lżejsze rozwiązanie, ale muszę znaleźć istnienie (lub nieistnienie) konkretnej kombinacji pól p. Podział stołów przyszedł mi do głowy - jest to bardziej sensowne, ale oznacza to po prostu, że mam zapytanie dla każdej tabeli po kolei. Z braku zainteresowania, ile stolików poleciłbyś tutaj podzielić?
Sarah,
5
@ Sarah - poleciłbym nie tylko dzielenie na tabele, ale także maszyny. możesz uruchamiać swoje zapytania równolegle, aby zwiększyć wydajność [robię to na mniejszą skalę]. co z uszkodzeniami systemu plików, a nawet rutynową kontrolą po ponownym uruchomieniu serwera? nie jestem pewien, co masz na myśli przez znalezienie konkretnej kombinacji ... może prosty sklep z kluczowymi wartościami pomógłby? rozmiar stołu - nie więcej niż kilkadziesiąt GB; dane na jednym serwerze - nie więcej niż kilka TB. spójrz na stackoverflow.com/questions/654594, aby dowiedzieć się, jakiego bólu głowy można się spodziewać na znacznie mniejszą skalę; użyj innodb_file_per_table
pQd
8

Zadzwoń do Percona . Nie zaliczaj „Idź”. Nie zbieraj 200 $.

JustinShoffstall
źródło
2

Może istnieć inny sposób, niż przechowywanie biliardów liczb, jeśli wszystko, co chcesz zrobić, to sprawdzić, czy są one w zestawie. Filtry Blooma są metodą probabilistyczną, mieszającą na wiele sposobów. Możliwe są również fałszywie pozytywne wyniki, ale fałszywe negatywne nie są. (Może to oznaczać, że liczba jest w zestawie - i być w błędzie, ale nie powie, że jej nie ma, jeśli tak naprawdę była). Wciąż istnieje również problem dużej liczby przedmiotów do przechowywania, ale przynajmniej może to nieco zmniejszyć rozmiar działającego zestawu danych.

Alister Bulman
źródło
Brzmi interesująco, chociaż mógłbym żyć z fałszywymi negatywami - ale nie z fałszywymi pozytywami :)
Sarah
2

Edycja: Właściwie jeśli jest to po prostu istnienie „rekordu” w lokalizacji X w zakresie liczb całkowitych, możesz wyeliminować magazyn danych i po prostu użyć mapy bitowej ... Tak więc, 10 lub więcej komputerów z 100 TB miejsca na dysku (więc masz 10 kopii bitmapy dla wydajności i tworzenia kopii zapasowych), a jeśli zrobiłeś 128 GB pamięci RAM na serwer, możesz zmieścić w pamięci indeks grup bloków najwyższego poziomu o wysokiej rozdzielczości, aby wykonać pierwszą kontrolę przed uderzeniem w dysk o bit X 26 Biliardów .

Wybrałbym opcję nr 2 Jeśli weźmiesz:

375 maszyn z 64 TB (32 dyski 2 TB) każda (realistycznie 400 maszyn na awarie), a następnie wystarczy zmapować rekordy na ZVOL o wielkości 2 TB każda. Następnie na jednym lub kilku serwerach indeksu przechowuj w tablicy Judy lub tablicy kryteriów lub po prostu zwykłej bitmapie, odwzorowując, czy dodałeś rekord do tej 1 z 26 Quadrillion lokalizacji. Indeks wynosiłby od 50 do 100 TB, a nawet indeks drugiego poziomu wskazywałby na indeksy, gdyby jakieś rekordy zapisywane były do ​​określonego 64k bloku adresów, który mieściłby się w mniej niż 64 GB pamięci RAM i zapewniałby szybki poziom wstępnej kontroli jeśli pewne „sąsiedztwo” było puste, czy nie.

Następnie, aby przeczytać ten rekord, najpierw sprawdź, czy istnieje rekord do znalezienia, patrząc na indeks. Jeśli tak, przejdź do maszyny # (X) / ZOL # (Y) na tym komputerze / lokalizacji zapisu # (Z) w obrębie tego obiektu blob o wielkości 2 TB w oparciu o proste obliczenie indeksu. Wyszukiwanie pojedynczych rekordów byłoby niezwykle szybkie i można przetestować ładowanie niektórych części magazynu danych do różnych plików db (podczas korzystania z magazynu danych do prawdziwej pracy) i przeprowadzanie testów wydajności, aby sprawdzić, czy są one w stanie obsłużyć całą bazę danych - czy nie, po prostu użyj w ten sposób magazynu danych.

ZOL jest rzeczą ZFS, którą można by pomyśleć o rzadkim pliku w innych systemach plików, więc miałyby zastosowanie podobne rzeczy. Lub możesz po prostu indeksować do określonej liczby bajtów na dysku, ale staje się to trudne, jeśli dyski mają różne rozmiary, jeśli nie ograniczysz liczby bajtów używanych na dysk na poziomie, który działa na wszystkich dyskach - tj. 1,75 TB na dysk 2 TB . Lub utwórz meta-urządzenia o stałym rozmiarze itp.


źródło
Cześć Sarah - nie jestem pewien, czy nadal nad tym pracujesz, ale jeśli potrzebujesz pomocy, mógłbym prototypować swój pomysł dla ciebie na maszynie o pojemności 100 TB i byłbym również chętny do hostowania (w dużym centrum danych w USA) i zarządzania całym klastrem produkcyjnym 400-500 maszyn zgodnie z wymaganiami. BTW, czy kiedykolwiek pracowałeś w CNET w SF?
1

Oprócz dostrajania parametrów DB, takich jak szalony (użyj mysqltuner, aby pomóc), aby zachować SELECT w pamięci podręcznej tak bardzo, jak to tylko możliwe, jedną rzeczą, którą możesz zbadać, jest START TRANSACTION / CoMMIT (zakładając InnoDB) podczas wstawiania kilkuset rekordów, aby uniknąć blokując rząd po rzędzie i znacznie zmniejszając czas wstawiania. Chciałbym również utworzyć tabelę zarówno jako MyISAM, jak i InnoDB i uruchomić na niej testy, aby zobaczyć, która jest naprawdę szybsza po ściślejszym buforowaniu - nie zawsze MyISAM będzie szybszy do odczytu - sprawdź to:

http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/

Podczas testowania liczba współbieżnych wątków również powinna być zmieniana w górę iw dół, dopóki nie znajdziesz optymalnej ilości pamięci RAM na serwerze, którą można przeznaczyć na dostrajanie pamięci podręcznych; może się okazać, że chociaż matematyka może obsługiwać więcej wątków, sama baza danych może faktycznie działać gorzej, jeśli liczba wątków wzrośnie zbyt wysoko.

Ponadto, jeśli używasz MyISAM i / lub pliku InnoDB na tabelę, możesz zbadać utworzenie innego punktu montowania systemu plików dla / var / lib / mysql, który został dostosowany do mniejszego rozmiaru bloku i dostroił parametry typu fs - tj. Ext3 / ext4 / resiserfs można użyć data = zwrot zapisu dla dziennika i wyłączyć aktualizację czasów dostępu w systemie plików dla prędkości I / O.

troyengel
źródło
1
myisam wydaje się być wykluczony ze względu na wymagania transakcyjne.
pQd,
0

W przypadku drugiej opcji, ile liczb faktycznie można umieścić?

Jeśli będzie tylko jeden na tysiąc lub 10 000, 100 000 itd., To przechowywanie zakresów używanych (lub nieużywanych) numerów może zaoszczędzić biliony wpisów. np .: przechowywanie („wolny”, 0,100000), („wzięty”, 100000,100003), („wolny”, 100004,584234) - dzielenie wierszy na dwa lub trzy rzędy zgodnie z wymaganiami i indeksowanie pierwszego numeru, wyszukiwanie x <= {igła}, aby sprawdzić, czy zakres zawierający szukany numer jest zajęty, czy wolny.

Możesz nie potrzebować nawet obu statusów. Po prostu zapisz, który status jest najmniej prawdopodobny.

Alister Bulman
źródło