Miliony rekordów w bazie MySQL

Jak sobie radzić z zapytaniami, gdy tabela liczy już co najmniej milion, a nawet parę rekordów?
Czy jest się wtedy skazanym na sekundowe, paru-sekundowe oczekiwanie na wykonanie zapytania?

Co jeśli po roku tych rekordów będzie z 20 milionów?

Czy w tak pojemnej tabeli przechowywać wszystkie rekordy czy może tylko ostatnie z 30 dni? A resztę trzymać w jakiejś innej?

Też mnie ciekawi jak są strony, które mają ogrom statystyk (np. ceny kryptowalut z ostatnich lat). Jak to jest zrobione, że jest tak dużo danych i to się tak szybko ładuje?

Optymalizacja zapytań, dodanie indeksów, cachowanie.

A jeśli zapytania są tak proste, że nie ma co optymalizować, indeksy są dodane do pól po których rekordy są wyszukiwane a cachowanie trochę nie pasuje, ponieważ dane co 5 minut są aktualizowane?

@2solaris5:

Ukrywasz rzeczywiste zagadnienie, czyli kręcisz.

Czy jest się wtedy skazanym na sekundowe, paru-sekundowe oczekiwanie na wykonanie zapytania?

Co jest klientem bazy danych? Soluszyn desktopowe? Wieloużytkownikowe webowe? W jakim języku ?
Mozna robić coś w modelu 'async' ale to zupełnie inna opowieść i nie ma nic wspólnego z bazami danych

Też mnie ciekawi jak są strony, które mają ogrom statystyk (np. ceny kryptowalut z ostatnich lat). Jak to jest zrobione, że jest tak dużo danych i to się tak szybko ładuje?

Rozległem archiwa historyczne (nie podlegające zmianom) prawie nigdy nie trzyma się w bazach SQL, taka zmiana kontekstu pozbawia je zalet.
Największe soluszyny na pewno się rozprasza (i współczesne NoSQLe są bardziej podatne na rozpraszanie - SQL kocha integralność)

Czy w tak pojemnej tabeli przechowywać wszystkie rekordy czy może tylko ostatnie z 30 dni? A resztę trzymać w jakiejś innej?

I mieć inne raporty dla FV z ostatnich 30 dni, inne dla starszych ? Przerażające constraintsy na klucze obce ? Brr, strach nawet pomyśleć ...
To niemal zawsze jest zła pokusa. Pozorne rozwiązanie 1go problemu, które generuje 20 innych

@2solaris5:

Właśnie zerknąłem:
11mln w tabeli , drugie miejsce 1.3 mln - to mała baza, pięknie gania na limitowanych Expressie 1.5GB RAM.

26mln / 3mln - baza najwyżej średnia, dostaje chyba 8GB RAM

Profesjonalnie zaprojektowane, indeksy, dopóki nie udupcyć kwerendą z like % nie widać specjalnych problemów.

Plus https://4programmers.net/index.php/Forum/Bazy_danych/203038-partycjonowanie_bazy_danych

Niesamowite, naprawdę. Może mi Laravel Telescope to wszystko spowalnia też trochę. Spróbuję go wyłączyć dla niektórych jobsów. Bo właśnie zauważyłem, że w ciągu 10 dni stworzyło się logów na ponad 20 GB.

Swoją drogą - czy stosujesz jakąś specjalną konfigurację mysql czy zostałeś przy domyślnej?
I ile ramu przydzielić do wykorzystania serwerowi mysql?
W ogóle ile ramu posiadać na serwerze do takich dość dużych zbiorów?

@2solaris5:

Logowanie do SQL to uroda (dość mało inteligenta, żeby nie kląć) światka PHP.
To trochę się bierze z tego, ze na bieda-hostingu jest jednym z niewielu dostępnych w czasie rzeczywistym (logi z /var/log są dostępne np po północy )

Zobaczysz temat w szerszym horyzoncie, jak pogrzebiesz w YT u ewangelizatorów dużych projektów Javy. Są naprawdę piękne rozwiązania.

Być może w PHP / Lavarelu jakieś profesjonalne silniki logowania są dostępne, ale na pewno w tym środowisku się o tym nie rozmawia

2solaris5 napisał(a):

Swoją drogą - czy stosujesz jakąś specjalną konfigurację mysql czy zostałeś przy domyślnej?
I ile ramu przydzielić do wykorzystania serwerowi mysql?

Nie czuję się pro adminem bazowym. Ale zarówno MySQL jak i MariaDb maja wiodące artykuły nt optymalizacji, powszechnie znane. Stosuję 3-4 elementy z tych artykułów.
"Jak zawiodą wszystkie środki przeczytać dokumentację" ?

RAM ... to zależy, ile klient ma na serwery itd... dawniej (=20 lat temu) się cieszyliśmy, jak RAMu było na 15% bazy, dziś modne by było całą zmieścić w RAM.

Jeżeli przy kilku milionach rekordów masz problem z czasem odpowiedzi, to coś jest zrypane - struktura, indeksy, zapytanie, statystyki serwera. Sprawdzałeś plan zapytania, czy "patrzyłem w kod i jest dobrze"? Zmieniłeś w tym co się łączy do bazy poziom izolacji na coś czego potrzebujesz, czy jedziesz na defaulcie (repeatable read)?
Jeżeli używasz bazy danych SQL tylko po to, żeby ją co 5 minut wypełnić dodatkowymi danymi i żeby każdy request pobierał sobie te ostatnie 5 minut danych (być może agregując je sobie w jakiś sposób), to używasz złego narzędzia.