Jeg arbejdede engang med en meget stor (Terabyte+) MySQL-database. Det største bord, vi havde, var bogstaveligt talt over en milliard rækker.
Det virkede. MySQL behandlede dataene korrekt det meste af tiden. Det var dog ekstremt uhåndterligt.
Bare det at sikkerhedskopiere og gemme dataene var en udfordring. Det ville tage dage at genoprette bordet, hvis vi havde brug for det.
Vi havde adskillige borde i intervallet 10-100 millioner rækker. Enhver væsentlig sammenføjning til bordene var for tidskrævende og ville tage evigheder. Så vi skrev lagrede procedurer for at 'gå' tabellerne og behandle joinforbindelser mod rækker af 'id'er. På denne måde vil vi behandle dataene 10-100.000 rækker ad gangen (Join mod id's 1-100.000 derefter 100.001-200.000 osv.). Dette var betydeligt hurtigere end at deltage mod hele bordet.
Det er også meget vanskeligere at bruge indekser på meget store tabeller, der ikke er baseret på den primære nøgle. Mysql gemmer indekser i to stykker -- det gemmer indekser (bortset fra det primære indeks) som indekser til de primære nøgleværdier. Så indekserede opslag udføres i to dele:Først går MySQL til et indeks og trækker fra det de primære nøgleværdier, som det skal finde, derefter foretager det et andet opslag på det primære nøgleindeks for at finde, hvor disse værdier er.
Nettet af dette er, at for meget store tabeller (1-200 millioner plus rækker) er indeksering mod tabeller mere restriktiv. Du har brug for færre, enklere indekser. Og at lave selv simple udvalgte udsagn, der ikke er direkte på et indeks, kommer måske aldrig tilbage. Hvor klausuler skal hit indekser eller glem det.
Men når det er sagt, så virkede tingene faktisk. Vi var i stand til at bruge MySQL med disse meget store tabeller og lave beregninger og få svar, der var rigtige.