Pod pojmem databáze se mi vybaví hlavně relační databáze MySQL. V kategorii relačních databází (RDBMS) je jedničkou Oracle, ta je však placená, tak se pro běžné použití většinou vystačí z volně dostupnou MySQL (založena v roce 1995, v roce 2008 koupena firmou Sun Microsystems, později projekt přešel pod Oracle, v tu dobu vznikl fork MariaDB z obav open-source komunity, že Oracle bude brzdit vývoj volně dostupné MySQL a upřednostňovat jejich komerční databázi Oracle).
MariaDB je tedy poháněna nápady open-source komunity, liší se v maličkostech, ty dobré věci od sebe navzájem přebírají obě verze, takže jsou kompatibilní a benchmarky nedokážou určit, která z těchto dvou je rychlejší. Záleží na dotazech. Jednoduché dotazy nepotřebují relační databázi a SQL spojování tabulek přes join, indexy, foreign klíče.
MySQL nestačí na všechny úkoly webové aplikace
Většina webových aplikací potřebuje řešit jednoduché a rychlé načítání/ukládání velkého množství hodnot z/do databáze. Relační SQL databáze se pro práci s větším množstvím dat nehodí, prostě MySQL nezvládne obsloužit milióny dotazů za vteřinu. A také škálovatelnost systému postaveném na MySQL je problém, při rostoucích nárocích na výkon přidat další slave, replikovat bezproblémově relační databázi z masteru je těžké. Na úkoly vhodné pro relační databáze lze databáze typu klíč-hodnota použít jako cache, což bývá většinou první volba při škálování webu pro zvýšení rychlosti.
Snadnější replikace dat a škálovatelnost systému
Pro většinu úkolů moderní webové aplikace/stránky se hodí použít NoSQL databázi typu klíč-hodnota. Příkladem databáze klíč-hodnota je Redis nebo Memcached. Tyto databáze dokážou pod jedním klíčem ukládat data (může být jedna hodnota nebo i složitý objekt) primárně do paměti. Kromě toho si ukládají data také na disk, takže čtení/zápis je bleskově rychlé a zároveň nehrozí ztráta dat, pokud se něco stane s HW. Pro jistotu lze použít dvě instance a replikovat data. Moje zkušenosti s replikací dat v MySQL jsou velice špatné, pokud vývojáři něco mění za chodu, často se replikace rozbijí, spadnou a oprava je náročná (zjistit problémové tabulky, přihlásit se na master, zkopírovat data, přihlásit na slave, nahrát data) shit. NoSQL databáze typu klíč-hodnota jsou lépe škálovatelné, podporují replikace master-slave a některé umí slave udělat read-only, takže zápis probíhá pouze na master a čtení odkudkoliv.
Datové struktury v klíč-hodnota databázích
MySQL umí jazyk SQL, ten u těchto databází není. Jak nahradit uložení dat rozložených např. v 5 tabulkách MySQL vzájemně propojených klíči ? Redis nebo Memcached podporují uložení řetězců, Redis navíc další, ale bohatě stačí ten string, protože PHP i jiné jazyky umí serializaci. Při uložení použiju serializaci dat a při čtení deserializaci. Někteří považují za čistější řešení vytvořit strukturu SQL tabulku, pro každý sloupec zvolit vhodný datový typ, určit maximální délku např. VARCHAR, což je problém, když najednou dostanete úkol např. změnit popisek v článku, popis nějaké akce, popis čehokoliv a nemáte ošetřen max.limit, takže se neuloží všechno co uživatel vyplnil do formuláře. Mnohem jednodušší a rychlejší je používat objekty v PHP a ukládat je do databáze serializované jako string. Validaci a filtrování řešit v PHP. Problém je akorát ten, že serializovaný string v relační databázi nejde přímo deserializovat a použít v SQL dotazech. Bude třeba s ním takto pracovat ?
Příklad využití serializace při ukládání do databáze
Např. ukládání konfigurace do databáze. Mám nastavení uživatele a firmy. Uživatel bude mít nějaké jméno, příjmení, email. Firma bude mít jméno, město, ulici, psč, ič, dič. Proč vytvářet 2 tabulky, kde budou muset být sloupce pro každou hodnotu, i když tam bude vždy jen jeden řádek ? Při rozšiřování by to vyžadovalo vytvoření dalších sloupců, řešit jejich délku na dvou místech. Není lepší vytvořit 1 tabulku, kde budou pouze 2 sloupce klíč a hodnota jako to používá např. populární CMS systém WordPress ? Zapíšu jeden řádek s klíčem uživatel a do hodnoty dám serializovaný objekt, kde bude jméno, příjmení, email a stejně tak pro firmu 1 řádek. Při změně struktury objektu uživatel nebo firma nebudu vůbec muset řešit databázi. A pozor, novější verze MySQL už na tohle zareagovali přidáním nativní podpory JSON objektu. JSON je asi nejlepší řešení datové struktury. Podporuje ho PHP, Javascript a už také MySQL. Můžete s ním pracovat v REST API a je lidsky čitelný i bez nutnosti použít nějaký jazyk. Navíc se dá úpravou pretty zkrášlit přidáváním/ubíráním odsazení textu.