მოთხოვნის ინდექსაცია და ოპტიმიზაცია

1) ინდექსაციისა და ოპტიმიზაციის მიზნები

ლატენტობა: აბრევიატურა P50/P95/P99.
გამტარუნარიანობა: QPS ზრდა ჰორიზონტალური მასშტაბის გარეშე.
პროგნოზირება: სტაბილური გეგმები და პასუხის დროის „ნახტომი“ არარსებობა.
დაზოგვა: ნაკლები IO/CPU, ნაკლები ღრუბლის ანგარიში.
საიმედოობა: დაბლოკვის და ბედლოკების შემცირება სწორი წვდომის გამო.

• ნებისმიერი ოპტიმიზაცია უნდა შეინარჩუნოს სისწორე და შესაბამისობა.
• თვალყურის დევნება მეტრიკებში და გეგმების ლოგოებში.

2) ინდექსების ძირითადი სტრუქტურები და როდის უნდა იქნას გამოყენებული

2. 1 B-Tree (ნაგულისხმევი)

თანაბარი/დიაპაზონი, დახარისხება, 'ORDER BY'.
დროის ფილტრების უმეტესობისთვის კარგია/ID/სტატუსი.

2. 2 Hash

სუფთა თანასწორობა ('='), მეხსიერებიდან იაფია, მაგრამ წესრიგის გარეშე (PG: შეზღუდვები ამოღებულია, მაგრამ მაინც ნიშა არჩევანია).

2. 3 GIN / GiST (PostgreSQL)

GIN: მასივები/JSONB გასაღებები, სრული ტექსტი (tsvector), containment ('@>').
GiST: გეო, დიაპაზონი, kNN.

2. 4 BRIN (PostgreSQL)

სუპერ იაფი ინდექსი „ბუნებრივად დალაგებული“ მაგიდების მიხედვით (დროულად append-only). კარგია დროის სერიებისთვის დიდი ცხრილებით.

2. 5 Bitmap (MySQL/InnoDB: არა მშობლიური; DW-DBMS/OLAP)

ეფექტურია დაბალი კარდინალურობისა და ფასეტებისთვის, უფრო ხშირად სვეტების საცავებში.

2. 6 სვეტების ინდექსები (ClickHouse)

Primary key + data skipping (minmax), secondary через `skip indexes` (bloom, set).
OLAP მოთხოვნები დანაყოფებითა და დიაპაზონებით.

2. 7 ინვერსიული ინდექსები (Elasticsearch/OpenSearch)

სრული ტექსტი, ფასეტები, ჰიბრიდული ძებნა. ზუსტი ფილტრებისთვის გამოიყენეთ keyword ველები და doc values.

2. 8 MongoDB

Single, compound, multikey (მასივები), partial, TTL, text, hashed (sharding ერთნაირად).

3) გასაღებების და კომპოზიციური ინდექსების დიზაინი

3. 1 „მარცხენა პრეფიქსი“

ინდექსში ველების რიგი განსაზღვრავს გამოყენებას.
მოთხოვნა 'WHERE tenant _ id =? AND created_at >=? ORDER BY created_at DESC` → индекс `(tenant_id, created_at DESC, id DESC)`.

3. 2 Tie-breaker

დაამატეთ უნიკალური კუდი (ჩვეულებრივ 'id') სტაბილური დახარისხებისა და seek პაგინაციისთვის.

3. 3 ნაწილობრივი/ფილტრირებული ინდექსები

sql
CREATE INDEX idx_orders_paid_recent
ON orders (created_at DESC, id DESC)
WHERE status = 'paid' AND created_at > now() - interval '90 days';

3. 4 ინდექსების დაფარვა

sql
CREATE INDEX idx_user_lastseen_inc ON users (tenant_id, last_seen DESC) INCLUDE (email, plan);

3. 5 ფუნქციური/გამოთვლილი

sql
CREATE INDEX idx_norm_email ON users (lower(email));

4) განაწილება და შარდვა

4. 1 PG native/ფირფიტის მემკვიდრეობა; MySQL RANGE/LIST)

დროის პარტიების როტაცია ('daily/weekly') ამარტივებს 'VACUUM/DELETE ".
ინდექსები ადგილობრივი ნაწილია - ნაკლები B-Tree, უფრო სწრაფად, ვიდრე გეგმა.

sql
CREATE TABLE events (
tenant_id bigint,
ts timestamptz,
...
) PARTITION BY RANGE (ts);

4. 2 განაწილების გასაღები

OLTP- ში - 'tenant _ id' (დატვირთვის ლოკალიზაცია).
დროის სერიაში/OLAP - 'ts' (დიაპაზონის მოთხოვნები).
ჰიბრიდი: '(tenant _ id, ts) + ქვედანაყოფები.

4. 3 შარდვა

Consistent hashing/range-shard თითო 'tenant _ id' ან დროში.
Cross-Shard მოთხოვნა - scatter-gather და k-way merge; გამართეთ per shard cursor.

5) სტატისტიკა, კარდინალობა და გეგმები

5. 1 მიმდინარე სტატისტიკა

ჩართეთ მანქანის ანალიზი ('autovacuum/autoanalyze'), გაზარდეთ 'defeult _ statistics _ target "" ბინძური "განაწილებისთვის.

5. 2 გაფართოებული სტატისტიკა (PG)

sql
CREATE STATISTICS stat_user_country_city (dependencies) ON country, city FROM users;
ANALYZE users;

5. 3 განხორციელების გეგმა

• `Rows`, `Loops`, `Actual time`, `Shared Read/Hit`, `Recheck Cond`.
• Типы join: Nested Loop, Hash Join, Merge Join.
• Seq Scan vs Index Scan/Only Scan/Bitmap Heap Scan.

5. 4 გეგმის სტაბილურობა

პარამეტრიზაციას (წინასწარ განსაზღვრულ სტატიებს) შეუძლია „ჩაძირვა“ ცუდი გზით. გამოიყენეთ plan cache guardrails (PG: 'plan _ cache _ mode = force _ custom _ plan' პრობლემური მოთხოვნებისთვის) ან მუდმივი „rush“.

6) join და დახარისხების ოპტიმიზაცია

6. 1 სტრატეგია

Nested Loop: მცირე გარე, სწრაფი ინდექსი შიდა.
Hash Join: დიდი ნაკრები, საკმარისია მეხსიერება hash table- ისთვის.
Merge Join: დალაგებული შესასვლელი, მომგებიანია უკვე არსებული წესრიგით.

6. 2 Join ინდექსები

'A JOIN B ON B.a _ id = A.id' - ისთვის ინდექსი 'B (a _ id)' - ზე.
ფილტრის შემდეგ ჯონის შემდეგ - ინდექსი შიდა ცხრილის ფილტრის სვეტებზე.

6. 3 დახარისხება

მოერიდეთ 'ORDER BY' შესაბამისი ინდექსის გარეშე; დიდ კომპლექტებში დახარისხება მეხსიერების/დისკის გზა.

7) მოთხოვნის გადაწერა (query rewrite)

თავიდან აიცილეთ სუბსიდიების „ფიფქები“; გადააკეთეთ JOIN.
გამოიყენეთ CTE-inline (PG-12 inlines CTE ნაგულისხმევი, მაგრამ 'MATERIALIZED' შეუძლია დააფიქსიროს შუალედური შედეგი, საჭიროების შემთხვევაში).
ამოიღეთ „შერჩევა“ და ჩამოთვალეთ ველები (დაზოგეთ IO/ქსელი).
გადაიტანეთ გამოთვლები „WHERE“ - დან ინდექსირებულ ფორმამდე (მიკერძოებული სვეტები).
აგრეგაციები: წინასწარი საერთო ცხრილები/მატერიალიზებული წარმოდგენები სავარაუდო განახლებით.

8) სამშობლო, შეზღუდვა და პაგინაცია

Batch-insert/განახლება: პაკეტების ნაცვლად 500-5000.
Seek pagination '(sort _ key, id)' ნაცვლად ღრმა „OFFSET“.
დალაგებამდე/ჯოინის (push-down 'LIMIT') კომპლექტის შეზღუდვა.

9) ქეშირება და დენორმალიზაცია

პროგრამის დონის Query-cache (გასაღები = SQL + bind-vars + უფლებების ვერსია).
Materialized views მძიმე დანაყოფებისთვის; როტაციის/რეფრესის გეგმა.
დენორმალიზაცია: შეინახეთ ხშირად წაკითხული ველები (ფასი ფასდაკლებით), მაგრამ ტრიგერის/ფონური ამოცანისთვის.
Redis, როგორც L2, „ცხელი“ გასაღებებისთვის (TTL- ით და მოვლენების ინვალიდობით).

10) პოპულარული ძრავების სპეციფიკა

10. 1 PostgreSQL

Индексы: B-Tree, Hash, GIN/GiST, BRIN, partial, functional, INCLUDE.

sql
CREATE INDEX idx_orders_tenant_created_desc
ON orders (tenant_id, created_at DESC, id DESC)
INCLUDE (amount, status);

sql
CREATE INDEX idx_docs_fts ON docs USING GIN (to_tsvector('russian', title          ' '          body));

10. 2 MySQL/InnoDB

sql
ALTER TABLE orders ALTER INDEX idx_old INVISIBLE; -- check risk-free plans

სტატისტიკა ჰისტოგრამების შესახებ ('ANALYZE TABLE... UPDATE HISTOGRAM` в 8. 0).

10. 3 ClickHouse

პირველადი გასაღები = დახარისხება; 'ORDER BY (tenant _ id, ts, id)'.

sql
CREATE TABLE events (
tenant_id UInt64,
ts DateTime64,
id UInt64,
payload String,
INDEX idx_bloom_payload payload TYPE bloom_filter GRANULARITY 4
) ENGINE = MergeTree()
ORDER BY (tenant_id, ts, id);

10. 4 MongoDB

js db. orders. createIndex({ tenant_id: 1, created_at: -1, _id: -1 });
db. orders. createIndex({ status: 1 }, { partialFilterExpression: { archived: { $ne: true } } });

გამოიყენეთ 'hint ()' დიაგნოზირებისთვის, დააკვირდით 'კვერს'.

10. 5 Elasticsearch/OpenSearch

Keyword vs ველის ტექსტი; doc _ values დახარისხების/შეკრებისთვის.
ჰეპის სეგმენტი: აგრეგაცია - მძიმე; შეზღუდეთ 'size' და გამოიყენეთ 'კომპოზიციური' აგრეგაცია (გვერდითი ნიმუში).
ნუ ჩართავთ ანალიზატორებს, სადაც ზუსტი შედარებაა საჭირო.

11) კონკურენცია, დაბლოკვა და MVCC

მოკლე გარიგებები; მოერიდეთ „ხანგრძლივ“ კითხვებს 'REPEATABLE REATABLE' საჭიროების გარეშე.
ინდექსის ოპერაციები ასევე იკეტება (შემცირება write throughput).

დაგეგმეთ ონლაინ ინდექსირება: 'CREATE INDEX CONCURENTLY' (PG), 'ALGORITHM = INPLACE '/' ONLININE INE E E E E E - ((MAID D D D D VIDUDD DDIEDEEEVVEEED D D EEEEEV

კუდის ჩანართები საათში/ID - ინდექსის „ცხელი გვერდები“; განაწილეთ გასაღები (UUIDv7/მარილი).

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

• 'db _ query _ latency _ ms' (P50/P95/P99) მოთხოვნის სახელით.
• `rows_examined`, `rows_returned`, `buffer_hit_ratio`.
• `deadlocks`, `lock_wait_ms`, `temp_sort_disk_usage`.
• გეგმების წილი „Seq Scan“ - ით, სადაც მოსალოდნელი იყო „ინდექსი სკანი“.
• რეგრესული ალერტები DBMS ვერსიის/პარამეტრების შეცვლისას.

• ჩართეთ slow query ჟურნალი ბარიერი (მაგალითად, 200 ms).
• მოთხოვნის კორელაცია სპანებთან (trace _ id).
• ამოიღეთ პრობლემური მოთხოვნების გეგმები და შეინახეთ ობიექტის საცავში რეტროსპექტივისთვის.

• P95 მოსმენით '<= 150 ms' in 'LIMIT <= 50' და „ცხელი“ ტენანტი.
• P95 ჩანაწერი '<= 200 ms' ბრძოლებში 1000 სტრიქონამდე.

13) უსაფრთხოება და მრავალ ტენანტობა

წვდომის კონტროლის სფეროების ინდექსები ('tenant _ id', 'owner _ id') სავალდებულოა.
პოლიტიკოსები (RLS/ABAC) უნდა იყვნენ წინასწარი ფილტრი; წინააღმდეგ შემთხვევაში, ოპტიმიზატორი არასწორად გეგმავს.
ნუ ინდექსირდებით მგრძნობიარე ველები ღია ფორმით; გამოიყენეთ ჰეში/ნიშნები.

14) ანტი შაბლონები

ღრმა „OFFSET“ გარეშე seek-კადრების ალტერნატივა.
„ერთი ინდექსი ყველაფრისთვის“ - მეხსიერების გადატვირთვა და write-path.
'შერჩევა' კრიტიკულ გზაზე.
ფუნქციები სვეტზე 'WHERE' ფუნქციური ინდექსის გარეშე.
არასტაბილური გეგმები ძველი სტატისტიკის გამო.
'ORDER BY- ს არარსებობა სტაბილური წესრიგის მოლოდინში.
ინდექსების გულისთვის ინდექსები: ROI <0, ძვირადღირებული ჩაწერის/მხარდაჭერის გამო.

15) განხორციელების სია

1. QPS და დროის მოთხოვნების ტოპ N შეარჩიეთ 3-5 კანდიდატი.
2. ამოიღეთ გეგმები 'EXPAIN ANALYZE ", შეამოწმეთ ფაქტობრივი კარდინალობა.
3. ინდექსების შემუშავება: ველის შეკვეთა, INCLUDE/პარტიული/functional.
4. დანერგეთ დიდი ცხრილების განლაგება (დროებითი/ჩრდილოვანი გასაღებები).
5. გადაწერეთ მოთხოვნები: ამოიღეთ 'SELECT', შეავსეთ მარტივი CTE, შეზღუდეთ ნაკრები.
6. ჩართეთ batching და seek pagination.
7. ქეშების კონფიგურაცია: L1/L2, მოვლენების ინვალიდობა.
8. შემოიღეთ გეგმების მონიტორინგი და ნაგავი, ალერტები რეგრესებისთვის.
9. დატვირთვის ტესტების ჩატარება მონაცემთა რეალური განაწილებით.
10. განაახლეთ ჰაიდლაინები განვითარების მიზნით (ORM ჰინტები, ინდექსაცია, ლიმიტები).

16) მაგალითები „დაწყებამდე“

sql
SELECT FROM orders
WHERE status = 'paid'
ORDER BY created_at DESC
LIMIT 50 OFFSET 5000;

sql
-- Индекс: (status, created_at DESC, id DESC) INCLUDE (amount, currency)
SELECT id, amount, currency, created_at
FROM orders
WHERE status = 'paid'
AND (created_at, id) < (:last_ts,:last_id)   -- seek
ORDER BY created_at DESC, id DESC
LIMIT 50;

17) ORM და API პროტოკოლები

თავიდან აიცილეთ N + 1: ხარბი ნიმუშები ('includes', 'JOIN FETCH', 'preload').
აშკარა ველების პროგნოზები, პაგინატის კურსორი.
GRPC/REST: შეზღუდეთ 'page _ size', დააფიქსირეთ 'sort', გამოიყენეთ გაუმჭვირვალე ნიშნები.
ქეში: გამოიყენეთ პარამეტრიზაცია; ნუ წარმოქმნით „უნიკალურ“ SQL თითოეული გამოწვევისთვის.

18) მიგრაცია და ოპერაცია

დაამატეთ ონლაინ ინდექსები და გაისროლეთ, როგორც INVISIBLE/CONCURRENTLY, შეამოწმეთ გეგმები, შემდეგ შეცვალეთ.
ინდექსების გადასინჯვა - რეგულარული სანიტარული გაწმენდა: დუბლიკატები, გამოუყენებელი, „მკვდარი“ ძველი ხაზებისთვის.
პარტიების როტაციის გეგმა (ძველი) და 'VACUUM/OPTIMIZE' გრაფიკი.

19) რეზიუმე

მოთხოვნების ოპტიმიზაცია არის სისტემური ინჟინერია: სწორი გასაღებები და ინდექსები, სისუფთავე გეგმები, გააზრებული წვეულება და შარდვა, მოთხოვნების დისციპლინა და ORM, ქეშირება და დაკვირვება. აღწერილი ნიმუშების დაცვით, თქვენ მიიღებთ სწრაფ, პროგნოზირებად და ეკონომიურ სისტემას, მდგრადია მონაცემების ზრდისა და დატვირთვისთვის.