Read Models жана проекциялар

Read Model - бул атайын иштелип чыккан таблица/индекс/белгилүү бир продукт жагдайда тез окуу үчүн түрү. Проекция - окуяларды/булактын өзгөрүшүн Read Model жаңылоосуна (адатта idempotent upsert) айландыруучу процесс. CQRS менен бирге бул OLTP ядросун түшүрүүгө жана "сергектикти" көзөмөлдөө менен p95/p99 окууларды турукташтырууга мүмкүндүк берет.

• "Универсалдуу схема" эмес, суроо-талапка ылайык денормалдаштыруу.
• Инкременталдык жана демпотенттик менен жаңыртуу.
• Так staleness жана тартипти башкаруу.

1) Качан Read Models колдонуу керек (жана качан - жок)

• Тез-тез оор окуулар (Joins/Агрегация/сорттоо) уруксат берүү кечигүү менен.
• Дашборддор, каталогдор, лендингдер, "топ-N", жеке фиддер, издөө тизмелери.
• Жүктү бөлүштүрүү: write ядро ​ ​ - катуу, read-тегиздик - тез жана масштабдуу.

• "Ар бир жазууга" катуу инварианттарды талап кылган операциялар (акча, уникалдуулук). Бар - strong path.

2) Архитектуралык контур (сөз схемасы)

1. Өзгөртүү булагы: OLTP домендик окуялар (event sourcing) же CDC.
2. Проекция конвейери: парсер → агрегация/денормализация → idempotent upsert.
3. Read Store: DD/индекс, өтүнүч менен оптималдаштырылган (RDBMS, мамычалар, издөө).
4. API/кардар: тез SELECT/GET, "as_of/freshness" атрибуттары менен.

3) Дизайн Read Model

Суроо менен баштаңыз: кайсы талаалар, чыпкалар, сорттоо, пагинация, топ-N?
Денормалдаштыруу: буга чейин бириктирилген маалыматтарды (аталыштар, суммалар, статустар) сактоо.

• Партиялаштыруу: 'tenant _ id', дата, аймак.
• Негизги ключ: бизнес ачкычы + убактылуу бакет (мисалы, '(tenant_id, entity_id)' же '(tenant_id, bucket_minute)').
• Индекстер: тез-тез where/order by.
• TTL/retenshn: убактылуу терезелер үчүн (мисалы, 90 күн).

4) Жаңыртуу агымы жана демпотенттик

Idempotent upsert - проекциялардын туруктуулугунун негизи.

sql
-- Projection table
CREATE TABLE read_orders (
tenant_id  TEXT,
order_id  UUID,
status   TEXT,
total    NUMERIC(12,2),
customer  JSONB,
updated_at TIMESTAMP,
PRIMARY KEY (tenant_id, order_id)
);

-- Idempotent update by event
INSERT INTO read_orders(tenant_id, order_id, status, total, customer, updated_at)
VALUES (:tenant,:id,:status,:total,:customer,:ts)
ON CONFLICT (tenant_id, order_id) DO UPDATE
SET status = EXCLUDED. status,
total = EXCLUDED. total,
customer = COALESCE(EXCLUDED. customer, read_orders. customer),
updated_at = GREATEST(EXCLUDED. updated_at, read_orders. updated_at);

• Ар бир билдирүү версия/убакыт алып келет; бир гана "жаңы же бирдей" (idempotency).
• Агрегаттар үчүн (эсептегичтер, суммалар) - мамлекетти сактаңыз жана коммутациялык жаңыртууларды (же CRDT ыкмаларын) колдонуңуз.

5) өзгөртүү булагы: окуялар vs CDC

Events (event sourcing): бай семантика, ар кандай проекцияларды куруу үчүн жеңил; схемалардын эволюциясы маанилүү.
CDC (логикалык репликация): жөн гана учурдагы DD туташтыруу; mapping DML → окуялар жана чыпкалоо ызы-чуу такталары талап кылынат.

• Жеткирүү кепилдиктери (at-least-once) жана "уулуу" билдирүүлөр үчүн DLQ.
• Ачкыч тартиби (partition key = 'tenant _ id: entity _ id').

6) Тартип, себеп жана "сергектик"

Ачкыч боюнча тартип: бир объектинин окуялары ырааттуу келип турушу керек; партиялаштырууну жана версияларды колдонуңуз.
себептүүлүгү (session/causal): Author анын өзгөрүүлөрдү (RYW) көрүү үчүн, өтүнүч watermark нускасын берүү.
Сергектик (bounded staleness): кайтып 'as _ of '/' X-Data-Freshness' жана SLO (мисалы, p95 ≤ 60 c).

7) Инкременталдык агрегаттар жана жогорку N

sql
CREATE TABLE read_sales_minute (
tenant_id TEXT,
bucket  TIMESTAMP, -- toStartOfMinute revenue  NUMERIC(14,2),
orders  INT,
PRIMARY KEY (tenant_id, bucket)
);

-- Update by Event
INSERT INTO read_sales_minute(tenant_id, bucket, revenue, orders)
VALUES (:tenant,:bucket,:amount, 1)
ON CONFLICT (tenant_id, bucket) DO UPDATE
SET revenue = read_sales_minute. revenue + EXCLUDED. revenue,
orders = read_sales_minute. orders + 1;

• Рейтингдүү витринаны (мисалы, 'revenue DESC' боюнча) колдоп, өзгөргөн позицияларды гана жаңыртыңыз (heap/skiplist/limited table).
• Жогорку "терезени" сактаңыз (мисалы, сегментке 100-1000 сап).

8) Издөө жана гео-проекциялар

Search (ES/Opensearch): denormalized документ, pipeline өзгөрүүлөр, документтин версия = булагы версия.
Гео: сактагыла 'POINT/LAT, LON', алдын ала топтоо tails/quadrotry.

9) Мультитенант жана региондор

'tenant _ id' проекциялардын жана окуялардын ачкычтарында милдеттүү.
Fairness: throughput проекцияларын per tenant (WFQ/DRR) чектеп, "ызы-чуу" башкаларга тоскоол болбойт.
Residency: проекция write ядросу менен бир аймакта жашайт; аймактар аралык витриналар - агрегаттар/отчеттор.

10) Байкоо жана SLO

• 'projection _ lag _ ms' (булак → витрина), 'freshness _ age _ ms' (акыркы дельтадан бери).
• throughput жаңыртуулар, каталардын үлүшү, DLQ-rate, redrive-success.
• Showrooms көлөмү, p95/p99 жашыруун окуу.

• Теги: `tenant_id`, `entity_id`, `event_id`, `version`, `projection_name`, `attempt`.
• Аннотациялар: merge чечимдери, эскирген версияларды калтыруу.

11) Playbooks (runbooks)

1. Lag өсүшү: connector/брокерди текшерүү, партияларды көбөйтүү, негизги витриналарды артыкчылыктуу кылуу.
2. Көптөгөн каталар схемасы: redrave тоңдуруп, схемаларды көчүрүү (backfill), жаңы нускасы менен кайра баштоо.
3. кайталап DLQ: batch азайтуу, "көмүскө" иштетүүчү күйгүзүү, боштукту күчөтүү.
4. Витринанын ыраатсыздыгы: журналдан/булактан терезенин сыртына (tenant/partition боюнча тандалма) терезелерди rebuild кылуу.
5. Ысык ачкычтар: ачкыч боюнча атаандаштыкты чектөө, жергиликтүү кезектерди кошуу, агрегатты өзүнчө витринага алып чыгуу.

12) Толук кайра эсептөө (rebuild) жана backfill

• Керектөөнү токтотуу (же витринанын жаңы версиясына өтүү).
• Пакеттер менен кайра саноо (партиялар/даталар/тенанттар боюнча).
• Эки фазалуу свитчти күйгүзүңүз: адегенде 'read __ v2' толтуруңуз, андан кийин окуу багытын атомдук түрдө которуңуз.

13) Схемалардын эволюциясы (версиялоо)

'schema _ version' окуялар/документтерде.
Проекция бир нече версияларды окуй алат, миграция "учуп баратканда".
Чоң өзгөрүүлөр үчүн - жаңы v2 витринасы жана канар трафиги.

14) Коопсуздук жана жеткиликтүүлүк

Булактан RLS/ACL мурастоо; терезени баштапкы маалыматтарга караганда кененирээк кылбаңыз.
UX/аналитика үчүн зарыл эмес проекцияларда PIIди жашырыңыз.
Редраивдерди/кайра эсептөөлөрдү/кол менен оңдоолорду текшерүү.

15) Конфигурациялык шаблон

yaml projections:
read_orders:
source: kafka. orders. events partition_key: "{tenant_id}:{order_id}"
idempotency: version_ts upsert:
table: read_orders conflict_keys: [tenant_id, order_id]
freshness_slo_ms: 60000 dlq:
topic: orders. events. dlq redrive:
batch: 500 rate_limit_per_sec: 50 read_sales_minute:
source: cdc. orders partition_key: "{tenant_id}:{bucket_minute}"
aggregate: increment retention_days: 90 limits:
per_tenant_parallelism: 4 per_key_serial: true observability:
metrics: [projection_lag_ms, dlq_rate, redrive_success, read_p95_ms]

16) типтүү каталар

"Бардык учурларда бир витрина" → оор жаңылануулар жана жаман p99.
Агрегаттарда → дубль/секирүү болбошу.
Double-write түздөн-түз дисплей жана OLTP → айырмачылыктар.
Нөлдүк көрүү сергектик → продукт менен күтүүлөрдүн карама-каршылыгы.
Rebuild эки фазалуу түрмөк жок → жооптордогу "тешиктер".
Партиялаштыруу/индекстер жок → нарктын жана латенттүүлүктүн өсүшү.

17) Тез Recipes

Каталог/издөө: дарек + инкременталдык upsert, lag ≤ 5-15 c, фильтрлер үчүн индекстер.
Dashboard: мүнөт/саат бакет, агрегаттар 'SUM/COUNT', p95 сергек ≤ 60 с.
Жеке лента: колдонуучу + causal/RYW жазуучу үчүн проекция, кэш үчүн fallback.
Global SaaS: аймактык терезелер, агрегаттар кросс-аймактык; fairness per tenant.

18) Азык-түлүктүн алдындагы чек-тизме

• Витрина белгилүү бир суроо-талап боюнча иштелип чыккан; индекстери жана партиялары бар.
• өзгөртүү булагы тандалып алынган (окуялар/CDC); жеткирүү кепилдиктери жана ачкыч тартиби.
• нускалары/убактысы менен Idempotent upsert; "эски" окуялардан коргоо.
• SLO сергектик аныкталган жана жооп берилет ('as _ of/freshness').
• DLQ жана коопсуз кайра орнотулган; rebuild/backfill боюнча playbook.
• Атаандаштык чектөөлөр (per-key serial) жана fairness per tenant.
• Lag/ката/latency метриктер, p95/p99 жана DLQ өсүшү боюнча алерттерди.
• Схемаларды версиялоо жана миграция стратегиясы (v2 + свитч).
• Erişim/PII саясаты мурасталган жана текшерилген.

Корутунду

Read Models жана проекцияларды окуу үчүн инженердик ылдамдаткыч болуп саналат: сиз алдын ала миллисекунддарды алуу жана жазуулардын өзөгүн түшүрүү үчүн "сергектик" жана агымдын инфраструктурасына бир аз баа менен төлөйсүз. Суроо-талап боюнча витриналарды долбоорлоо, жаңылыктарды идемпотенттик кылуу, лагды өлчөө жана ачык-айкын сергектикти убада кылуу - жана сиздин APIларыңыз жүгү, маалыматтары жана географиясы жогорулаганда да тез бойдон калат.