|
Datagestuurde applicaties bestrijken een breed scala aan complexiteiten, van eenvoudige microservices tot realtime gebeurtenisgestuurde systemen die zwaar worden belast. Zoals echter elk ontwikkelings- en/of DevOps-team dat belast is met prestatieverbeteringen zal bevestigen, is het "niet triviaal" om datagestuurde apps wereldwijd snel te maken.
Moderne applicatie-architecturen zoals de JAMstack dwingen de scheiding van zorgen af door de gegevens- en persistentievereisten naar de API te verplaatsen. Door statische inhoud, bedrijfslogica en gegevenspersistentie netjes te scheiden, kan elk afzonderlijk worden geschaald en beheerd.
Veel bedrijven zijn ook gericht op het ontkoppelen van hun monolithische applicaties om microservices te gebruiken en implementeren vaak in serverloze omgevingen. Deze verschuiving naar meer ontkoppeling voor een betere isolatie van de omgeving kan ook zorgen voor een betere regionale flexibiliteit met betrekking tot waar bedrijfslogica wordt ingezet en hoe deze wordt geschaald. Applicaties kunnen nu wereldwijd worden geïmplementeerd in een enkele CI/CD-actie.
De gegevenslaag is echter complexer. Er zijn praktische uitdagingen zoals transactieconsistentie, hoge beschikbaarheid en queryprestaties onder belasting. Er zijn beperkingen, zoals het naleven van PII en nalevingsvereisten. En er zijn onoverkomelijke grenzen zoals die de wetten van de fysica aan latency opleggen.
Applicatiecaching
Veel ontwikkelingsteams kijken naar caching om deze problemen op de applicatielaag op te lossen, ondersteund door persistentielagen zoals Redis of zelf ontwikkelde systemen. Het concept is eenvoudig:bewaar de door de klant gevraagde gegevens voor een bepaalde periode en als we ze opnieuw zien, hebben we ze klaar om de volgende aanvraag te behandelen zonder toevlucht te nemen tot de oorspronkelijke database. Het ontwikkelen van een goede cachingstrategie brengt zijn eigen uitdagingen met zich mee:welke gegevens moeten worden gecached, hoe deze moeten worden gecachet en wanneer. En misschien nog belangrijker, wat, hoe en wanneer gegevens uit de cache moeten worden verwijderd. De cachingstrategie moet goed worden gedefinieerd, begrepen en toegepast voor elke nieuwe functieset die aan de applicatie wordt toegevoegd, door ontwikkelaars en mogelijk afdelingsteams. Ontwikkelingstijd en complexiteit zijn de kosten.
Database leesreplica's
Als alternatief lossen veel bedrijven latentie- en schaalproblemen op met database-leesreplica's. Leesreplica's zijn alleen-lezen exemplaren van de primaire database en worden automatisch gesynchroniseerd (asynchroon) gehouden wanneer er updates voor de primaire database worden gemaakt. Het ontwikkelen van een solide read-replica-strategie is een ontmoedigende taak vol zijn eigen subtiele en niet zo subtiele kosten en complexiteiten.
Veel van die complexiteit kan worden getemd met ScaleGrid. Volledig beheerde leesreplica's kunnen met een klik op een knop worden geïmplementeerd vanuit ScaleGrid (met HA-ondersteuning) in alle grote clouds en regio's, met als belangrijkste voordeel dat de gegevens automatisch gesynchroniseerd worden met de primaire database.
Leesreplica's kunnen echter niet ontsnappen aan de noodzaak om meerdere, misschien wel veel meervoudige databaseservers te draaien en de bijbehorende kosten.
Een andere benadering:PolyScale.ai Edge Cache
PolyScale is een database edge-cache die een andere benadering heeft. De cache van PolyScale biedt twee belangrijke voordelen:verbeterde querylatentie en verminderde databasewerkbelasting. Laten we dat een beetje opsplitsen:
Regionale latentie wordt net als een CDN opgelost; PolyScale biedt een wereldwijd edge-netwerk van Points of Presence (PoP) en slaat antwoorden op databasequery's op dicht bij de oorspronkelijke client, waardoor de antwoorden aanzienlijk worden versneld.
Leesqueryprestaties is drastisch verbeterd omdat PolyScale elk databaseverzoek in de cache in <10 ms zal behandelen, ongeacht de complexiteit van de query. Bovendien, aangezien leesverzoeken worden geleverd vanuit PolyScale, heeft deze belasting nooit invloed op de oorspronkelijke database.
Implementatie
PolyScale kan in een paar minuten worden geïmplementeerd zonder code te schrijven of servers in te zetten. Werk eenvoudig de databaseclient (of het nu een webtoepassing, microservice of BI-tool zoals Tableau is) bij met de PolyScale-hostnaam. Databaseverkeer gaat dan door het edge-netwerk en is klaar voor caching.
Omdat PolyScale wire-compatibel is met MySQL en Postgres, is het volledig transparant voor databaseclients, dus verandert er niets aan uw huidige architectuur. Geen migraties, geen wijzigingen in de transactionaliteit en geen wijzigingen in uw huidige querytaal. Echt plug-and-play.
Hoe werkt het?
PolyScale's wereldwijde netwerkproxy's en caches native database wire-protocollen, zodat het transparant is voor elke databaseclient. Query's worden geïnspecteerd en gelezen (SQL SELECT ) kan geografisch dicht bij de aanvragende oorsprong in de cache worden opgeslagen voor versnelde prestaties. Al het andere verkeer (INSERT , UPDATE en DELETE ) gaat naadloos door naar de brondatabase.
PolyScale's AI is op weg naar volledige automatisering. In plaats van de cache naar behoefte te configureren, meet het platform de verkeersstroom en past het de caching-eigenschappen continu aan om optimale prestaties te leveren. U kunt hier meer lezen over het PolyScale AI-cachingmodel.
Conclusies
PolyScale.ai biedt een moderne, plug-and-play-benadering van prestaties en schaalbaarheid op het gegevensniveau. Het PolyScale-platform is op weg naar volledige automatisering waarbij, eenmaal verbonden, de gegevens in de cache op intelligente wijze worden beheerd voor optimale prestaties.
Aangezien PolyScale wire-compatibel is met uw huidige database, zijn er geen wijzigingen nodig om de uitlezingen binnen enkele minuten wereldwijd te schalen. Probeer het eens!