Witam szanowne grono.

Mam bazę 1TB, dokładniej jedną tabele która ma 1TB danych, baza jest w InnoDB.
Czy pracując na takiej bazie indeksy wystarczą?
Jak najlepiej optymalizować tą baza, co zrobić żeby to fajnie działało.
Chodzi mi tu o zapytania SQL,
może trzeba odpowiedni config zrobić w pliku konfiguracyjnym MySQL?
Jak wy optymalizujecie takie tabele?

Z góry dzięki za pomoc.

Powinieneś znormalizować.

Optymalizacja zależy od struktury.

Wszystko ZALEŻY.
Jakie dane trzymasz, jaka jest selektywność poszczególnych kolumn no i co chcesz z tym zrobić.

zaczynasz dobrze kombinować
martw się o rozmiar indeksów, nie rozmiar tabeli:)

tuning pod konkretne potrzeby. dla innodb oczywiście są ogóle porady, łatwo je wygooglać.
bez szczegółowej wiedzy o Twoich potrzebach mogę z pewnością stwierdzić tylko jedno: domyślne ustawienia serwera mysql dla Ciebie będą ZŁE.

Witam !

Baza danych 1 TB to przeciez wiecej niz cala baza danych Wikipedii.
Do pracy z takimi zbiorami danych stosuje sie inne technologie niz bezposrednie zabijanie bazy danych .
Napisanie wlasnego oprogramowanie, bazujacego na algorytmie DFA, ADFA lub innym algorytmie szukajacym jest walka z wiatrakami, poniewaz od wielu lat rozwijane sa tego typu projekty i nie sadze zeby trzeba bylo wywazac otwarte juz drzwi.
Wikipedia uzywa JAVA-LUCENE. Mozna pokusic sie o uzycie projektu Nutch. Ewentualnie o jakis komercyjny projekt taki jak Exorbyte
Mysle, ze tak czy inaczej twoja 1TB tabele mozna - tak jak twierdza koledzy - logicznie zoptymalizowac, co jednak - jak sadze - niewiele pomoze przy checi bezposredniej pracy z DB.

P.S

Nie daj sie nabrac na Zend_Search_Lucene . Lojalnie przestrzegam i odradzam.

Pozdrawiam

zbigu, nie rozkręcając flame'a... ze dwa komentarze, bazując na Twoim wpisie

dzięki za tę ciekawostkę. tyle, że nadal 1TB to baza średniego rozmiaru.
udostępnić te 1TB 400mln userom, to dopiero issue:)

to tylko autor wie, co ma zamiar robić z tymi danymi. my możemy powróżyć z fusów co mu potrzeba.

podpisuję się 2 rękami

i to nawet pozostając przy mysql. jedna z różnych możliwości - silnik od infobrighta.

aczkolwiek, jakbym miał wybierać DB, to postawiłbym na oracla, chociażby ze względu na patrycjonowanie bazy. w mysql też można, ale w praktyce to przepaść.

Ja bym jeszcze się zastanowił nad silnikiem (czy na pewno musi być InnoDB) i ewentualnie budową klastra - aktualizujesz na jednym serwerze, czytasz z pozostałych. Powstaje opóźnienie - pytanie, czy jest dopuszczalne.

W ogóle, dużo pytań...

Hmm, wiem, że niektórzy praktykują algorytymy np. drzewa Celko aby unikać zagnieżdżeń wielokrotnych w klauzli IN () (duża liczba podzapytań zwalnia nawet największy serwer... widać to później w slow logach). Algorytm Celko bedzie przydatny przy kategoriach i ich podkategoriach. Ciekawa sprawa. Inną kwestią jest optymalizacja zmiennych (czy aby zamiast bigint(21) nie lepiej coś mniejszego) wykonanie testów zapytań EXPLAIN SELECT ... Użycie pól indexowych typu ENUM (zmienna indexowa) i SET, używanie szybkich pól bitowych może być pomocne. Czyszczenie bazy w postaci DELETE, czasem zbierają się śmieci... Jeżeli to dane tylko do przeszukiwania to może zamiast trybu InnoDB tryb MyISAM (fulltextsearch).
Ogólnie to polecam w google wpisać mysql performance blog i poprzeglądać ( I index).

Swoją drogą zaspokój moją ciekawość i powiedz gdzie mają takie duże bazy jeżeli nie w google, pentagonie i banku?

Pozdrawiam

np. Ogromne tablice tęczowe.
Hashe w różnych algorytmach md5, sha1 etc.