Na ovoj stranici
Zamislite ekran podrške kome treba samo jedan odgovor: da li je ova porudžbina plaćena? Sistem za plaćanja zna odgovor. Tim za integracije predlaže da se svaki zapis o plaćanju kopira u drugu bazu, da se kopija stalno ažurira i čita kada agent otvori porudžbinu. Ovo je hipotetički operativni primer, a ne analitički slučaj prikazan u navedenoj demonstraciji.
Možda je kopija potrebna. Ali prvo pitajte da li ekranu sada treba samo jedan odgovor za koji ima dozvolu.
Tehnička demonstracija analitičkih upita između oblaka prikazuje upit nad postojećim izvorima bez prethodnog pravljenja trajne kopije izvorne tabele na odredištu. Ista demonstracija materijalizuje spojenu tabelu, pa pokazuje da udaljeni pristup i kopiranje mogu postojati u istom toku rada. To je stvarna mogućnost proizvoda, a ne obećanje da je usluga za analitičke upite pogodna za operativni ekran statusa plaćanja ili da podaci nikada ne putuju tokom izvršavanja. Dokumentacija Google Cloud o federativnim upitima objašnjava da se neki rezultati spoljašnjih upita privremeno prenose u uslugu za upite. Bitna je razlika između trajne sinhronizovane replike i ograničenog čitanja radi određenog pitanja.
Pođite od posla korisničkog sistema
U zahtevu „povežite ove sisteme“ kriju se dva različita zahteva. Jedan pita: „Šta izvor kaže sada?“ Drugi pita: „Koje stanje odredište mora čuvati da bi moglo delovati kasnije?“
Ekranu podrške ograničeno čitanje može vratiti status porudžbine i vreme kada je posmatran. Izvor ostaje merodavan. Ako izvor ne radi, ekran treba da kaže da trenutni status nije dostupan ili jasno označi keširani odgovor. Druga kopija stvorila bi novo pitanje: koji status važi kada se dva sistema ne slažu?
Korisnički sistem traži jedan aktuelan odgovor iz izvora kroz dozvoljen i ograničen upit; tokom obrade mogu se prenositi privremeni podaci bez stvaranja trajne replike.
Za kampanju napuštene korpe odredište možda mora da deluje bez otvaranja ekrana. Možda su mu potrebni blagovremen događaj, stanje pristanka i način da otkaže zakazanu poruku posle kupovine. Čitanje uživo u trenutku kampanje i dalje može pomoći, ali odgovor na zahtev nije ceo posao.
| Šta korisničkom sistemu treba | Prvi pristup koji treba isprobati | Glavni kompromis |
|---|---|---|
| Jedan aktuelan odgovor | Ograničen upit vlasniku podataka | Zavisi od pristupa izvoru i kašnjenja |
| Stalna radnja pri promeni | Događaj ili minimalna sinhronizacija promena | Mora obraditi kašnjenje, duplikate i propuštene događaje |
| Istorijski dokaz za odluku | Verzije snimka bitnih polja | Treba urediti čuvanje i pristup |
| Rad dok izvor nije dostupan | Izričit keš ili replika | Može zastareti; treba pravilo o starosti |
Ovo je tabela za odlučivanje, a ne poređenje performansi. Iz nje ne sledi univerzalna granica kada birati upit, a kada kopiju.
Kopija ima trajni trošak
Prvi izvoz lako je potceniti jer se završi. Kopija nastavlja da živi. Pojavi se novo polje, identifikatori se spoje, dozvola se promeni ili stari događaj stigne posle novog. Odredište tada može čuvati odgovor koji bi izvor odbacio.
Trošak nije samo prostor za čuvanje. Tu je i usklađivanje: praćenje zaostatka, ponavljanje propuštenih promena, brisanje podataka kada je obavezno i objašnjavanje zašto je odluka doneta prema jučerašnjoj vrednosti. Ti zadaci su opravdani kada odredištu treba nezavisno stanje. Suvišni su kada je jedini cilj aktuelan odgovor.
I upit košta. Može opteretiti izvor, izložiti polja drugom nosiocu pristupa, preći mrežnu granicu i zakazati u najgorem trenutku. Planer upita može obraditi više podataka nego što vidljivi rezultat nagoveštava. Dokumentacija o federaciji opisuje detalje izvršavanja koje treba proveriti pre nego što udaljeni upit proglasite prenosom bez podataka.
Bezbedan upit ima usku svrhu i uski rezultat. Imenujte vlasnika polja. Ograničite dozvolu pozivaoca. Odlučite koliko odgovor sme biti star, koliko upit sme trajati i šta interfejs kaže pri isteku vremena. Sačuvajte vreme posmatranja uz odgovor.
Kada se kontrolisana kopija isplati
„Lokalni podaci daju nam predvidljiv interfejs i manje udaljenih kvarova.“ To je ozbiljan argument. Ako tok rada ima strogo ograničenje kašnjenja ili mora nastaviti tokom prekida izvora, kontrolisana replika može biti pravi izbor.
Presudna reč je kontrolisana. Odredite koja se polja kopiraju, koliko brzo moraju da se ažuriraju, šta se događa kada ažuriranje stane i kada korisnički sistem odbija da deluje prema zastarelom stanju. Proverite i zakasnelu ispravku, ne samo idealan tok. Brz zastareo odgovor može biti gori od jasne poruke da odgovor nije dostupan.
Počnite od najmanjeg pitanja koje korisnički sistem postavlja. Ako ga čitanje rešava, neka izvor ostane merodavan. Ako radnja zahteva lokalno stanje, kopirajte samo ono što radnja opravdava.
Mali ogled može rešiti izbor bez gradnje opšteg sloja za replikaciju. Odaberite jedno stvarno pitanje, zabeležite koliko svež odgovor mora biti i pokrenite dozvoljen upit nad izvorom. Posmatrajte kašnjenje, opterećenje izvora i kvarove uz stvarna ograničenja pristupa. Zatim isprobajte najuži skup kopiranih podataka koji bi zadovoljio isti sistem. Uporedite ne samo brzinu odgovora, već i ispravke, brisanje i ponašanje pri prekidu. Vodič za planiranje integracije daje širi kontekst; ogled bira gde odgovor treba da živi. Nijedan put nije automatski jeftiniji kada uračunate trajno održavanje.
Veza se ne meri brojem redova koji su je prešli.
Često Postavljana Pitanja
Kada je udaljeni upit bolji od sinhronizacije?
Kada pozivaocu treba odgovor iz merodavnog izvora i može da prihvati dostupnost i kašnjenje tog izvora. Ograničite pristup i prikažite kada je odgovor pročitan.
Kada podaci ipak moraju da se kopiraju?
Kopirajte najmanji potreban skup stanja kada drugi sistem mora da deluje bez upita uživo, čuva proverljiv snimak ili ispuni zahtev za brzinom ili dostupnošću koji izvor ne može da ispuni.
Znači li upit na mestu da podaci nikada ne putuju?
Ne. Federativna usluga može preneti privremene podatke ili rezultate radi izvršavanja upita. Proverite dokumentovano izvršavanje, čuvanje i bezbednost konkretnog pružaoca.