Predmemorija odgovara na pitanje koje je sustav već vidio. Prediktivna baza podataka pokušava učiniti sljedeći koristan odgovor jeftinim prije nego što pitanje stigne.

Ta je razlika važna kada aplikacija preraste nekoliko jednostavnih čitanja. Katalozi proizvoda trebaju rangiranje, nadzorne ploče trebaju sažetke, alati za podršku trebaju kontekst, a API-ji trebaju vraćati korisne zadane vrijednosti bez pretvaranja svakog zahtjeva u lanac skupih spajanja. Predmemoriranje i dalje je vrijedno, ali je po dizajnu reaktivno. Pohranjuje prošlost. Prediktivni dizajn podataka pretvara poznate obrasce, namjeru korisnika i događaje u domeni u strukture podataka koje vjerojatan budući rad čine brzim i pouzdanim.

Cilj nije učiniti bazu podataka „inteligentnom” nejasnom automatizacijom. Cilj je projektirati eksplicitne projekcije: pažljivo održavane prikaze podataka oblikovane oko odluka koje će korisnici vjerojatno sljedeće donijeti.

Započnite sljedećim pitanjem, a ne sljedećim upitom

Tradicionalni dizajn sheme često počinje entitetima: korisnicima, narudžbama, proizvodima, računima. To je nužno, ali nije dovoljno za sustave osjetljive na performanse. Operativne tablice čuvaju istinu i podržavaju ispravna pisanja. Rijetko su idealan oblik za svako čitanje.

Korisnije je pitanje dizajna: što će ova osoba ili usluga najvjerojatnije zatražiti nakon ovog događaja?

Razmotrite slanje narudžbe. Primarno pisanje pripada normaliziranim transakcijskim tablicama. No događaj može predvidjeti i nekoliko skorašnjih čitanja:

• Kupac može otvoriti povijest svojih narudžbi.
• Skladišni radnik može trebati red za ispunjenje narudžbi.
• Agent podrške može trebati sažetu vremensku crtu kupca.
• Analitički zaslon može trebati ažurirane dnevne ukupne iznose.
• Usluzi preporuka mogu trebati najnoviji signali o kupnji.

Pokušaj zadovoljavanja svega toga istim normaliziranim putem upita stvara sustav koji je tehnički ispravan, ali sve skuplji za rad. Umjesto toga, sačuvajte transakciju kao izvor istine i izgradite modele čitanja za rad koji slijedi nakon nje.

Koristite projekcije kao sastavne dijelove pozadinskog sustava prvog reda

Projekcija je izvedeni prikaz podataka optimiziran za određeno čitanje. Može biti sažetna tablica, materijalizirani pogled gdje ga baza podataka podržava, indeks pretraživanja ili dokument sastavljen za API odgovor. Važan je dio vlasništvo: projekcija treba imati jasnu svrhu, ulaze, pravila ažuriranja i očekivanje svježine.

Primjerice, krajnja točka pregleda računa ne bi nužno trebala pri svakom zahtjevu izračunavati ukupnu potrošnju tijekom vremena, broj otvorenih računa, posljednju aktivnost i status računa iz sirovih tablica. Namjenski sažeti red može učiniti uobičajeni put predvidljivim:

CREATE TABLE account_overview (
    account_id BIGINT PRIMARY KEY,
    lifetime_spend DECIMAL(12, 2) NOT NULL DEFAULT 0,
    open_invoice_count INT NOT NULL DEFAULT 0,
    last_activity_at TIMESTAMP NULL,
    updated_at TIMESTAMP NOT NULL
);

Ova tablica nije zamjena za račune ili plaćanja. To je model čitanja. Njezine vrijednosti moraju biti izvedive iz mjerodavnih podataka, a put ažuriranja mora biti namjerno osmišljen.

Odaberite način ažuriranja projekcija

Postoje tri uobičajena pristupa, svaki s različitim karakteristikama kvara.

• Sinkrona ažuriranja zapisuju transakciju i projekciju u istom zahtjevu. Omogućuju trenutačnu konzistentnost, ali povećavaju složenost i latenciju puta pisanja.
• Asinkroni potrošači obrađuju trajne događaje ili tablicu izlaznih događaja nakon potvrde transakcije. Štite put zahtjeva i dobro se skaliraju, ali korisničko sučelje mora tolerirati kratkotrajnu zastarjelost.
• Planirane ponovne izgradnje ponovno izračunavaju podatke u skupinama. Jednostavne su za izvješća niske hitnosti, ali neprikladne tamo gdje korisnici očekuju trenutačne promjene.

Za mnoge PHP aplikacije, obrazac izlazne pošte pragmatična je sredina. Potvrdite poslovnu promjenu i mali zapis događaja u jednoj transakciji baze podataka. Radnik zatim čita neobrađene događaje i ažurira projekcije. Time se izbjegava tvrdnja da je događaj objavljen kada je odgovarajuća transakcija baze podataka neuspjela.

$pdo->beginTransaction();

try {
    $statement = $pdo->prepare(
        'INSERT INTO orders (customer_id, total_amount, status)
         VALUES (:customer_id, :total_amount, :status)'
    );
    $statement->execute($orderData);

    $event = $pdo->prepare(
        'INSERT INTO outbox_events (type, payload, created_at)
         VALUES (:type, :payload, NOW())'
    );
    $event->execute([
        'type' => 'order.placed',
        'payload' => json_encode(['customer_id' => $orderData['customer_id']]),
    ]);

    $pdo->commit();
} catch (Throwable $exception) {
    $pdo->rollBack();
    throw $exception;
}

Radnik mora biti idempotentan. Može primiti isti događaj dvaput nakon ponovnog pokušaja, stoga se ažuriranja projekcije trebaju sigurno konvergirati. Jedinstveni zapis o obrađenom događaju, monotona verzija ili atomski upsert mogu pružiti tu zaštitu. Isporuka „barem jednom” je upravljiva; tiho dvostruko brojanje novca nije.

Predviđanje je često jednostavnije od strojnog učenja

Riječ prediktivno može upućivati na model, spremište značajki i neprozirni proces bodovanja. To može biti prikladno, ali većina dobitaka u pozadinskim sustavima počinje običnim ponašanjem proizvoda. Nedavna aktivnost predviđa sljedeći zaslon. Promjena stanja predviđa sljedeći operativni zadatak. Često traženi filtar predviđa koristan indeks ili unaprijed izračunati broj faceta.

Prije dodavanja sofisticiranih modela, instrumentirajte stvarne obrasce pristupa. Tražite ponavljane kombinacije filtara, skupe agregate i slijedove zahtjeva. Ako korisnici koji pregledavaju račun često zatim otvore njegove račune, unaprijed dohvaćanje ograničenog sažetka računa može biti opravdano. Ako to čine ponekad, predmemorija može biti dovoljna. Ako je put rijedak ili je teret velik, ne činite ni jedno ni drugo.

Predviđanje treba smanjiti rad, a ne premjestiti ga negdje gdje je manje vidljiv. Svako izvedeno spremište stvara trošak: pohranu, koordinaciju implementacije, popunjavanje povijesnih podataka, nadzor, pregled privatnosti i operativno vlasništvo.

Očuvajte mogućnost oporavka izvora istine

Izvedeni podaci sigurni su samo kada se mogu popraviti. Ugradite tu pretpostavku u arhitekturu od samog početka.

• Pohranjujte mjerodavne transakcijske zapise neovisno od projekcija.
• Verzionirajte sadržaje događaja i logiku projekcije kako se ugovori razvijaju.
• Omogućite ograničen proces ponovne izgradnje za zakupca, račun ili datumski raspon.
• Pratite zaostajanje projekcije i neuspjele događaje kao operativne signale.
• U sučeljima učinite svježinu vidljivom kada bi zastarjeli podaci mogli dovesti korisnike u zabludu.

Potpuna ponovna izgradnja nije samo značajka oporavka od katastrofe. Ona je test dizajna. Ako ponovna izgradnja projekcije zahtijeva nedokumentirane ručne korake ili nepovrativ povijesni kontekst, projekcija je postala skriveni izvor istine.

Uvodite promjene u fazama

Prediktivne strukture podataka zahtijevaju više pažnje nego dodavanje ključa predmemorije. Primijenite pristup proširi pa smanji. Najprije uvedite novu tablicu, stupac, potrošača ili indeks bez ovisnosti o njemu. Popunite povijesne podatke. Provjerite brojanja i reprezentativne zapise u odnosu na izvorne tablice. Zatim postupno prebacujte čitanja, pratite latenciju i ispravnost te tek kasnije uklonite zastarjele putove.

U implementacijama temeljenima na Dockeru to obično znači da migracije i jednokratni poslovi popunjavanja povijesnih podataka moraju biti odvojeni od dugotrajnih aplikacijskih spremnika. Web-proces ne bi trebao tijekom pokretanja ponovno izgraditi milijune redaka, a neuspjelo ponovno pokretanje ne bi trebalo ponoviti neograničenu migraciju. Učinite posao eksplicitnim, nastavljivim i vidljivim za nadzor.

Baza podataka postaje površina proizvoda

Dobro projektirane prediktivne baze podataka ne nagađaju nepromišljeno. One kodiraju informirana očekivanja o tome što korisnici i sustavi trebaju sljedeće, uz zadržavanje mogućnosti ispravljanja, ponavljanja i pojednostavljivanja.

To je trajna pouka izvan predmemorije: performanse nisu samo pohranjivanje prethodnih odgovora. Riječ je o oblikovanju pouzdanih podataka oko sljedećeg smislenog pitanja — i tretiranju svakog prečaca kao održavanog dijela proizvoda.