Het Polyglot probleem: het oplossen van de Paradox van de ‘juiste’ Database

(Leszek Glasner/)

Polyglot persistentie, voor het eerst geïntroduceerd in 2011, is nu bijna canoniek recht in het. Dus, wat ik te zeggen heb kan overkomen als godslastering.

de meeste organisaties van vandaag hebben het concept van Polyglot Persistence — de invoering van een verscheidenheid van verschillende data-opslagtechnologieën gebaseerd op de verscheidenheid van manieren waarop zij hun gegevens opvragen, analyseren en implementeren. En de groei en alomtegenwoordigheid van key/value, graph, time series, en JSON data stores heeft ontwikkelaars voorzien van een overvloed aan keuzes om de juiste data tool voor de juiste baan te kiezen.

maar de eisen aan ons als ontwikkelaars zijn snel geëvolueerd en ik geloof dat Polyglot persistentie snel zal worstelen om gelijke tred te houden. Of misschien is dat de realiteit waar je vandaag voor staat. Waarom? Want de taak die we hebben is ontmoedigend en ontwikkelingsteams zijn al dun gestrekt.

Databasediversiteit

we moeten experts zijn op een breed spectrum van databasetechnologieën, elk met hun eigen query-talen. We hebben onze applicaties nodig om efficiënte resultaten te leveren in een groeiend aantal use cases. We worden gevraagd om honderden, groeiende tot duizenden verschillende data-driven applicaties te bouwen en te beheren die een verscheidenheid aan datamodellen en implementaties vereisen. Kun je je voorstellen dat je nog een andere technologie of query taal beheerst en onderhoudt? Wat dacht je van nog vijf? Nog tien?

Software eet de wereld op, onze ontwikkelingsinspanningen zullen alleen maar toenemen, de tijd en kosten om meerdere datastores te integreren zijn onhoudbaar en ontwikkelaars moeten zich dringend concentreren op een eindige reeks databasetechnologieën.

belangrijker is dat use cases steeds geavanceerder worden en wat we van onze gegevens zullen vragen, vereist het gebruik van meerdere datamodellen, misschien zelfs ogenblikkelijk. Het bouwen van oplossingen in de applicatie code om query ‘ s te berekenen is niet duurzaam of schaalbaar. Ik geloof dat het tijd is dat organisaties hybride benaderingen zoeken die hen in staat stellen om zowel hun technologieportfolio te vereenvoudigen en de flexibiliteit hebben om het juiste datamodel voor de juiste baan te kiezen.

het verkennen van gegevensmodellen

ik heb ontdekt dat het nuttig is om te begrijpen welke gegevensmodellen goed werken voor verschillende toepassingen en hoe deze kunnen worden gecombineerd.

JSON Document Databases

JSON is zeer veelzijdig voor ongestructureerde en gestructureerde gegevens. De recursieve aard van JSON maakt het inbedden van subdocuments en variabele lengte lijsten. Bovendien kunt u zelfs de rijen van een tabel opslaan als JSON-documenten, en moderne gegevensopslag zijn zo goed in het comprimeren van gegevens dat er in wezen geen geheugen overhead is in vergelijking met relationele databases. Voor gestructureerde gegevens kan schemavalidatie naar behoefte worden geïmplementeerd met behulp van een uitbreidbare HTTP-API.

Grafiekendatabases

Grafiekendatabases zijn goede gegevensmodellen voor relaties. In veel Real-world gevallen is een grafiek een zeer natuurlijk datamodel. Het legt relaties vast en kan labelinformatie bevatten met elke rand en met elke hoekpunt. JSON-documenten zijn een natuurlijke pasvorm om dit type vertex-en randgegevens op te slaan.

een grafiekendatabase is bijzonder goed voor” grafiekenqueries”. Het cruciale ding hier is dat de query taal routines zoals “kortste pad” en “graph traversal” moet implementeren, de fundamentele mogelijkheid voor deze is om toegang te krijgen tot de lijst van alle uitgaande of inkomende randen van een vertex snel.

Databases met meerdere modellen

een database met meerdere modellen combineert de mogelijkheden van databases met documenten, sleutels/waarden en grafieken. Hiermee kunt u verschillende datamodellen kiezen met minder operationele overhead. Het hebben van meerdere data modellen beschikbaar in een enkele database engine verlicht een aantal van de uitdagingen van het gebruik van verschillende data modellen op hetzelfde moment, omdat het betekent minder operationele overhead en minder data synchronisatie, en zorgt daarom voor een enorme sprong in data modellering flexibiliteit.

u hebt plotseling de mogelijkheid om gerelateerde gegevens bij elkaar te houden in hetzelfde gegevensarchief, zelfs als er verschillende datamodellen nodig zijn. De mogelijkheid om de verschillende datamodellen te mengen binnen een enkele query verhoogt de opties voor applicatieontwerp en prestatieoptimalisaties. En als je ervoor kiest om de persistence layer op te splitsen in verschillende databasemodellen (zelfs als ze hetzelfde datamodel gebruiken), heb je nog steeds het voordeel dat je slechts één technologie hoeft te implementeren. Bovendien wordt een datamodel lock-in voorkomen.

de Polyglot-oplossing

Polyglot-persistentie werd aanvaard omdat het ons in staat stelde om te voorkomen dat we afbreuk zouden doen aan één monolithische databasetechnologie. We begrepen dat persistentie van Polyglot gepaard ging met kosten in complexiteit, kosten voor prestaties en kosten voor consistentie en beschikbaarheid naarmate clusters groter en groter werden. Maar de meesten, zo niet alle, van ons vonden dat de voordelen van flexibiliteit van datamodellen die kosten veel zwaarder wegen omdat één monolithische database nooit zou en zal bestaan om alle of zelfs de meeste vereisten en use cases aan te pakken.

vandaag is het duidelijk dat we de voordelen van Polyglot persistentie zonder de kosten nodig hebben. We moeten de flexibiliteit hebben om hoogwaardige applicaties te bouwen die horizontaal schalen en gebruik maken van een verscheidenheid aan datamodellen. We hebben query talen nodig die ons in staat stellen om native en over verschillende datamodellen te bevragen. We hebben databases nodig om ons de vrijheid en flexibiliteit te geven om verschillende datamodellen op unieke manieren te gebruiken naarmate onze projecten onvermijdelijk evolueren.

voor veel geavanceerde organisaties is het al gebruikelijk om een kleine grafische database te gebruiken in een deel van een project, een grote key/value-implementatie voor een ander deel of een combinatie van graph, key/value en document (JSON) modellen voor een ander deel.

veelzijdigheid van gegevens

beschouw een complexe gegevensverzameling zoals die voor een vliegtuigvloot die bestaat uit meerdere vliegtuigen, elk bestaande uit enkele miljoenen onderdelen, die deelcomponenten vormen, vervolgens Grotere en kleinere componenten, die allemaal in een hiërarchie van items vallen.”

voor optimaal onderhoud van de vloot moet de organisatie een verscheidenheid aan gegevens opslaan op verschillende niveaus van de hiërarchie, bijv. namen van onderdelen of onderdelen, serienummers, informatie over de fabrikant, onderhoudsintervallen, onderhoudsdata, informatie over onderaannemers, links naar handleidingen en documentatie, contactpersonen, informatie over garantie-en servicecontracten, enz. Dat soort gegevenshiërarchie is een duidelijke natuurlijke pasvorm voor een grafiekdatabase omdat het relaties tussen verschillende gegevenspunten, waaronder informatie op elke rand en top vangt. Maar is een grafiekdatabase ideaal om de belangrijkste vragen van het fleet maintenance team efficiënt te beantwoorden?

een grafiekendatabase presteert goed voor de vraag: “Wat zijn alle onderdelen in een bepaald onderdeel?”En het zou kunnen helpen bij het beantwoorden van de vraag: “gegeven gebroken deel A, Wat is het kleinste onderdeel van het vliegtuig dat het onderdeel bevat en waarvoor er een onderhoudsprocedure is?”Maar een grafiekdatabase zou enigszins nutteloos zijn met een veel voorkomende vraag zoals” welke onderdelen van dit vliegtuig moeten volgende week onderhoud?”omdat de grafische structuur niet past bij de query.

echter, als die grafiekgegevens als JSON-documenten konden worden opgeslagen, waarbij willekeurige gegevens werden gekoppeld aan hoekpunten en randen, kon die vraag gemakkelijk worden beantwoord door middel van een documentquery.

het punt is dat om alle query ‘ s in dat systeem snel gedaan te krijgen, je een database nodig hebt die informatie kan opslaan als een verscheidenheid aan gegevensmodellen, vaak een multi-model database genoemd. Zou het niet leuk zijn als die grafiekdatabase secundaire indexen kon implementeren op zijn vertex data?

maar dan zou het in wezen een database met meerdere modellen worden. Dat is een goede eerste stap. Het ideale scenario is met behulp van een grafiek, document, en een sleutel/waarde data model allemaal op hetzelfde moment om eerst onderdelen met onderhoud als gevolg, loopt de bovenstaande kortste pad berekening voor elk van hen, en voer dan een join operatie met de contacten collectie om concrete contactgegevens toe te voegen. Toegang tot een ander gegevensmodel moet gewoon een query veranderen, niet je database. Daar moeten we heen, en snel.

dit voorbeeld van wagenparkonderhoud is niet uniek of zelfs speciaal. In gesprek met ontwikkelaars, ik heb ontdekt dat het is gewoon een goede analoog voor het groeiende aantal en de diversiteit van use cases ontwikkelaars zien. Vanuit mijn perspectief is het fundamentele leren van Polyglot Persistentie de noodzaak om het juiste datamodel te gebruiken voor de juiste baan. En met innovaties in databasetechnologie kunnen we meer dan één in dezelfde database-engine hebben. Anders moeten we erkennen dat Polyglot volharding zijn eigen compromis is dat ons beperkt en ons uiteindelijk achter onze concurrenten zal plaatsen.

over de auteur: Max Neunhoeffer is senior developer en architect bij ArangoDB. In zijn academische carrière werkte hij 16 jaar aan de ontwikkeling en implementatie van nieuwe algoritmen in de computeralgebra. Enkele jaren geleden heeft hij zijn focus verlegd naar NoSQL databases. Bij ArangoDB is hij verantwoordelijk voor” alles gedistribueerd”, inclusief inzet op Kubernetes, maar ook veerkracht, failover en schaalbaarheid. Zijn bijzondere interesses zijn gedistribueerde transacties, zelfgenezende gedistribueerde systemen en performance tuning. Als zijn dagen 48 uur hadden, zou hij golfen, zeilen, piano spelen en een nieuwe programmeertaal uitvinden.

Tags: ArangoDB, graph, json, key-value, multi-model database, polyglot, Polyglot persistentie, relationeel

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.