Wordt 2023 het jaar van de polyglot volharding?

Heruitgegeven door Plato

volgers: 0

Maak kennis met polyglot persistentie.

Het is geen nieuwe term, maar wel een die vlam vat in wat velen het meest onsexy onderdeel van gegevensbeheer noemen: Database Management. Het sluit ook aan bij het fysieke deel van gegevensbeheer, namelijk opslagbeheer, dat vaak over het hoofd wordt gezien door gegevensteams.

Opslagbeheer en databasebeheer/-administratie waren vroeger inderdaad een aparte zorg. De data-engineer of wetenschapper maakte zich meer zorgen over het creëren van de juiste data-workflows uit meerdere bronnen.

Totdat prestaties en optimalisatie problemen werden. De datateams van vandaag werken met meerdere databronnen, elk met meerdere datatypes.

Neem bijvoorbeeld een eenvoudig e-commerce platform. Mogelijk moet het sessiegegevens opslaan, met zoekgegevens werken en geo-gelokaliseerde betalingsgegevens verwerken.

U moet coderen en verbindingen maken om deze databases met elkaar te laten praten. Maar er is één groot probleem: er is een lange waslijst met databases die goed zijn in het ene en niet in het andere.

Om de juiste verbindingen tot stand te brengen, moet u weten welke databases voor u geschikt zijn – wat moeilijk kan zijn omdat er bijna elke dag nieuwe technologieën online komen.

De pleidooi voor polyglot-persistentie

Het polyglot persistentiemodel biedt een andere benadering van hetzelfde probleem.

Het zou ons bijvoorbeeld in staat hebben gesteld om met Elasticsearch te werken voor zoekresultaten, MongoDB in staat te stellen gebruikersinformatie op te slaan, Memcached te gebruiken om de cache af te handelen en Azure de financiële transactiegegevens te laten bewaren.

Net als zijn neef, polyglot-programmering, erkent het dat geen enkele opslagoplossing geschikt is voor alle gegevensopslagbehoeften van uw toepassingen. Dus waarom zou u geen hybride antwoord creëren op de huidige uitdagingen op het gebied van database- en opslagbeheer?

Polyglot-persistentie slaat aan omdat de industrie applicaties op een andere manier maakt. Traditioneel werkten monolithische applicaties met een enkele database of op een monoglot-manier.

Applicaties maken tegenwoordig gebruik van een microservice-architectuur. Een enkele applicatie wordt dus uitgevoerd als een set van individuele services met een functioneel bereik. Dit maakt flexibiliteit en schaalbaarheid mogelijk.

Maar microservices een nieuwe uitdaging introduceren. Elke microservice voert een database uit voor elk onderdeel. Dit betekent dat het implementeren van query's en atomaire, consistente, geïsoleerde en duurzame (ACID) transacties een uitdaging kan zijn.

Databaseprogrammeurs moeten dus voorzichtig met dit probleem omgaan wanneer ze verschillende databases samenvoegen. De zoeklogica moet nauwkeurig zijn.

Dan heb je de kwestie van het kiezen van een geschikte database voor een specifieke use case. Er zijn meerdere smaken van hetzelfde type databases, die elk goed presteren in een bepaalde use-case.

U wilt bijvoorbeeld schemaloze documentdatabases zoals MongoDB opslaan voor het opslaan van uw documenten. Aan de andere kant, om miljoenen entiteiten en gebruikers met elkaar te verbinden, geeft u misschien de voorkeur aan een grafische database zoals Neo4j. Ten slotte kunt u voor tijdreeksgegevensopslag de eerbiedwaardige Cassandra kiezen.

Met Polyglot-persistentie kunt u een specifieke database gebruiken voor elk van uw microservices.

Pas op voor de uitdagingen

Polyglot persistentie heeft zijn nadelen.

De eerste en meest voor de hand liggende is complexiteit. Het toevoegen van een gespecialiseerde database voor verschillende microservices vereist specifieke systemen en expertise. Let niet op de hardware; het vinden van de juiste mensen met veeltalige kennis van databases kan een uitdaging zijn.

Integratielagen kunnen dynamisch worden; het vinden van de faalpunten kan een andere uitdaging zijn. Niet iedereen heeft het geduld van Sherlock Holmes om het te onderzoeken, noch hebben ze de tijd om het met de huidige digitale snelheden te doen. Om alles goed en consequent te laten werken, zijn extra middelen nodig.

Dan heb je de kwestie om de oorzaak van een probleem te vinden. Triaging wanneer uw toepassing als monoglot eenvoudig is; het volgen van de verschillende threads naar een probleem in een polyglot persistentiemodel kan lastig zijn als je verschillende versies van de waarheid hebt. Dit betekent dat Data Governance een flinke uitdaging kan zijn.

Dit zorgt voor een andere hoofdpijn: nakoming. Zonder een holistisch beeld van al uw data en unified audit trail data, kunnen datalekken kostbaar zijn.

De voordelen zijn echter overtuigend.

Het idee om services losjes gekoppeld te houden door ze niet aan een enkele database te binden, de mogelijkheid om de beste database te kiezen (of zelfs te ruilen voor een betrouwbaardere) voor elke microservice op basis van de use case, en het idee om elke data-workload de beste en meest optimale omgeving voor verwerking en opslag maken deze trend tot een trend om in de gaten te houden.