Znaleźć sposób na dużą bazę

Witam,

Mam pewien problem z którym borykam się już dłuższy czas. Otóż próbuję zaprojektować dość dużą bazę danych, która w sumie posiada mniej więcej 15 milionów rekordów we wszystkich tabelach.

Jest to baza z ofertami turystycznymi, gdzie oprócz nazwy oferty, kraju, regionu, miasta i nazwy hotelu są dostępne terminy i ich ceny z różnymi dodatkowymi informacjami. Z tymi właśnie danymi jest problem ponieważ tych terminów jest bardzo dużo (~ 7 mln rekordów), a poza tym trzeba po nich przeszukiwać.

Największym problemem są duplikaty, dlatego że potrzebuję wyświetlić jeden termin dla jednej oferty, gdzie używając DISTINCTA lub GROUP BY jest bardzo czasochłonne.
Wszelkie podjęte działania w celu optymalizacji zapytań są nieskuteczne, nie pomagają nawet indeksy.
Podzapytania są również bardzo wolne. Wszelkie próby zwiększenia pamięci dla mySQL'a też nie przynoszą dużych przyśpieszeń.

Nieskuteczne stają się metody grupowania (Loose index scan, Tight index scan), które owszem są szybkie, ale ograniczają się do pobrania danych z kolumn, które później są grupowane wg. indeksów, a ja muszę pobrać dużo więcej kolumn w zapytaniu lub nawet łączyć niektóre kolumny z innych tabel.

Zastanawiam się czy to nie zbyt duża baza na jeden serwer, który też nie jest pierwszej młodości czy może mySql nie nadaje się do takich baz.

Gdybym mógł pobrać lub złączyć jakoś dane z tabel oferty i terminy wg. przeszukiwania po terminach wg. kilku kryteriów i wyeliminować duplikaty nie używając GROUP BY czy DISTINCT.

Uproszczona struktura tych 2 tabel to:

[tabela OFERTY]

• id
• nazwa
• kod hotelu
• kraj
• region
• miasto

[tabela TERMINY]

• id
• data_wyjazdu
• ilosc_dni
• cena
• kod_hotelu [relacja]
• wyzywienie

Macie może jakieś pomysły jak to zoptymalizować?

15 milionow rekordow, to powiedzialbym baza nieduzej wielkosci. Obstawiam, ze albo zapytania, ktorymi wyswielasz sa nieoptymalne, albo struktura.

Napisz wiecej, jak wygladaja u ciebie indeksy i normalizacja bazy. Na ogol problem z distinct maja osoby, ktore nie posiadaja znormalizowanej postaci. Na przyklad kraj, miasto, byc moze rejon, sa zle skonstruowane: wystarczy miasto_id [relacja], bo jednoznacznie bedzie oznaczalo tak kraj, jak i region. To zmniejsza rozmiar tabeli, zmniejsza bledy, ale moze tez eliminowac potrzebe distinct (bo w tabeli miast bedzie tylko jeden taki wpis).

Wez tez pod uwage, ze sam MySQL nie jest najszybsza z baz, choc z taka liczba wpisow powinien radzic sobie przyzwoicie.

Zapomnij o mySQLu. Masz go zapewne na serwerze współdzielonym więc nie ma szans na klaster. Rozejrzyj się lepiej za Postgresem 8.3.

Swoją droga problemem nie jest to 15mln, ale to 7mln w jednej tabeli nie da się tego jakość pociąć? Idę o zakład, że nie musisz trzymać wszystkich dat. Wystarczy trzymać datę startu i czas trwania. Następnie robisz słownik z datami startu i tworzysz relację pomiędzy ofertami i słownikiem. Przeszukiwanie powinno przyspieszyć.

A no i oczywiście na koniec sezonu VACUUM na bazie w celu usunięcia starych ofert.