Jsem si jistý, že jste viděli, jak přichází toto:„Záleží“.
Záleží na všem. A řešení sdílení zákaznických dat pro oddělení A může být zcela odlišné pro sdílení zákaznických dat s oddělením B.
Mým oblíbeným konceptem, který se v průběhu let prosadil, je koncept „Eventual Consistency“. Termín přišel z Amazonu, který hovořil o distribuovaných systémech.
Předpokladem je, že zatímco stav dat v distribuovaném podniku nemusí být nyní dokonale konzistentní, "nakonec" bude.
Když se například aktualizuje záznam zákazníka v systému A, data zákazníka systému B jsou nyní zastaralá a neodpovídající. Ale "nakonec" bude záznam z A odeslán do B prostřednictvím nějakého procesu. Nakonec se tedy tyto dva případy budou shodovat.
Když pracujete s jedním systémem, nemáte „EC“, ale máte okamžité aktualizace, jediný „zdroj pravdy“ a obvykle zamykací mechanismus pro řešení rasových podmínek a konfliktů.
Čím schopnější jsou vaše provozy schopné pracovat s „EC“ daty, tím snazší je tyto systémy oddělit. Jednoduchým příkladem je datový sklad používaný prodejem. Používají DW ke spouštění svých denních reportů, ale své reporty nespouštějí až do časného rána a vždy se dívají na „včerejší“ (nebo dřívější) data. Není tedy potřeba, aby byl DW v reálném čase dokonale konzistentní s každodenním operačním systémem. Je naprosto přijatelné, aby proces běžel, řekněme, u konce obchodní činnosti a aby se transakce a aktivity přesouvaly v průběhu dnů hromadně v rámci jedné velké operace s jedinou aktualizací.
Můžete vidět, jak tento požadavek může vyřešit spoustu problémů. Neexistuje žádný spor o transakční data, žádné obavy, že se některá data sestav změní uprostřed shromažďování statistik, protože sestava provedla dva samostatné dotazy na živou databázi. Není třeba, aby štěbetání s vysokými detaily během dne vysálo síť a zpracování procesoru atd.
To je extrémní, zjednodušený a velmi hrubý příklad EC.
Ale zvažte velký systém, jako je Google. Jako spotřebitel Vyhledávání nemáme ponětí, kdy nebo jak dlouho trvá, než Google sklidí výsledek vyhledávání, až se dostane na stránku vyhledávání. 1 ms? 1s? 10s? 10 hodin? Je snadné si představit, že když narazíte na servery západního pobřeží společnosti Google, můžete velmi dobře získat jiný výsledek vyhledávání, než když zasáhnete jejich servery na východním pobřeží. V žádném bodě nejsou tyto dva případy zcela konzistentní. Ale do značné míry jsou většinou konzistentní. A pokud jde o případ použití, jejich spotřebitelé nejsou zpožděním a zpožděním skutečně ovlivněni.
Zvažte e-mail. A chce poslat zprávu B, ale v tomto procesu je zpráva směrována přes systém C, D a E. Každý systém zprávu přijme, převezme za ni plnou odpovědnost a pak ji předá jinému. Odesílatel vidí, že e-mail pokračuje svou cestou. Přijímač to opravdu nemine, protože nemusí nutně vědět, že přichází. Existuje tedy velké časové okno, které může trvat, než tato zpráva projde systémem, aniž by kdokoli věděl nebo se staral o to, jak je rychlá.
Na druhou stranu A mohl telefonovat s B. "Právě jsem to poslal, už jsi to dostal? Teď? Teď? Získat to hned?"
Existuje tedy nějaký druh základní, implikované úrovně výkonu a odezvy. Nakonec, "nakonec", pošta k odeslání A odpovídá doručené poště B.
Tato zpoždění, přijímání zastaralých dat, ať už jsou stará den nebo 1-5 s, jsou tím, co řídí konečné propojení vašich systémů. Čím volnější je tento požadavek, tím volnější je spojka a tím větší flexibilitu máte z hlediska designu k dispozici.
To platí až k jádrům ve vašem CPU. Moderní, vícejádrové a vícevláknové aplikace běžící na stejném systému mohou mít různé pohledy na „stejná“ data, pouze mikrosekundy zastaralé. Pokud váš kód může správně pracovat s daty, která mohou být vzájemně nekonzistentní, pak šťastný den, jde to. Pokud ne, musíte věnovat zvláštní pozornost tomu, abyste zajistili, že jsou vaše data zcela konzistentní, pomocí technik, jako jsou kvalifikace nestálé paměti nebo zamykací konstrukce atd. To vše svým způsobem stojí výkon.
Takže toto je základní úvaha. Všechna ostatní rozhodnutí začínají zde. Odpověď vám může říci, jak rozdělit aplikace mezi počítače, jaké prostředky jsou sdíleny a jak jsou sdíleny. Jaké protokoly a techniky jsou k dispozici pro přesun dat a kolik to bude stát z hlediska zpracování provedení přenosu. Replikace, vyvažování zátěže, sdílení dat atd. atd. To vše je založeno na tomto konceptu.
Upravit v reakci na první komentář.
Správně, přesně. Hra zde, například, když B nemůže změnit údaje o zákaznících, jaká je škoda se změněnými údaji o zákaznících? Můžete „riskovat“, že bude krátkodobě neaktuální? Možná vaše zákaznická data přicházejí dostatečně pomalu, abyste je mohli okamžitě replikovat z A do B. Řekněme, že změna je umístěna do fronty, která je kvůli nízkému objemu snadno vyzvednuta (<1 s), ale i přesto by byla „mimo transakce“ s původní změnou, takže existuje malé okno, kde by A data, která B nemá.
Teď se mysl opravdu začne točit. Co se stane během těch 1s "lagu", jaký je nejhorší možný scénář. A umíš to řídit? Pokud dokážete navrhnout zpoždění kolem 1 s, můžete být schopni navrhnout zpoždění kolem 5 s, 1 m nebo ještě delší. Kolik zákaznických dat skutečně používáte na B? Možná B je systém navržený tak, aby usnadnil vychystávání objednávek ze skladu. Těžko si představit, že by bylo potřeba něco víc než pouhé ID zákazníka a možná i jméno. Jen něco pro hrubou identifikaci, pro koho je objednávka při sestavování.
Vychystávací systém nemusí nutně vytisknout všechny informace o zákazníkovi až do úplného konce vychystávacího procesu a do té doby může být objednávka přesunuta do jiného systému, který je možná aktuálnější, zejména s informacemi o přepravě, takže vychystávací systém nakonec nepotřebuje téměř žádná zákaznická data. Ve skutečnosti byste mohli VLOŽIT a denormalizovat informace o zákaznících v rámci objednávky vychystávání, takže není potřeba ani očekávat pozdější synchronizaci. Pokud je správné číslo zákazníka (které se stejně nikdy nezmění) a jméno (které se mění tak zřídka, že nemá cenu o něm diskutovat), je to jediná skutečná reference, kterou potřebujete, a všechny vaše dodací listy jsou v době dodání naprosto přesné. vytvoření.
Trik je v myšlení, rozbití systémů a zaměření se na základní data, která jsou pro daný úkol nezbytná. Data, která nepotřebujete, není třeba replikovat ani synchronizovat. Lidé se rozčilují nad věcmi, jako je denormalizace a redukce dat, zvláště když jsou ze světa relačního datového modelování. A z dobrého důvodu by to mělo být zvažováno opatrně. Ale jakmile se dostanete do distribuce, implicitně jste denormalizovali. Sakra, teď to kopíruješ velkoobchodně. Takže na to můžete být chytřejší.
To vše lze zmírnit pevnými postupy a důkladným pochopením pracovního postupu. Identifikujte rizika a vypracujte zásady a postupy pro jejich zvládnutí.
Ale nejtěžší je hned na začátku přerušit řetěz k centrální DB a poučit lidi, že nemohou „mít všechno“, jak mohou očekávat, když máte jediné, centrální, dokonalé úložiště informací.