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]
Odpowiedzi:
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.
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
źródło
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ć:
losowe linki - prędkość wstawek:
źródło
Zadzwoń do Percona . Nie zaliczaj „Idź”. Nie zbieraj 200 $.
źródło
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.
źródło
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
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.
źródło
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.
źródło