Кешот одговара на прашање што системот веќе го видел. Предиктивната база на податоци се обидува да го направи следниот корисен одговор евтин уште пред да пристигне прашањето.

Таа разлика е важна кога една апликација ќе порасне надвор од неколку едноставни читања. На производните доводи им треба рангирање, на контролните табли им требаат резимеа, на алатките за поддршка им треба контекст, а API-јата треба да враќаат корисни стандардни вредности без секое барање да се претвори во низа скапи спојувања. Кеширањето останува вредно, но по дизајн е реактивно. Го складира минатото. Предиктивниот дизајн на податоци ги претвора познатите обрасци, намерата на корисникот и доменските настани во структури на податоци што ја прават веројатната идна работа брза и сигурна.

Целта не е базата на податоци да се направи „интелигентна“ со нејасна автоматизација. Целта е да се проектираат експлицитни проекции: внимателно одржувани погледи на податоците обликувани околу одлуките што корисниците веројатно ќе ги донесат следни.

Почнете со следното прашање, а не со следното барање

Традиционалниот дизајн на шема често започнува со ентитети: корисници, нарачки, производи, фактури. Тоа е неопходно, но не е доволно за системи чувствителни на перформанси. Оперативните табели ја зачувуваат вистината и поддржуваат точни запишувања. Ретко се идеалната форма за секое читање.

Покорисно дизајнерско прашање е: што најверојатно ќе побара ова лице или услуга по овој настан?

Разгледајте поставување на нарачка. Примарното запишување припаѓа во нормализирани трансакциски табели. Но настанот може да предвиди и неколку читања во блиска иднина:

• Клиентот може да ја отвори историјата на своите нарачки.
• На работник во магацин може да му треба редица за исполнување на нарачки.
• На агент за поддршка може да му треба концизна временска линија за клиентот.
• На аналитички екран може да му требаат ажурирани дневни вкупни износи.
• На услуга за препораки може да ѝ требаат најновите сигнали за купување.

Обидот сите овие потреби да се задоволат од истата нормализирана патека за барања создава систем кој е технички точен, но сè поскап за работење. Наместо тоа, зачувајте ја трансакцијата како извор на вистина и изградете модели за читање за работата што следува по неа.

Користете ги проекциите како првокласни компоненти на задниот дел

Проекција е изведен приказ на податоци оптимизиран за одредено читање. Таа може да биде табела со резиме, материјализиран поглед каде што базата на податоци го поддржува тоа, индекс за пребарување или документ составен за API одговор. Важен е делот со сопственоста: проекцијата треба да има јасна намена, влезови, правила за ажурирање и очекување за свежина.

На пример, крајната точка за преглед на сметка не мора нужно при секое барање да ги пресметува вкупното трошење досега, бројот на отворени фактури, последната активност и статусот на сметката од сурови табели. Наменски ред со резиме може да ја направи вообичаената патека предвидлива:

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
);

Оваа табела не е замена за фактури или плаќања. Таа е модел за читање. Нејзините вредности мора да може да се изведат од авторитативните податоци, а нејзината патека за ажурирање мора намерно да биде дизајнирана.

Изберете како се ажурираат проекциите

Постојат три вообичаени пристапи, секој со различни карактеристики при неуспех.

• Синхрони ажурирања ја запишуваат трансакцијата и проекцијата во истото барање. Тие обезбедуваат непосредна конзистентност, но ја зголемуваат сложеноста и латентноста на патеката за запишување.
• Асинхрони потрошувачи обработуваат трајни настани или outbox табела откако ќе се изврши потврдувањето на трансакцијата. Тие ја штитат патеката на барањето и добро се скалираат, но интерфејсот мора да толерира краткотрајна застареност.
• Закажани повторни изградби повторно ги пресметуваат податоците во серии. Едноставни се за извештаи со мала итност, но несоодветни се таму каде што корисниците очекуваат моментални промени.

За многу PHP апликации, outbox образецот е прагматична средина. Потврдете ја деловната промена и мал запис за настан во една трансакција на базата на податоци. Потоа работник чита необработени настани и ги ажурира проекциите. Ова избегнува тврдење дека настанот бил објавен кога соодветната трансакција на базата на податоци не успеала.

$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;
}

Работникот мора да биде идемпотентен. Може да го прими истиот настан двапати по повторен обид, па ажурирањата на проекцијата треба безбедно да конвергираат. Единствен запис за обработен настан, монотона верзија или атомско upsert ажурирање може да ја обезбеди таа заштита. Испораката „најмалку еднаш“ е управлива; тивкото двојно пресметување на пари не е.

Предвидувањето често е поедноставно од машинското учење

Зборот предиктивно може да сугерира модел, складиште на карактеристики и нетранспарентен процес за оценување. Тие можат да бидат соодветни, но повеќето придобивки во задниот дел почнуваат со вообичаеното однесување на производот. Неодамнешната активност го предвидува следниот екран. Промена на состојба ја предвидува следната оперативна задача. Често бараниот филтер предвидува корисен индекс или претходно пресметан број на аспекти.

Пред да додадете софистицирани модели, измерете ги реалните обрасци на пристап. Барајте повторувани комбинации на филтри, скапи агрегати и низи од барања. Ако корисниците кои прегледуваат сметка обично потоа ги отвораат нејзините фактури, претходното вчитување на ограничено резиме на фактури може да биде оправдано. Ако тоа го прават понекогаш, кеш може да биде доволен. Ако патеката е ретка или товарот е голем, не правете ниту едно од двете.

Предвидувањето треба да ја намали работата, а не да ја премести некаде помалку видливо. Секое изведено складиште создава трошок: складирање, координација на распоредувањето, повторни пополнувања, следење, преглед на приватноста и оперативна сопственост.

Одржувајте го изворот на вистина поправлив

Изведените податоци се безбедни само кога може да се поправат. Вградете ја таа претпоставка во архитектурата уште од почетокот.

• Чувајте ги авторитативните трансакциски записи независно од проекциите.
• Верзионирајте ги товарите на настаните и логиката на проекцијата додека договорите се развиваат.
• Обезбедете ограничен процес за повторна изградба за закупец, сметка или опсег на датуми.
• Следете го доцнењето на проекцијата и неуспешните настани како оперативни сигнали.
• Направете ја свежината видлива во интерфејсите кога застарените податоци би можеле да ги доведат корисниците во заблуда.

Целосната повторна изградба не е само функција за опоравување при катастрофа. Таа е тест на дизајнот. Ако повторната изградба на проекција бара недокументирани рачни чекори или неповратно историско значење, проекцијата станала скриен извор на вистина.

Распоредувајте ги промените по фази

Предиктивните структури на податоци бараат повеќе грижа отколку додавање клуч за кеш. Користете пристап на проширување и стеснување. Прво распоредете ја новата табела, колона, потрошувач или индекс без да зависите од него. Пополнете ги историските податоци. Проверете ги броевите и репрезентативните записи според изворните табели. Потоа постепено префрлете ги читањата, следете ги латентноста и точноста, и дури подоцна отстранете ги застарените патеки.

Во распоредувања базирани на Docker, ова обично значи дека миграциите и еднократните задачи за повторно пополнување мора да бидат одделени од долготрајните контејнери на апликацијата. Веб-процес не треба да повторно изградува милиони редови при стартување, а неуспешното рестартирање не треба да повторува неограничена миграција. Направете ја задачата експлицитна, продолжлива и набљудлива.

Базата на податоци станува површина на производот

Добро проектираните предиктивни бази на податоци не нагаѓаат непромислено. Тие кодираат информирани очекувања за тоа што им е потребно на корисниците и системите следно, задржувајќи ја способноста за корекција, повторување и поедноставување.

Тоа е трајната лекција надвор од кешот: перформансите не се само складирање на претходни одговори. Станува збор за обликување сигурни податоци околу следното значајно прашање — и за третирање на секоја кратенка како одржуван дел од производот.