Ik weet zeker dat je dit zag aankomen, "Het hangt ervan af".
Het hangt van alles af. En de oplossing voor het delen van klantgegevens voor afdeling A kan compleet anders zijn voor het delen van klantgegevens met afdeling B.
Mijn favoriete concept dat in de loop der jaren is ontstaan, is het concept van "Eventuele Consistentie". De term kwam van Amazon en sprak over gedistribueerde systemen.
Het uitgangspunt is dat hoewel de staat van gegevens in een gedistribueerde onderneming nu misschien niet perfect consistent is, dit "uiteindelijk" wel zal zijn.
Wanneer een klantrecord bijvoorbeeld wordt bijgewerkt op systeem A, zijn de klantgegevens van systeem B nu verouderd en komen ze niet overeen. Maar "uiteindelijk" zal het record van A via een of ander proces naar B worden verzonden. Dus uiteindelijk zullen de twee instanties overeenkomen.
Als je met één systeem werkt, heb je geen "EC", maar heb je directe updates, een enkele "bron van waarheid" en, typisch, een vergrendelingsmechanisme om race-omstandigheden en conflicten af te handelen.
Hoe beter uw bedrijf met "EC"-gegevens kan werken, hoe gemakkelijker het is om deze systemen te scheiden. Een eenvoudig voorbeeld is een datawarehouse dat door sales wordt gebruikt. Ze gebruiken de DW om hun dagelijkse rapporten uit te voeren, maar ze voeren hun rapporten pas in de vroege ochtend uit en ze kijken altijd naar de gegevens van 'gisteren' (of eerder). Het is dus niet nodig dat de DW in realtime perfect in overeenstemming is met het dagelijkse operationele systeem. Het is volkomen acceptabel dat een proces bijvoorbeeld aan het einde van de werkdag wordt uitgevoerd en de transacties en activiteiten van de dag massaal doorloopt in een grote, enkele update-operatie.
U kunt zien hoe deze vereiste veel problemen kan oplossen. Er is geen betwisting voor de transactiegegevens, geen zorgen dat sommige rapportgegevens zullen veranderen in het midden van het verzamelen van de statistiek, omdat het rapport twee afzonderlijke zoekopdrachten naar de live database deed. Het is niet nodig dat de gedetailleerde chatter gedurende de dag netwerk- en cpu-verwerking, enz. opzuigt.
Dat is een extreem, vereenvoudigd en heel grof voorbeeld van EC.
Maar denk eens aan een groot systeem als Google. Als consument van Zoeken hebben we geen idee wanneer of hoe lang het duurt voordat een zoekresultaat dat Google verzamelt, op een zoekpagina staat. 1ms? 1s? 10s? 10 uur? Het is gemakkelijk om je voor te stellen hoe als je Googles West Coast-servers bereikt, je heel goed een ander zoekresultaat krijgt dan wanneer je hun East Coast-servers bereikt. Op geen enkel moment zijn deze twee gevallen volledig consistent. Maar over het algemeen zijn ze meestal consistent. En voor hun gebruik worden hun consumenten niet echt beïnvloed door de vertraging en vertraging.
Denk aan e-mail. A wil een bericht naar B sturen, maar in het proces wordt het bericht door systeem C, D en E gerouteerd. Elk systeem accepteert het bericht, neemt er de volledige verantwoordelijkheid voor en geeft het vervolgens door aan een ander. De afzender ziet de e-mail onderweg zijn. De ontvanger mist het niet echt omdat ze niet per se weten dat het eraan komt. Er is dus een grote tijdspanne die het bericht kan vergen om door het systeem te gaan zonder dat iemand zich zorgen maakt over hoe snel het is.
Aan de andere kant had A met B aan de telefoon kunnen zijn. "Ik heb het net verzonden, heb je het al ontvangen? Nu? Nu? Nu ontvangen?"
Er is dus een soort onderliggend, impliciet niveau van prestaties en respons. Uiteindelijk komt "uiteindelijk" de outbox van A overeen met de inbox van B.
Deze vertragingen, de acceptatie van verouderde gegevens, of deze nu een dag oud zijn of 1-5 seconden oud, bepalen de uiteindelijke koppeling van uw systemen. Hoe losser deze eis, hoe losser de koppeling en hoe meer flexibiliteit je tot je beschikking hebt qua ontwerp.
Dit geldt tot in de kernen in je CPU. Moderne, multi-core, multi-threaded applicaties die op hetzelfde systeem draaien, kunnen verschillende weergaven van "dezelfde" gegevens hebben, slechts enkele microseconden verouderd. Als uw code correct kan werken met gegevens die mogelijk niet met elkaar in overeenstemming zijn, dan is het een gelukkige dag. Als dat niet het geval is, moet u speciale aandacht besteden om ervoor te zorgen dat uw gegevens volledig consistent zijn, met behulp van technieken zoals vluchtige geheugenkwalificaties of vergrendelingsconstructies, enz. Die op hun manier allemaal de prestaties kosten.
Dit is dus de basisoverweging. Alle andere beslissingen beginnen hier. Als u dit beantwoordt, kunt u zien hoe u toepassingen op verschillende machines kunt partitioneren, welke bronnen worden gedeeld en hoe ze worden gedeeld. Welke protocollen en technieken zijn beschikbaar om de gegevens te verplaatsen en hoeveel het gaat kosten in termen van verwerking om de overdracht uit te voeren. Replicatie, load balancing, datashares, etc. etc. Allemaal gebaseerd op dit concept.
Bewerken, als reactie op de eerste opmerking.
Juist, precies. Het spel hier, bijvoorbeeld, als B klantgegevens niet kan wijzigen, wat is dan het kwaad met gewijzigde klantgegevens? Kunt u "het risico lopen" dat het voor een korte tijd verouderd is? Misschien komen uw klantgegevens langzaam genoeg binnen om deze direct van A naar B te repliceren. Stel dat de wijziging in een wachtrij wordt geplaatst die, vanwege het lage volume, gemakkelijk wordt opgepikt (<1s), maar zelfs dan zou het "uit transactie" zijn met de oorspronkelijke wijziging, en er is dus een klein venster waar A zou hebben gegevens die B niet heeft.
Nu begint de geest echt te draaien. Wat gebeurt er tijdens die 1s van "lag", wat is het slechtst mogelijke scenario. En kun je er omheen bouwen? Als je een vertraging van 1 seconde kunt engineeren, kun je misschien een vertraging van ongeveer 5s, 1 meter of zelfs langer maken. Hoeveel van de klantgegevens gebruikt u daadwerkelijk op B? Misschien is B een systeem dat is ontworpen om het orderpicken uit de voorraad te vergemakkelijken. Het is moeilijk voor te stellen dat er meer nodig is dan alleen een klant-ID en misschien een naam. Gewoon iets om grofweg te identificeren voor wie de bestelling is terwijl deze wordt geassembleerd.
Het orderverzamelsysteem hoeft niet per se alle klantinformatie af te drukken tot het einde van het orderverzamelproces, en tegen die tijd kan de bestelling zijn verplaatst naar een ander systeem dat misschien meer actueel is met vooral verzendinformatie, dus uiteindelijk heeft het orderverzamelsysteem nauwelijks klantgegevens nodig. In feite zou u de klantinformatie in de orderverzamelopdracht kunnen EMBED en denormaliseren, zodat er geen noodzaak of verwachting is om later te synchroniseren. Zolang de klant-ID correct is (die sowieso nooit zal veranderen) en de naam (die zo zelden verandert dat het niet de moeite waard is om te bespreken), is dat de enige echte referentie die u nodig hebt, en al uw pick-slips zijn perfect nauwkeurig op het moment van creatie.
De truc is de mentaliteit, om de systemen op te splitsen en je te concentreren op de essentiële gegevens die nodig zijn voor de taak. Gegevens die u niet nodig hebt, hoeven niet te worden gerepliceerd of gesynchroniseerd. Mensen ergeren zich aan zaken als denormalisatie en datareductie, vooral als ze uit de relationele datamodelleringswereld komen. En terecht, het moet met de nodige voorzichtigheid worden overwogen. Maar als je eenmaal gedistribueerd bent, ben je impliciet gedenormaliseerd. Verdorie, je kopieert het nu in het groot. Dus je kunt er net zo goed slimmer in zijn.
Dit alles kan worden beperkt door solide procedures en een grondig begrip van de workflow. Identificeer de risico's en werk beleid en procedures uit om ze aan te pakken.
Maar het moeilijkste is om in het begin de keten naar de centrale database te doorbreken en mensen te instrueren dat ze niet "alles kunnen hebben" zoals ze zouden verwachten als je een enkele, centrale, perfecte opslag van informatie hebt.