|
Aplikace řízené daty pokrývají širokou škálu složitosti, od jednoduchých mikroslužeb až po systémy řízené událostmi v reálném čase při značné zátěži. Jak však potvrdí každý vývojový a/nebo DevOps tým pověřený zlepšováním výkonu, zrychlení aplikací založených na datech globálně je „netriviální“.
Moderní aplikační architektury, jako je JAMstack, vynucují oddělení problémů přesunem požadavků na data a perzistenci do API. Čisté oddělení statického obsahu, obchodní logiky a perzistence dat umožňuje, aby každý z nich byl škálován a spravován nezávisle.
Mnoho podniků se také zaměřuje na oddělení svých monolitických aplikací za účelem využívání mikroslužeb a často je nasazují v prostředích bez serverů. Tento posun k většímu oddělení pro lepší izolaci životního prostředí může také zajistit lepší regionální agilitu s ohledem na to, kde je nasazena obchodní logika a jak je škálována. Aplikace lze nyní nasadit globálně v jediné akci CI/CD.
Datová vrstva však představuje větší složitost. Existují praktické problémy, jako je transakční konzistence, vysoká dostupnost a výkon dotazů při zatížení. Existují omezení, jako je dodržování PII a požadavky na shodu. A existují nepřekonatelné meze, jako jsou ty, které na latenci uvalují fyzikální zákony.
Ukládání aplikací do mezipaměti
Mnoho vývojových týmů se snaží tyto problémy vyřešit ukládáním do mezipaměti na aplikační vrstvě, podporované vrstvami persistence, jako je Redis nebo domácí systémy. Koncept je jednoduchý:uložte data požadovaná klientem po určitou dobu, a pokud je znovu uvidíme, máme je připravena obsloužit další požadavek, aniž bychom se museli uchylovat k původní databázi. Vytváření dobré strategie ukládání do mezipaměti přináší vlastní řadu problémů:jaká data ukládat do mezipaměti, jak je ukládat a kdy. A možná ještě důležitější je, co, jak a kdy vyřadit data z mezipaměti. Strategie ukládání do mezipaměti musí být dobře definována, pochopena a použita pro každou novou sadu funkcí přidanou do aplikace, a to napříč vývojáři a potenciálně týmy oddělení. Čas a složitost vývoje jsou náklady.
Repliky pro čtení databáze
Mnoho podniků alternativně řeší problémy s latencí a škálováním pomocí replik pro čtení z databáze. Čtené repliky jsou instance primární databáze pouze pro čtení a jsou automaticky synchronizovány (asynchronně), když jsou prováděny aktualizace primární databáze. Vytváření solidní strategie čtení a repliky je skličující úkol, který má své vlastní jemné a ne tak jemné náklady a složitosti.
Většinu této složitosti lze zkrotit pomocí ScaleGrid. Plně spravované repliky pro čtení lze nasadit kliknutím na tlačítko ze ScaleGrid (s podporou HA) do všech hlavních cloudů a oblastí, přičemž klíčovou výhodou je, že data jsou automaticky synchronizována s primární databází.
Čtení replik však nemůže uniknout nutnosti provozovat více, možná mnohonásobných databázových serverů a související náklady.
Jiný přístup:PolyScale.ai Edge Cache
PolyScale je mezipaměť na okraji databáze, která má jiný přístup. Mezipaměť PolyScale poskytuje dvě hlavní výhody:vylepšenou latenci dotazů a nižší zátěž databáze. Pojďme to trochu rozebrat:
Regionální latence je řešeno podobně jako CDN; PolyScale poskytuje globální okrajovou síť Points of Presence (PoP) a ukládá odpovědi na databázové dotazy blízko původního klienta, což výrazně urychluje odpovědi.
Čtení výkonu dotazu je dramaticky vylepšen, protože PolyScale obslouží jakýkoli požadavek na databázi uložený v mezipaměti za <10 ms, bez ohledu na složitost dotazu. Navíc, vzhledem k tomu, že požadavky na čtení jsou obsluhovány z PolyScale, toto zatížení nikdy neovlivní původní databázi.
Implementace
PolyScale lze implementovat bez psaní kódu nebo nasazování serverů během několika minut. Jednoduše aktualizujte připojovací řetězec databázového klienta (ať už jde o webovou aplikaci, mikroslužbu nebo nástroj BI, jako je Tableau) pomocí názvu hostitele PolyScale. Databázový provoz poté projde okrajovou sítí a je připraven pro ukládání do mezipaměti.
Díky drátové kompatibilitě s MySQL a Postgres je PolyScale pro databázové klienty zcela transparentní, a proto se na vaší současné architektuře nic nemění. Žádné migrace, žádné změny transakčních vlastností a žádné změny vašeho aktuálního dotazovacího jazyka. Skutečně plug and play.
Jak to funguje?
Globální síť PolyScale využívá a ukládá do mezipaměti nativní databázové drátové protokoly, takže je transparentní pro každého databázového klienta. Dotazy jsou kontrolovány a čteny (SQL SELECT ) lze uložit do mezipaměti geograficky blízko žádajícího původu pro zrychlený výkon. Veškerý ostatní provoz (INSERT , UPDATE a DELETE ) plynule prochází do zdrojové databáze.
Umělá inteligence PolyScale je na cestě k plné automatizaci. Namísto konfigurování mezipaměti podle potřeby bude platforma měřit tok provozu a průběžně upravovat vlastnosti mezipaměti, aby poskytovala optimální výkon. Více o modelu ukládání do mezipaměti PolyScale AI si můžete přečíst zde.
Závěry
PolyScale.ai poskytuje moderní, plug and play přístup k výkonu a škálování na datové vrstvě. Platforma PolyScale je na cestě k plné automatizaci, kde po připojení bude inteligentně spravovat ukládání dat do mezipaměti pro optimální výkon.
Vzhledem k tomu, že PolyScale je drátově kompatibilní s vaší aktuální databází, nejsou nutné žádné změny pro globální škálování čtení během několika minut. Zkuste to!