Read Models և պրոյեկցիաներ

Read Model-ը հատուկ նախագծված կոդն է/ինդեքսը/տեսակը արագ կարդալու համար հատուկ ապրանքային սցենարի համար։ Պրոյեկցիան մի գործընթաց է, որը վերածում է իրադարձությունների/աղբյուրի փոփոխությունը Read Model-ի թարմացման մեջ (սովորաբար idempotent ups.ru)։ CQRS-ի հետ կապված դա թույլ է տալիս բեռնել OLTP միջուկը և կայունացնել p95/p99 ընթերցումները, վերահսկելով «թարմությունը»։

Հիմնական գաղափարները

Դենորմալիզացնել հարցման տակ, ոչ թե «համընդհանուր սխեմա»։

Թարմացնելը ռեֆմենտալ և իդեմենտալ է։

Հստակ կառավարել staleness և կարգը։

1) Երբ օգտագործեք Read Models (և երբ 'ոչ)

Հարմար է

Հաճախակի ծանր ընթերցումներ (ջոիններ/ագրեգացիաներ/տեսակավորում) նորարարության թույլատրելի ուշացումով։

Dashbords, lendings, «առաջին N», անձնական ֆիդներ, որոնման ցուցակներ։

Բեռի բաժանումը 'write-միջուկը' խիստ, read-ինքնաթիռը 'արագ և մեծացված։

Չի համապատասխանում

Վիրահատությունները, որոնք պահանջում են խիստ ինվարանտներ «յուրաքանչյուր ձայնագրման համար» (գումար, եզակի)։ Այնտեղ 'strong path։

2) Ճարտարապետական ֆորումը (բանավոր սխեմա)

1. Փոփոխությունների աղբյուրը 'տիրույթի իրադարձությունները (event sourcing) կամ CDC-ը OLTP-ից։

2. Պրոյեկտների փոխակրիչը 'պարսեր/denomation/didempotent ups.ru։

3. Read Store: BD/ինդեքսը օպտիմիզացված է հարցման համար (RDBSA, հսկայական, որոնողական)։

4. API/հաճախորդ 'արագ RTS/GET, «as _ of/freshness» օրինակներով։

3) Read Model նախագծումը

Սկսեք հարցումից 'ի՞ նչ դաշտեր, ֆիլտրեր, տեսակավորում, պագինացիա, առաջին N։

Դենորմալիզացրեք 'պահպանեք արդեն միավորված տվյալները (անուններ, գումարներ, արձաններ)։

Բանալիներ

Կուսակցությունը '«tenium _ id», ամսաթիվը, տարածքը։

Primary key: բիզնես բանալին + ժամանակավոր բաքը (օրինակ ՝ «(tenrone _ id, entity _ id)» կամ «(tenrone _ id, bucket _ minae)»)։

Ինդեքսներ ՝ հաճախակի where/order by։

TTL/retenshn 'ռուսական վիտրինի համար (օրինակ, 90 օր)։

4) Հոսքի հոսքը և կուռքերը

Idempotent ups.ru-ը պրոյեկտների կայունության հիմքն է։

Կեղծ

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

Ագրեգատների համար (հաշվիչներ, գումարներ), պահեք state և օգտագործեք բաղադրիչ նորարարություններ (կամ CRDT մոտեցումներ)։

5) Փոփոխության աղբյուրը 'vs CDC իրադարձությունները

Իրադարձությունները (event sourcing) 'հարուստ սեմանտիկան, հեշտ է կառուցել տարբեր պրոյեկտներ։ սխեմաների էվոլյուցիան կարևոր է։

CDC (տրամաբանական կրկնօրինակումը) 'պարզապես միացնել գոյություն ունեցող BD-ին։ Mapping DML-ը կպահանջի իրադարձությունների և աղմկոտ դեղատների ֆիլտրացման։

Երկու տարբերակները պահանջում են

Առաքման երաշխիքները (at-least-once) և DLQ-ը «թունավոր» հաղորդագրությունների համար։

Կարգի բանալին (partenskey = «tenrone _ id: entity _ id»)։

6) Կարգը, պատճառները և «թարմությունը»

Մեկ օբյեկտի իրադարձությունները պետք է հետևողական լինեն. օգտագործեք նվագակցումը և տարբերակները։

Պատճառները (session/causal), որպեսզի հեղինակը տեսնի իր փոփոխությունները (RYW), փոխանցեք watermark տարբերակը պահանջների մեջ։

Թարմություն (bounded staleness): Վերադարձեք «as _ of »/« X-J-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;

Առաջին N-ի համար

Աջակցեք վիրավորված վիտրինին (օրինակ ՝ «revenue DESC») և թարմացրեք միայն փոփոխված դիրքերը (heap/skiplist/limited table)։

Պահեք «պատուհանը» (օրինակ ՝ 100-1000 տող սեգմենտում)։

8) Որոնողական և գեո պրոյեկցիաներ

Որոնումը (ES/Oppronearch) 'վերարտադրված փաստաթուղթ, pipeline փոխակերպումներ, փաստաթղթի տարբերակը = աղբյուրի տարբերակը։

Գեյո 'պահեք «POP/LAT, LON», նախկինում համախմբեք թայլերը/քառակուսիները։

9) Multi-tenant և տարածաշրջանները

«tenrone _ id» -ը պարտական է պրոյեկտների և իրադարձությունների բաներին։

Fairness: Սահմանափակեք throughput պրոյեկտները per tenae (WFQ/MSR), որպեսզի «աղմուկը» չխանգարի մյուսներին։

Residency: Պրոյեկտը ապրում է նույն տարածաշրջանում, ինչպես write-միջուկը։ միջտարածաշրջանային վիտրինները ագրեգատներ/ծալքեր են։

10) Դիտարկումը և SLO-ն

Մետրիկները

«project _ lag _ 24» (ռուսական վիտրինի աղբյուրը),« freshness _ age _ 2019 »(վերջին դելտա պահից)։

throughput apdeits, սխալների մասը, DLQ-rate, redrive-success։

Վիտրինի չափը, p95/p99 ընթերցանության լատենտ։

Թրեյսինգ/լոգներ

Теги: `tenant_id`, `entity_id`, `event_id`, `version`, `projection_name`, `attempt`.

Սենսացիաներ ՝ merge լուծումներ, հնացած տարբերակների բաց։

11) Պլեյբուկի (runbooks)

1. Ճամբարի աճը 'ստուգել կոնեկտորը/բրոքերը, ավելացնել կուսակցությունները, ներառել հիմնական վիտրինի գերակայությունը։

2. Սխեմայի շատ սխալներ 'սառեցնել ռեդրեյվը, կատարել սխեմաների միգրացիան (backfill), վերագործարկել մապերի նոր տարբերակով։

3. Կրկնվող DLQ 'նվազեցնել batch-ը, ներառել «ստվերային» վերամշակողը, ուժեղացնել կուռքերը։

4. Վիտրինի անհամապատասխանությունը 'կատարել rebuild վիտրինները/աղբյուրը պատուհանի համար (ընտրովի ten.ru/part.ru)։

5. Տաք բանալիներ 'սահմանափակել մրցակցությունը, ավելացնել տեղական գծերը, միավորել առանձին պատուհանի մեջ։

12) Ամբողջական վերահաշվարկ (rebuild) և backfill

Մոտեցում

Դադարեցնել սպառումը (կամ անցնել վիտրինի նոր տարբերակին)։

Հաշվել փաթեթները (կուսակցության/ամսաթվերի/տենանտների)։

Միացրեք երկբևեռ սվիտչը 'նախ լցրեք «read _ v2», ապա ատոմորեն փոխում ենք ընթերցանության ուղղությունը։

13) Սխեմաների էվոլյուցիան (տարբերակումը)

«schema _ version» իրադարձություններում/փաստաթղթերում։

Պրոյեկցիան կարող է կարդալ մի քանի տարբերակներ, միգրացիա «ամռանը»։

Մեծ փոփոխությունների համար 'նոր v2 վիտրինը և կանարեկային ֆորումը։

14) Անվտանգություն և հասանելիություն

Ժառանգեք RFC/ACL աղբյուրից։ մի արեք վիտրինը ավելի լայն հասանելի, քան սկզբնական տվյալները։

Դիմակավորված PII-ը UX/վերլուծության համար անհրաժեշտ նախագծերում։

Ռեդրեյվների/հատումների/ձեռքով աջ։

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։

Idempotenty բացակայությունը կատարվում է դուբլի/ցատկում ագրեգատներում։

Dance-write ուղղակիորեն վիտրինի և OLTP-ի տարբերությունները։

Թարմության զրոյական տեսանելիությունը բացատրում է սննդի հետ սպասումների հակամարտությունը։

Rebuild-ը, առանց երկչափ սվիտչի, պատասխանում է «անցքեր»։

Ոչ մի կուսակցական/ինդեքսներ ապացուցում են արժեքի և լատենտության աճը։

17) Արագ բաղադրատոմսեր

Գրացուցակ/որոնում: Վավերագրական վիտրինը + www.ru իրական ups.ru, lag no 5-15 c, ֆիլտրերի ինդեքսները։

Dashbords: րոպե/ժամ բաքեր, «SUM/COUNT» ագրեգատներ, p95 թարմություն 2460 c։

Անձնական ժապավենը '+ causal/RYW-ի պրոյեկտը հեղինակի համար, fallback-ի վրա։

Գլոբալ SaaS 'տարածաշրջանային վիտրիններ, քրոսեքսային ագրեգատներ։ fairness per tenant.

18) Չեկ թուղթ մինչև վաճառելը

• Վիտրինը նախագծված է կոնկրետ հարցման համար։ կան ինդեքսներ և կուսակցություններ։
• Փոփոխությունների աղբյուրը ընտրվել է (իրադարձություններ/CDC); երաշխիքներ և կարգուկանոն բանալիով։
• Idempotent ups.ru տարբերակներով/ժամանակ; պաշտպանություն «հին» իրադարձություններից։
• SLO թարմություն է տալիս և պատասխանում է («as _ of/freshness»)։
• DLQ և անվտանգ ռեդրեյվը տրամադրված են. plack rebuild/backfill։
• Մրցակցության սահմանափակումները (per-key serial) և fairness per tenae։
• Լագայի/սխալների/latency, alerts p95/p99 և DLQ աճի վրա։
• Սխեմաների տարբերակումը և միգրացիայի ռազմավարությունը (v2 + սվիտչ)։
• Հասանելիության քաղաքականությունը/PII ժառանգվում և ստուգվում են։

Եզրակացություն

Read Models-ը և պրոյեկտները ընթերցանության ինժեներական արագացուցիչն են, դուք վճարում եք «թարմ» և striming ենթակառուցվածքը, որպեսզի ստանաք կանխատեսելի միլիմետրեր և բեռնեք ձայնագրությունների միջուկը։ Նախագծեք վիտրինները հարցման տակ, դարձրեք apdeits idempotent, չափեք լամպը և հստակ խոստացեք թարմություն, և ձեր API-ն կմնա արագ նույնիսկ բեռի, տվյալների և աշխարհագրության աճի ժամանակ։