Obsługa bardzo dużych danych za pomocą mysql

Czy MySQL może rozsądnie wykonywać zapytania na miliardach wierszy? -- MySQL może "obsługiwać" miliardy wierszy. „Rozsądnie” zależy od zapytań; zobaczmy je.

Czy InnoDB (MySQL 5.5.8) jest właściwym wyborem dla wielomiliardowych wierszy? -- 5.7 ma kilka ulepszeń, ale 5.5 jest całkiem niezły, mimo że jest prawie 6 8 lat i u progu nie jest już wspierany.

Najlepszy magazyn danych dla miliardów wierszy — jeśli masz na myśli „silnik”, to InnoDB.

Jak duża może być baza danych MySQL, zanim wydajność zacznie spadać — znowu, to zależy od zapytań. Mogę pokazać ci stół rzędu 1K, który się stopi; Pracowałem z tabelami z miliardami wierszy, które nucą.

Dlaczego MySQL może działać wolno z dużymi tabelami? -- skanowanie zakresu prowadzi do wejścia/wyjścia, co jest wolną częścią.

Czy Mysql może obsłużyć tabele, które pomieszczą około 300 milionów rekordów? -- znowu tak. Limit wynosi około biliona wierszy.

(dla tabel InnoDB, co jest w moim przypadku) zwiększenie innodb_buffer_pool_size (np. do 80% pamięci RAM). Znalazłem również inne ustawienia dostrajania wydajności MySQL tutaj na blogu Percona -- tak

posiadanie odpowiednich indeksów w tabeli (używanie EXPLAIN w zapytaniach) -- cóż, zobaczmy je. Jest wiele błędów, które można popełnić w tym krytycznym obszar.

partycjonowanie tabeli -- "Partycjonowanie nie jest panaceum!" Nawiązuję do tego w moim blogu

Fragmentacja MySQL — obecnie jest to DIY

Klastrowanie MySQL — obecnie najlepszą odpowiedzią jest jakaś opcja oparta na Galera (PXC, MariaDB 10, DIY w/Oracle). „Replikacja grupowa” firmy Oracle jest realnym konkurentem.

Partycjonowanie nie obsługuje FOREIGN KEY lub „globalny” UNIQUE .

UUID w skali, o której mówisz, nie tylko spowalniają system, ale wręcz go zabijają. UID typu 1 może być obejściem.

Szybkość wstawiania i budowania indeksu — istnieje zbyt wiele odmian, aby można było udzielić jednej odpowiedzi. Zobaczmy Twój wstępny CREATE TABLE i w jaki sposób zamierzasz wprowadzić dane.

Wiele złączeń — „Normalizuj, ale nie przesadzaj”. W szczególności nie normalizuj dat i godzin, wartości zmiennoprzecinkowych ani innych „ciągłych” wartości.

Twórz tabele podsumowań

2,3 miliona transakcji dziennie — jeśli to 2,3 miliona wstawek (30/s), wtedy nie ma większego problemu z wydajnością. Jeśli jest to bardziej złożone, może być konieczne RAID, SSD, przetwarzanie wsadowe itp.

radzić sobie z taką ilością danych — jeśli większość aktywności dotyczy „ostatnich” wierszy, wtedy pula_buforów dobrze „buforuje” aktywność, unikając w ten sposób operacji we/wy. Jeśli aktywność jest „losowa”, to MySQL (lub każdy w przeciwnym razie) będą miały problemy z wejściem/wyjściem.

Zmniejszenie typów danych pomaga w tabeli takiej jak twoja. Wątpię, czy potrzebujesz 4 bajtów do określenia fuel_type . Istnieje wiele podejść 1-bajtowych.