Read Models და პროექცია

Read Model არის სპეციალურად შემუშავებული ცხრილი/ინდექსი/ხედი სწრაფი კითხვისთვის კონკრეტული პროდუქტის სცენარისთვის. პროექცია არის პროცესი, რომელიც გარდაქმნის წყაროს მოვლენებს/ცვლილებებს Read Model- ის განახლებაში (ჩვეულებრივ idempotent upsert). CQRS- სთან ერთად, ეს საშუალებას გაძლევთ გადმოტვირთვის OLTP ბირთვი და სტაბილიზაცია p95/p99 მოსმენით, აკონტროლებთ „სიახლეს“.

• დენორმალიზაცია როგორც მოთხოვნა და არა „უნივერსალური სქემა“.
• განაახლეთ დროულად და იდემპოტურად.
• აშკარად გააკონტროლეთ ფოლადი და წესრიგი.

1) როდესაც გამოიყენეთ Read Models (და როდის - არა)

• ხშირი მძიმე კითხვა (ჯონი/აგრეგაცია/დახარისხება) განახლებისთვის დასაშვები შეფერხებით.
• დაშბორდები, კატალოგები, ლენდინგი, „ტოპ N“, პერსონალური ფიდები, საძიებო სიები.
• დატვირთვის გამიჯვნა: write ბირთვი - მკაცრი, read თვითმფრინავი - სწრაფი და მასშტაბური.

• ოპერაციები, რომლებიც მოითხოვს მკაცრ ინვარიანტებს „თითოეული ჩაწერისთვის“ (ფული, უნიკალურობა). არსებობს Strong path.

2) არქიტექტურული წრე (სიტყვიერი სქემა)

1. ცვლილებების წყარო: დომენის მოვლენები (ღონისძიება) ან CDC OLTP- დან.
2. პროექციის კონვეიერი: პარსერი - აგრეგაცია/დენორმალიზაცია - idempotent upsert.
3. Read Store: BD/მოთხოვნის ოპტიმიზირებული ინდექსი (RDBMS, სვეტები, საძიებო).
4. API/კლიენტი: სწრაფი SELECT/GET, ატრიბუტებით „as _ of/freshness“.

3) Read Model- ის დიზაინი

დაიწყეთ თხოვნით: რომელი ველები, ფილტრები, დახარისხება, პაგინაცია, ტოპ N?
დენორმალიზება: შეინახეთ უკვე კომბინირებული მონაცემები (სახელები, თანხები, სტატუსები).

• განაწილება: 'tenant _ id', თარიღი, რეგიონი.
• Primary key: ბიზნეს გასაღები + დროებითი ბაკეტი (მაგალითად, '(tenant _ id, entity _ id)' ან '(tenant _ id, bucket _ minute)').
• ინდექსები: ხშირი, სადაც/წესრიგი უნდა იყოს.
• TTL/ჭრელი: დროებითი ფანჯრისთვის (მაგალითად, 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);

• თითოეული შეტყობინება ახორციელებს ვერსიას/დროს; ჩვენ ვიღებთ მხოლოდ „ახალ ან თანაბარ“ (იდუმალი).
• აგრეგატებისთვის (მრიცხველები, თანხები) - შეინახეთ სახელმწიფო და გამოიყენეთ კომუტაციური განახლებები (ან CRDT მიდგომები).

5) ცვლილებების წყარო: მოვლენები CDC

მოვლენები (მოვლენები): მდიდარი სემანტიკა, ადვილია სხვადასხვა პროექციის შექმნა; სქემების ევოლუცია მნიშვნელოვანია.
CDC (ლოგიკური რეპლიკაცია): უბრალოდ დაკავშირება არსებულ მონაცემთა ბაზასთან; დასჭირდება მოვლენების DML mapping და ხმაურის აფთიაქების გაფილტვრა.

• მიწოდების გარანტიები (at-least-once) და DLQ „შხამიანი“ შეტყობინებებისთვის.
• შეკვეთა (წვეულება key = 'tenant _ id: entity _ id').

6) წესრიგი, მიზეზი და „ახალი“

შეკვეთა: ერთი ობიექტის მოვლენები თანმიმდევრულად უნდა მოვიდეს; გამოიყენეთ განაწილება და ვერსიები.
მიზეზი: იმისათვის, რომ ავტორმა დაინახოს თავისი ცვლილებები (RYW), გადაიტანეთ watermark ვერსიები მოთხოვნებში.
სიახლე: დააბრუნეთ '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) საძიებო და გეო პროგნოზები

ძებნა (ES/Opensearch): დენორმალიზებული დოკუმენტი, მილის გარდაქმნები, დოკუმენტის ვერსია = წყაროს ვერსია.
გეო: შეინახეთ 'POINT/LAT, LON', ადრე დააკავშირეთ ტაილები/ATV.

9) მულტფილმები და რეგიონები

'tenant _ id' სავალდებულოა პროექციებისა და მოვლენების გასაღებებში.
Fairness: შეზღუდეთ per tenant (WFQ/DRR) პროგნოზები ისე, რომ „ხმაურიანი“ არ შეანელოთ დანარჩენი.
Residency: პროექცია ცხოვრობს იმავე რეგიონში, როგორც write ბირთვი; ინტერრეგიონალური ფანჯრები - დანაყოფები/მოხსენებები.

10) დაკვირვება და SLO

• 'projection _ lag _ ms' (წყარო - ვიტრინა), 'freshness _ age _ ms' (ბოლო დელტადან).
• throughput apdates, შეცდომების წილი, DLQ-rate, redrive-success.
• ფანჯრების ზომა, p95/p99 კითხვის ლატენტობა.

• Теги: `tenant_id`, `entity_id`, `event_id`, `version`, `projection_name`, `attempt`.
• მენიუ: merge გადაწყვეტილებები, მოძველებული ვერსიების გამოტოვება.

11) Playbooks (runbooks)

1. ლაგის ზრდა: შეამოწმეთ კონექტორი/ბროკერი, გაზარდეთ წვეულებები, ჩართეთ ძირითადი ფანჯრების პრიორიტეტი.
2. სქემის მრავალი შეცდომა: რადარის გაყინვა, სქემების მიგრაცია (backfill), გადატვირთვა mapper- ის ახალი ვერსიით.
3. განმეორებითი DLQ: შეამციროს batch, ჩართოთ „ჩრდილის“ დამუშავება, გაძლიერდეს idempotence.
4. ფანჯრის არათანმიმდევრულობა: ჟურნალის/ფანჯრის წყაროდან რებილის ფანჯრების შესრულება (შერჩევით ჩრდილში/წვეულებაზე).
5. ცხელი გასაღებები: შეზღუდეთ კონკურენცია გასაღებით, დაამატეთ ადგილობრივი ხაზები, შეიყვანეთ დანაყოფი ცალკეულ ფანჯარაში.

12) სრული დათვლა

• შეაჩერეთ მოხმარება (ან გადავიდეთ ფანჯრის ახალ ვერსიაზე).
• გადაანგარიშეთ პაკეტები (პარტიების/თარიღების/ტენანტების მიხედვით).
• ჩართეთ ორფაზიანი სვიტრი: ჯერ შეავსეთ 'read _ _ v2 ", შემდეგ ატომურად გადართეთ კითხვის მარშრუტიზაცია.

13) სქემების ევოლუცია (ვერსია)

'schema _ version' მოვლენებში/დოკუმენტებში.
პროექციას შეუძლია წაიკითხოს რამდენიმე ვერსია, მიგრაცია „ფრენაზე“.
ძირითადი ცვლილებებისთვის - ახალი v2 ფანჯარა და კანარის ტრაფიკი.

14) უსაფრთხოება და წვდომა

მემკვიდრეობით RLS/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.
ერთეულებში იდემპოტენტურობის არარსებობა - დუბლირება/გადახტომა.
ორმაგი write პირდაპირ ფანჯარაში და OLTP განსხვავებები.
სიახლის ნულოვანი ხილვადობა - მოლოდინების კონფლიქტი პროდუქტთან.
Rebuild, ორფაზიანი გრაგნილის გარეშე, პასუხებში „ხვრელია“.
არ არსებობს კონვერტაცია/ინდექსები - ფასისა და ლატენტობის ზრდა.

17) სწრაფი რეცეპტები

კატალოგი/ძებნა: დოკუმენტური ფანჯარა + ექსტრავერტული upsert, lag-5-15 c, ფილტრების ინდექსები.
Dashboards: წუთიერი/საათიანი ტანკები, აგრეგატები 'SUM/COUNT', p95 სიახლე 60 წმ.
პერსონალური ფირზე: მომხმარებლის პროექცია + causal/RYW ავტორისთვის, ქეში fallback.
გლობალური SaaS: რეგიონალური ფანჯრები, ჯვარედინი ერთეული; fairness per tenant.

18) ჩეკის სია გაყიდვამდე

• ვიტრინა შექმნილია კონკრეტული თხოვნისთვის; არსებობს ინდექსები და წვეულებები.
• შეირჩა ცვლილებების წყარო (მოვლენები/CDC); მიწოდების გარანტიები და გასაღები.
• Idempotent upsert ვერსიებით/დროით; დაცვა „ძველი“ მოვლენებისგან.
• სიახლის SLO განსაზღვრულია და მოცემულია პასუხებში ('as _ of/freshness').
• DLQ და უსაფრთხო რადარი მორგებულია; rebuild/backfill ფლეიბუკი.
• კონკურენციის შეზღუდვები (per-key serial) და fairness per tenant.
• მეტრიკები lage/შეცდომები/შეცდომები, ალერტები p95/p99 და ზრდა DLQ.
• სქემების ვერსია და მიგრაციის სტრატეგია (v2 + სვიტრი).
• დაშვების პოლიტიკოსები/PII მემკვიდრეობით და გადამოწმებულია.

დასკვნა

Read Models და პროექციები არის საინჟინრო კითხვის ამაჩქარებელი: თქვენ იხდით მცირე ფასად „სიახლე“ და ნაკადის ინფრასტრუქტურა, რათა მიიღოთ პროგნოზირებადი მილიწამები და გადმოტვირთვის ჩანაწერების ბირთვი. დააპროექტეთ ფანჯრები მოთხოვნის ქვეშ, გააკეთეთ აპდეიტები idempotent, გაზომეთ lag და აშკარად დაჰპირდით სიახლეს - და თქვენი API სწრაფად დარჩება დატვირთვის, მონაცემებისა და გეოგრაფიის გაზრდით.