Operuję na bazie MySQL z kilkoma pięknymi tabelkami. Problem polega na tym, że tabelki te mają po wiele milionów rekordów i co najlepsze - są ze sobą w relacji. Żeby wyobrazić sobie problem, załóżmy, że mamy 5 milionów użytkowników forum i każdy z nich napisał po 50 wątków, a w każdym wątku jest po 100 postów (nie, nie chodzi tu "naszą klasę" he he he). W dodatku forum to cały czas się rozwija i rozdyma bazę.
Pierwszy pomysł na jaki wpadłem, to podzielenie takiej wielkiej tabeli na mniejsze, powiedzmy po 500tys rekordów. Łatwo byłoby to zrobić licząc po ID (modulo 500tys), jednak przeszukiwanie (i poniekąd joinowanie) z reguły nie jest po ID tylko po innym indeksie niezależnym ani od ID ani od czasu... Jednak ze względu iż baza wciąż się rozwija, nie da się na sztywno podzielić tej tabeli zgodnie z indeksem po którym szukamy..
Doszedłem więc do miejsca w którym optymalne byłoby stworzenie wielu tabel podzielonych po 500tys rekordów zgodnie z ID, i dołożenie nowej tabeli - indeksu, który zawierałby id_rekordu oraz nazwe_tabeli w której się znajduje. Jednak z założenia indeks ten miałby również kilka/kilkanaście milionów rekordów...
Być może któryś z szacownych użytkowników forum.php.pl spotkał się z podobnym problemem i zaoszczędzi mi czasu na szukaniu optymalnego rozwiązania?
Pomysły na jakie wpadłem są następujące:
- podział wielkiej tabeli na mniejsze, dołożenie wielkiego tabelo-indeksu, przy czym joinowanie tabel musiałoby najpierw przejść przez filtr i wyszukanie odpowiednich tabel w tabelo-indeksie,
- podział wielkiej tabeli na mniejsze poprzez podział zgodnie z parametrem czasu (na przykład jedna tabela-jeden miesiąc), przy założeniu, że zakres czasu jaki obejmowałby tą tabelę pokrywałby się mniej więcej z czasem w jakim z reguły wyszukują informacje użytkownicy (na przykład, użytkownicy wyszukują informacje z ostatnich 3 miesięcy, więc tabelki będą 3-miesięczne + ostatnia 3-6 miesięcy - jak się przepełni nastąpi podział automatem, etc.),
- podział wielkiej tabeli na mniejsze poprzez stałe założenie ilości tych mniejszych tabelek i upychanie danych poprzez swego rodzaju hashowanie tego indeksu po którym wyszukuję (co jeśli baza mi urośnie tak, że trzeba będzie dalej dzielić?)
- typowo algorytmiczne rozwiązanie - organizacja tabel w b-drzewo, stos albo inną strukturę...
Może jakieś inne rozwiązanie?
Edit po 11 dniach: Widzę, że nikt nie miał nigdy takiego problemu a mi baza puchnie!
Postaram się dzisiaj rozwiązać ten problem i przekażę wyniki moich eksperymentów