Na tejto stránke
Predstavte si obrazovku podpory, ktorá potrebuje jednu odpoveď: bola táto objednávka zaplatená? Odpoveď má platobný systém. Integračný tím navrhne skopírovať všetky platobné záznamy do druhej databázy, držať kópiu aktuálnu a čítať ju pri otvorení objednávky agentom. Ide o hypotetický prevádzkový príklad, nie analytický prípad zo zdrojovej ukážky.
Možno je to nutné. Najprv sa opýtajte, či obrazovka teraz potrebuje iba jednu povolenú odpoveď.
Technická ukážka analytických dotazov naprieč cloudmi zobrazuje dotaz nad existujúcimi zdrojmi dát bez predchádzajúceho vytvorenia trvalej kópie zdrojovej tabuľky v cieli. Tá istá ukážka vytvorí aj materializovanú spojenú tabuľku, takže vzdialený prístup a kopírovanie môžu byť súčasťou jedného postupu. Je to skutočná schopnosť produktu, nie prísľub, že analytická dotazovacia služba sa hodí pre prevádzkovú obrazovku platby alebo že sa pri vykonaní dáta vôbec nehýbu. Dokumentácia Google Cloud k federovaným dotazom vysvetľuje, že niektoré výsledky vonkajších dotazov sa dočasne presunú do dotazovacej služby. Dôležitý je rozdiel medzi trvalou synchronizovanou replikou a ohraničeným čítaním kvôli jednej otázke.
Rozhodujte podľa úlohy príjemcu
V požiadavke „prepojte tieto systémy“ sa skrývajú dve rôzne potreby. Jedna sa pýta: „Čo hovorí zdroj teraz?“ Druhá: „Aký stav musí cieľ držať, aby mohol neskôr konať?“
Pre obrazovku podpory môže čítanie s obmedzeným rozsahom vrátiť stav objednávky a čas jeho zistenia. Zdroj zostáva autoritou. Ak je nedostupný, obrazovka má oznámiť, že aktuálny stav nie je dostupný, alebo jasne označiť uloženú staršiu odpoveď. Druhá kópia by vytvorila novú otázku: ktorý stav platí, keď sa nezhodujú?
Príjemca žiada zdroj o jednu aktuálnu odpoveď cez oprávnený dotaz; ten môže spracovať dočasné dáta bez vytvorenia trvalej repliky.
Pri kampani na opustený košík môže cieľ potrebovať konať bez toho, aby niekto otvoril obrazovku. Môže potrebovať včasnú udalosť, stav súhlasu a spôsob zrušenia čakajúcej správy po nákupe. Živé čítanie v čase kampane môže stále pomôcť, ale odpoveď na požiadanie nie je celou úlohou.
| Potreba príjemcu | Prvý návrh na test | Hlavný kompromis |
|---|---|---|
| Jedna aktuálna odpoveď | Ohraničený dotaz k vlastníkovi | Závisí od prístupu k zdroju a jeho odozvy |
| Priebežný krok pri zmene | Udalosť alebo minimálna rozdielová synchronizácia | Musí riešiť oneskorenie, duplicity a zmeškané udalosti |
| Historický dôkaz rozhodnutia | Verziovaná snímka relevantných polí | Treba riadiť uchovávanie a prístup |
| Fungovanie pri výpadku zdroja | Výslovná vyrovnávacia pamäť alebo replika | Môže zastarať; potrebuje pravidlo veku |
Toto je rozhodovacia tabuľka, nie benchmark. Nevyplýva z nej univerzálna hranica medzi dotazom a kopírovaním.
Kópia má priebežnú cenu
Prvú extrakciu ľahko podceníme, pretože sa skončí. Kópia však žije ďalej. Pribudne pole, identifikátor sa zlúči, zmení sa oprávnenie alebo stará udalosť príde po novej. Cieľ teraz môže držať odpoveď, ktorú by zdroj odmietol.
Cena nie je len úložisko. Je ňou zosúlaďovanie: sledovanie oneskorenia, opätovné spracovanie zmeškaných zmien, mazanie dát podľa pravidiel a vysvetlenie, prečo rozhodnutie použilo včerajšiu hodnotu. Tieto úlohy sú opodstatnené, keď cieľ potrebuje samostatný stav. Sú zbytočným triedením, keď jediným výsledkom má byť aktuálna odpoveď.
Aj dotaz má náklady. Môže zaťažiť zdroj, odhaliť polia ďalšiemu subjektu, prekročiť sieťovú hranicu a zlyhať v najhoršej chvíli. Plánovače dotazov môžu spracovať viac dát, než naznačuje viditeľný výsledok. Dokumentácia federácie opisuje detaily vykonania, ktoré treba skontrolovať skôr, než vzdialený dotaz označíte za nulový prenos.
Bezpečný dotaz má úzky účel a malý výsledok. Pomenujte vlastníka poľa. Obmedzte oprávnenie volajúceho. Rozhodnite, aká stará odpoveď je prijateľná, ako dlho môže dotaz čakať a čo rozhranie oznámi pri vypršaní času. Pri odpovedi uchovajte čas zistenia.
Keď si riadená kópia zaslúži cenu
„Miestne dáta nám dajú predvídateľné rozhranie a menej vzdialených zlyhaní.“ To je vážny argument. Ak má postup prísnu požiadavku na odozvu alebo musí pokračovať cez výpadok zdroja, riadená replika môže byť správnym návrhom.
Rozhodujúce je slovo riadená. Určte kopírované polia, požadovanú rýchlosť aktualizácie, postup pri zastavení aktualizácií a chvíľu, keď príjemca odmietne konať zo zastaraného stavu. Testujte neskorú opravu aj bezproblémovú cestu. Rýchla zastaraná odpoveď môže byť horšia než viditeľná nedostupnosť.
Začnite najmenšou otázkou príjemcu. Ak ju vyrieši čítanie, nechajte zdroj rozhodovať. Ak krok potrebuje miestny stav, kopírujte len to, čo tento krok dokáže odôvodniť.
O voľbe môže rozhodnúť malá skúška bez budovania všeobecnej replikačnej vrstvy. Vyberte jednu otázku, ktorú príjemca skutočne kladie, zapíšte požadovanú aktuálnosť odpovede a vykonajte oprávnený dotaz k zdroju. Sledujte odozvu, zaťaženie zdroja a správanie pri zlyhaní so skutočnými prístupovými pravidlami. Potom skúste najmenší skopírovaný stav, ktorý by splnil tú istú potrebu. Porovnajte nielen čas odpovede, ale aj opravy, mazanie a správanie pri výpadku. Sprievodca plánovaním integrácie dáva širší kontext pracovného postupu; táto skúška vyberá, kde má odpoveď žiť. Ani jedna cesta nie je automaticky lacnejšia, keď spočítate priebežnú údržbu.
Prepojenie sa nemeria počtom riadkov, ktoré ním prešli.
Často Kladené Otázky
Kedy je vzdialený dotaz lepší než synchronizácia?
Keď volajúci potrebuje odpoveď z autoritatívneho zdroja a môže zniesť jeho dostupnosť a oneskorenie. Prístup držte v oprávnenom rozsahu a ukážte čas čítania odpovede.
Kedy treba dáta kopírovať?
Kopírujte minimálny potrebný stav, ak musí iný systém konať bez živého dotazu, uchovať auditovateľnú snímku alebo splniť požiadavku na oneskorenie či dostupnosť, ktorú zdroj nedokáže splniť.
Znamená dotazovanie na mieste, že sa dáta nikdy neprenášajú?
Nie. Federovaná služba môže pri vykonaní dotazu preniesť priebežné dáta alebo výsledok. Skontrolujte zdokumentované správanie poskytovateľa pri vykonaní, uchovávaní a ochrane.