Relační databáze a datový model

Index a limity relačních databází

Databáze s pár tisíci řádky je rychlá vždycky. U milionů řádků ale začne záležet na tom, jak v datech hledá, a taky na tom, jestli je relační databáze pro naše data vůbec ta správná volba.

Index

Tabulka customers má milion řádků a zákazník se přihlašuje e-mailem. Kolik řádků musí databáze projít, než ho najde?

Bez další pomoci všechny. Neví, kde zákazník leží, takže čte jeden řádek za druhým, dokud na e-mail nenarazí. Pro jedno přihlášení je to milion porovnání.

Proto si databáze pro vybrané sloupce vede index. Je to samostatná seřazená struktura, ve které jsou hodnoty sloupce a u každé odkaz na její řádek. Funguje jako rejstřík na konci učebnice: místo listování celou knihou najdete heslo v abecedním seznamu a ten vás pošle na správnou stránku.

V seřazeném seznamu se hledá půlením. Podíváme se doprostřed, podle abecedy poznáme, ve které polovině hledaný e-mail leží, a druhou polovinu zahodíme. Každý krok vyloučí polovinu zbývajících řádků, takže milion řádků databáze projde zhruba za 20 kroků.

Index se zakládá pro konkrétní sloupec:

CREATE INDEX idx_customers_email ON customers (email);

Primární klíč dostane index automaticky, o ten se starat nemusíme.

Index není zadarmo

Když index tolik zrychlí hledání, proč ho nedat na každý sloupec? Protože ho databáze musí udržovat. Každé vložení, změna nebo smazání řádku upraví i všechny indexy tabulky, takže zápis se s každým dalším indexem zpomalí. A index zabírá místo na disku.

Index se proto dává na sloupce, podle kterých se často hledá, řadí nebo spojuje tabulky. Typicky to jsou cizí klíče a sloupce jako e-mail nebo datum. Naopak u sloupce s pár možnými hodnotami, třeba ano a ne, index skoro nepomůže: polovinu tabulky musí databáze přečíst tak jako tak.

Kde relační databáze nestačí

Relační databáze je výchozí volba pro většinu aplikací, ale má i nevýhody:

• Pevné schéma. Struktura tabulek se navrhuje předem. Data, u kterých každý záznam vypadá jinak, se do ní ukládají těžko, a přidat sloupec do tabulky se stovkami milionů řádků je samo o sobě projekt.
• Škálování. Relační databázi se nejsnáz pomůže silnějším serverem. Rozložit ji na víc serverů je složité, protože vazby mezi tabulkami chtějí mít data pohromadě.
• Spojování tabulek. Dotaz, který skládá dohromady deset tabulek, je pomalý i nepřehledný.
• Data jiného tvaru. Na velké soubory jako videa, volný text nebo síť vztahů mezi lidmi v sociální síti existují vhodnější nástroje.

Pro takové případy vznikly tzv. NoSQL databáze, třeba dokumentová MongoDB nebo Redis, který ukládá dvojice klíč a hodnota. Relační databázi ale nenahrazují, spíš doplňují: velké aplikace často používají obojí.