როგორ დაანაწილებთ (partition) ერთ ცხრილს მილიარდობით მწკრივით?

Question

IT Interview Practice · Accepted Answer

**დაყავით გიგანტური ცხრილი პატარა ფიზიკურ შვილობილ ცხრილებად partition key-ით, ასე რომ თითო query მხოლოდ იმ partition-ებს ეხებოდეს, რომლებიც სჭირდება (partition pruning), მილიარდობით მწკრივის სკანირების ნაცვლად.** 5B order მწკრივიანი ცხრილი მაინც ერთ ლოგიკურ ცხრილად იქცევა, მაგრამ engine მისი 99%-ს გამოტოვებს, როცა თქვენი `WHERE` partition key-ზე ფილტრავს.

## Partitioned ცხრილის ფორმა

```text
                 orders (logical parent)
                        │  partition key = created_at
       ┌────────────────┼────────────────┬───────────────┐
       ▼                ▼                ▼               ▼
 orders_2024_q1   orders_2024_q2   orders_2024_q3   orders_2025_q1
  (child table)    (child table)    (child table)    (child, active)
       │                                                  │
   local index                                        local index
   (per child)                                        (per child)
```

## Partition სტრატეგიის არჩევა

- **Range** — თარიღის/id range-ებით. საუკეთესო time-series-ისთვის (order-ები, ლოგები, event-ები); უახლესი მონაცემი ცხელი რჩება და ძველი range-ები ადვილად ჩამოსაგდებია.
- **Hash** — თანაბარი განაწილება N partition-ზე `hash(key) % N`-ით. გამოიყენეთ, როცა ბუნებრივი range არ არის და დაბალანსებული load გინდათ (მაგ. `user_id`).
- **List** — ცხადი bucket-ები (`region IN ('EU','US')`). კარგია tenant ან region იზოლაციისთვის.

```sql
-- Postgres: range partition თვის მიხედვით, pruning created_at-ზე
CREATE TABLE orders (id bigint, created_at date, amount numeric)
  PARTITION BY RANGE (created_at);

CREATE TABLE orders_2025_01 PARTITION OF orders
  FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');

-- ეს სკანირებს მხოლოდ orders_2025_01-ს, არა მთელ ცხრილს
SELECT sum(amount) FROM orders
 WHERE created_at >= '2025-01-01' AND created_at < '2025-02-01';
```

## Pruning, index-ები, maintenance

- **Partition pruning** მხოლოდ მაშინ მუშაობს, თუ query **partition key**-ზე ფილტრავს. სხვა რამეზე ფილტრი — და ყოველ partition-ს სკანირებთ — #1 შეცდომა.
- **Local index** = ერთი index თითო შვილზე (ნაგულისხმევი Postgres-ში); იაფი ასაგებად და ჩამოსაგდებად partition-თან ერთად. **Global index** (Oracle) ყველა partition-ს ფარავს — ეხმარება unique lookup-ებს partition-ებზე, მაგრამ partition-ის ჩამოგდებისას ხელახლა უნდა აიგოს.
- **Maintenance** ხდება O(partition): ძველი მონაცემის არქივირება `DROP TABLE orders_2019`-ით (მყისიერი, გიგანტური `DELETE`-ის გარეშე), და `ATTACH`/`DETACH` მოძრავი ფანჯრებისთვის.

## ინტერვიუს პერსპექტივა

ინტერვიუერი ამოწმებს, გესმით თუ არა, რომ **partitioning არ არის indexing** — ის ამცირებს დასკანირებულ მონაცემს, index ამცირებს scan-ის შიგნით შესწავლილ მწკრივებს; ხშირად ორივე გჭირდებათ. კარგი პასუხი ასახელებს range/hash/list-ს; შესანიშნავი პასუხი ხაზს უსვამს, რომ **partition key თქვენს დომინანტ query ფილტრს უნდა ემთხვეოდეს**, აფრთხილებს, რომ არასწორი გასაღები pruning-ს კლავს, და ახსენებს იაფ არქივირებას `DROP`-ით.

**ტრეიდ-ოფი:** cross-partition query-ები (გასაღების ფილტრის გარეშე, ან unique constraint-ები partition-ებზე) ნელდება და unique enforcement რთულდება. ნუ დაანაწილებთ 10M-მწკრივიან ცხრილს — ოპერაციულ სირთულეს ამატებთ სარგებლის გარეშე. Partition გააკეთეთ, როცა ცხრილი უზარმაზარია **და** query-ები ბუნებრივად გასაღებით არის შემოსაზღვრული.

Partitioned ცხრილის ფორმა

Partition სტრატეგიის არჩევა

Pruning, index-ები, maintenance

ინტერვიუს პერსპექტივა

დაკავშირებული კითხვები