S rostoucí popularitou projektu se pojí narůstající návštěvnost, do hry začínají vstupovat různé analytické nástroje, sám Google navštěvuje web častěji a v horších případech se může stát cílem DDoS útoku. V tu chvíli vyvstává nutnost efektivně spravovat a škálovat databáze.
Z vlastní zkušenosti víme, že databáze bývá slabým článkem, který web zpomaluje a může vést ke snížení dostupnosti aplikace. A to především tehdy, pokud je potřeba na webu provádět složité výpočty, zobrazování informací z mnoha zdrojů (např. produktu s parametry, několika cenami, štítky apod.).
Aby se to netýkalo i vašeho webu, provedli jsme testování čtecích operací v různých databázích, jehož praktické výsledky a jejich srovnání vám teď ukážeme. Here we go!
Na počátcích každého webu se zpravidla využívá méně výkonná infrastruktura, protože při nízké návštěvnosti není ekonomicky výhodné platit drahé hostingové služby. V této fázi je prostě zbytečné investovat do předimenzovaného řešení.
S postupem času se ale situace mění. Jak se web dostává do povědomí, získává své zákazníky a návštěvnost roste, přichází potřeba změnit nejen samotný server, ale i technologie, na nichž web funguje. To se týká zejména databázového systému, který musí zvládat stále složitější operace a zpracovávat rostoucí množství dat bez ztráty výkonu.
Pojďme si na začátek říct, co se děje, když už databáze nestačí. To se může stát jak při dlouhodobém růstu návštěvnosti, tak nárazově, třeba během marketingových akcí, kdy je vysoká návštěvnost jen na pár dní.
V takových případech je potřeba ji škálovat. Každá databáze však umožňuje různé způsoby, v závislosti na jejích schopnostech. Zkrátka, škálovat můžete buď vertikálně, nebo horizontálně.
Vertikální škálování navýší zdroje (např. CPU, RAM) jednoho serveru, aby zvládal větší zátěž. Tento přístup je relativně jednoduchý na implementaci, ale má své limity, protože je omezen fyzickými možnostmi serveru. Jakmile vyčerpáte dostupné zdroje na serveru, není možné jej dále posilovat. Není totiž kde.
Horizontální škálování naopak zahrnuje přidání dalších serverů, které společně zátěž zpracovávají. Tento přístup umožňuje teoreticky neomezené škálování, protože je možné přidávat nové servery podle potřeby. Také zajistí lepší dostupnost a odolnost vůči výpadkům. V případě selhání jednoho serveru totiž mohou ostatní servery převzít jeho zátěž.
Nesmíme zapomenout ještě na jednu super možnost, a tou je geografická redundance! Jednoduše to znamená, že web funguje na několika serverech, které jsou umístěny ve více lokalitách. Takže čiště teoreticky, když vám velká voda vyplaví serverovnu „pod kopcem“, máte pořád další servery na kopci o 300 km dál. A web vesele frčí.
Které databáze pro vývoj webu, zejména v PHP, jsou nejčastěji používané? Jasně, jsou to SQL databáze MySQL a PostgreSQL. Tyto databáze tvoří základ většiny webových aplikací a e-shopů díky své spolehlivosti a široké podpoře. Rozepisovat se o tom, co všechno umí, není předmětem tohoto článku, pojďme se tedy podívat na čerstvý vítr v zatuchlém kamrlíku databází.
Pro zjištění, jakými možnostmi NewSQL databáze oplývají, jsme si vybrali CockroachDB. Hlavním důvodem byla kompatibilita s PostgreSQL, což znamená, že ji můžeme používat ve frameworku Symfony, se kterým pracujeme. To nám usnadnilo integraci díky nativní podpoře Doctrine. CockroachDB nabízí vysoký výkon a škálovatelnost. To jsou při rostoucí návštěvnosti klíčové faktory.
Škálování
CockroachDB podporuje horizontální škálování – do systému lze tak za běhu přidávat další servery bez výpadku. To poskytuje teoreticky neomezené škálování. Naproti tomu SQL databáze jako MySQL a PostgreSQL se obvykle škálují vertikálně, tedy zvyšováním prostředků (CPU, RAM) jednoho serveru. Horizontální škálování je výhodnější, protože eliminuje fyzické limity serveru a snižuje riziko selhání.
Dostupnost
Při selhání jednoho serveru dokáže CockroachDB automaticky přesměrovat požadavky na jiný uzel. Díky tomu je vysoce dostupný. Na rozdíl od tradičních SQL databází, kde při selhání serveru může dojít k úplnému výpadku služby, CockroachDB nabízí větší odolnost vůči chybám.
Kompatibilita
Výhodou CockroachDB je kompatibilnost s PostgreSQL. Ta sice umožňuje využívat Doctrine v Symfony, nicméně přináší i určité komplikace. Jedním příkladem za všechny je chybějící podpora funkcí jako AUTO_INCREMENT u primárního klíče, což vyžaduje změny v aplikaci. SQL databáze jsou naopak plně podporovány bez těchto úprav. Přechod na CockroachDB tak vyžaduje více práce.
Správa
Správa CockroachDB je trochu složitější. Tradiční SQL databáze jako MySQL a PostgreSQL mají širokou dostupnost nástrojů a podpory. Díky tomu je jejich správa jednodušší a obecně známější. Přechod na CockroachDB by kvůli rozdílnému fungování a potřebě specifických nástrojů znamenal významné změny ve stávajících postupech.
Pro účely testování jsme vytvořili dataset dvou set článků. Každý měl svůj název, popis a relaci na kategorii – ta obsahovala jméno a URL adresu, takže při vypisování článků se kromě jejich názvů a popisů, dotazovalo i na informace o kategoriích. Abychom simulovali reálnou zátěž a zjistili, jak se databáze chovají pod tlakem, záměrně jsme psali dotazy neoptimálně, takže každý výpis článků vyvolal další dotaz do databáze.
Testování probíhalo ve třech fázích podle počtu požadavků za minutu (RPM):
Výsledky
CockroachDB se při vysoké zátěži ukázala jako výkonnější databáze a to díky své schopnosti horizontálního škálování. Na rozdíl od PostgreSQL, která při vyšším zatížení výrazně zpomalila, CockroachDB efektivně rozložila zátěž mezi uzly a udržela lepší odezvu. Přestože při nízkém zatížení nebyly rozdíly tak výrazné, pro aplikace s vyššími požadavky na výkon a dostupnost se CockroachDB jeví jako vhodnější řešení.
I když CockroachDB v testech prokázala lepší výkon při vyšší zátěži a horizontální škálování přináší nesporné výhody, je potřeba se zamyslet, zda je přechod na NewSQL databáze ekonomicky výhodný.
V praxi může být tento přechod složitý, protože vývojáři NewSQL databáze většinou dobře neznají a nemají k dispozici tak rozsáhlou podporu a ekosystém jako u tradičních SQL databází. Pro dlouhodobé udržování a vývoj projektů psaných v PHP tedy není NewSQL zatím ideální volbou.
Z hlediska experimentu a možností škálování je NewSQL zajímavým řešením, avšak v reálném provozu, kde je důležitá stabilita a dostupnost podpůrných nástrojů, se ukazuje, že je v tuto chvíli poměrně nepraktické. Naštěstí tu ale máme nástroje jako ElasticSearch (NoSQL databáze), které dokáží splnit očekávání vysokého výkonu i dostupnosti při práci s daty. Ale o tom zase až příště.
Rostoucí návštěvnost a složitější databázové operace mohou být pro váš web velkou výzvou. Abyste se vyhnuli výpadkům a zajistili hladký chod aplikací, je klíčové mít spolehlivou technologii a správně navržené řešení. Vytvoříme vám web, aplikaci nebo klidně e-shop, které zvládnou i vysokou zátěž a komplexní operace. Chcete taky takový? Ozvěte se nám, vyřešíme váš problém.
Rok se s rokem sešel a v pražském Cubexu se konal další ročník konference Brand Management. Loňský rok se nesl v duchu ekonometrie, dat a Les Bine...
Do marketingového klubu Cognito přestoupili dva hvězdní hráči – Martin Veselský a Simona Matúšková. Žluto-modrý dres oblékají od konce srpna a ryc...
Vyřešit problém s bezhotovostními platbami spropitného v hotelových provozech se rozhodl pražský startup Smart Tips. Pro realizaci technického řeš...
