თანამედროვე მონაცემთა ბაზების მართვაში, განსაკუთრებით კი დროითი სერიების (time-series) დამუშავებისას, შენახვის ხარჯების ოპტიმიზაცია კრიტიკული გამოწვევაა. TimescaleDB ამ პრობლემას ინოვაციური მიდგომით — Hypercore-ის ძრავით წყვეტს, რაც საშუალებას იძლევა, მონაცემები 98%-მდე შევკუმშოთ.
| Feature | TOAST (vanilla PostgreSQL) | TimescaleDB hypercore |
|---|---|---|
| Design goal | Individual values > 2 KB | Cross-row patterns in time-series |
| Trigger | Row exceeds TOAST_TUPLE_THRESHOLD (~2 KB) | Per-chunk policy (e.g. older than 7 days) |
| Supported types | Variable-length only (text, jsonb, bytea, numeric) | All data types |
| Algorithms | pglz (default), lz4 (since PG14, opt-in) | Combination: delta encoding, delta-of-delta, simple-8b, run-length encoding, XOR-based, dictionary compression |
| Compression granularity | Per value (1 value = 1 byte stream) | Per batch (~1000 rows together) |
| Exploiting data structure | No - treats values as opaque bytes | Yes - exploits numeric structure, monotonicity, repetition |
| Typical ratio for sensor floats | ~1.0× (no compression) | 10-20× |
| Typical ratio for timestamps | ~1.0× (no compression - fixed-length type) | 50-100× (delta-of-delta for regular intervals) |
| Typical ratio for text | 2-3× (general-purpose LZ) | 5-10× (dictionary + RLE if repetitive) |
ტრადიციული PostgreSQL-ის TOAST მექანიზმისგან განსხვავებით, რომელიც ცალკეულ დიდ მნიშვნელობებს ამუშავებს, TimescaleDB-ის შეკუმშვა მთლიანად მწკრივებს შორის არსებულ შაბლონებზეა ორიენტირებული. ეს ორი მექანიზმი ერთმანეთს ავსებს და არა ანაცვლებს.
| time | machine_id | sensor_type | value |
|---|---|---|---|
| 12:00:00 | MACHINE_001 | temp | 72.5 |
| 12:00:00 | MACHINE_001 | speed | 2.0 |
| 12:00:05 | MACHINE_001 | temp | 72.7 |
| 12:00:05 | MACHINE_001 | speed | 2.1 |
| 12:00:10 | MACHINE_001 | temp | 72.4 |
| 12:00:10 | MACHINE_001 | speed | 2.4 |
| time | machine_id | sensor_type | value |
|---|---|---|---|
| 12:00:00 | MACHINE_001 | temp | 72.5 |
| 0 seconds | MACHINE_001 | speed | 2.0 |
| 5 seconds | MACHINE_001 | temp | +0.2 |
| 0 seconds | MACHINE_001 | speed | +0.1 |
| 5 seconds | MACHINE_001 | temp | -0.3 |
| 0 seconds | MACHINE_001 | speed | +0.3 |
| time | machine_id | sensor_type | value |
|---|---|---|---|
| 12:00:00 | MACHINE_001 | temp | 72.5 |
| +5 seconds | MACHINE_001 | temp | +0.2 |
| 0 seconds | MACHINE_001 | temp | -0.3 |
| 0 seconds | MACHINE_001 | temp | +0.3 |
| 0 seconds | MACHINE_001 | temp | -0.1 |
| time | machine_id | sensor_type | value |
|---|---|---|---|
| 12:00:00 | MACHINE_001 | temp | 72.5 |
| 12:00:05 | MACHINE_001 | temp | 72.7 |
| 12:00:10 | MACHINE_001 | temp | 72.4 |
| 12:00:15 | MACHINE_001 | temp | 72.6 |
| 12:00:20 | MACHINE_001 | temp | 72.5 |
| machine_id | sensor_type |
|---|---|
| MACHINE_001 × 5 | temp × 5 |
Hypercore არის ჰიბრიდული მწკრივ-სვეტოვანი ძრავა. ახალი მონაცემები მასში ჩვეულებრივად, მწკრივებად ინახება, რაც სწრაფ ჩაწერას (INSERT/UPDATE) უზრუნველყოფს. თუმცა, დროთა განმავლობაში, სისტემა ავტომატურად გარდაქმნის მათ შეკუმშულ სვეტოვან ფორმატში.
| column | technique | representation after compression |
|---|---|---|
| time | delta-of-delta | 12:00:00, +5s, 0, 0, 0 |
| machine_id | run-length encoding | MACHINE_001 × 5 |
| sensor_type | run-length encoding | temp × 5 |
| value | delta encoding | 72.5, +0.2, -0.3, +0.2, -0.1 |
როგორ მუშაობს შეკუმშვის ტექნოლოგია
კონვერტაციის პროცესში, 1000 მწკრივი ერთ ჯგუფად ერთიანდება. თითოეული სვეტი მასივად გარდაიქმნება, რაც ანალიტიკურ მოთხოვნებს საშუალებას აძლევს, მხოლოდ საჭირო ინფორმაცია წაიკითხოს და არა მთელი ცხრილი.
შეკუმშვისთვის გამოიყენება რამდენიმე სპეციალიზებული ალგორითმი:
- Delta encoding: ინახავს მხოლოდ წინა მონაცემთან სხვაობას.
- Delta-of-delta: იდეალურია მუდმივი ინტერვალების მქონე მონაცემებისთვის.
- Gorilla XOR: ეფექტურია მცოცავი წერტილის მქონე რიცხვებისთვის.
- Run-length encoding (RLE): იმეორებს ერთი და იმავე მნიშვნელობის მქონე მონაცემებს მხოლოდ ერთხელ.
მაგალითად, თუ სენსორი 10 წუთის განმავლობაში ერთსა და იმავე ტემპერატურას აჩვენებს, RLE მეთოდი ამ მონაცემს მინიმალურ სივრცეში ათავსებს.
სწორედ ამ მეთოდების კომბინაციით მიიღწევა მაღალი ეფექტურობა. თუმცა, მნიშვნელოვანია სწორი პარამეტრების არჩევა: segmentby განსაზღვრავს მონაცემთა დაჯგუფებას, ხოლო orderby — მათ თანმიმდევრობას შეკუმშვის პროცესში.
შედეგად, მოთხოვნები, რომლებიც იყენებენ ფილტრაციას segmentby სვეტის მიხედვით, შესაძლოა ათჯერ უფრო სწრაფად შესრულდეს. ეს არა მხოლოდ ზოგავს დისკის სივრცეს, არამედ ამცირებს ოპერატიული მეხსიერებისა და პროცესორის დატვირთვას.
უნდა გავითვალისწინოთ, რომ შეკუმშვა ყველაზე ეფექტურია მაშინ, როდესაც მონაცემთა სტრუქტურა რეგულარულია. თუ თქვენი სისტემა აგროვებს IoT მონაცემებს ან ფინანსურ ტრანზაქციებს, TimescaleDB-ის ეს ფუნქცია მნიშვნელოვნად შეამცირებს თქვენს ინფრასტრუქტურულ ხარჯებს.
| Metric | Rowstore (chunk 47, 2.3 GB) | Columnstore (chunk 46, 7.2 MB) |
|---|---|---|
| Execution time | 10.2 ms | 0.36 ms |
| Planning time | 19.0 ms | 1.9 ms |
| Total | 29.2 ms | 2.3 ms |
| Speed-up | — | ~12.7× total / 28× execution |
| Data compression ratio | — | 42.8× (308 MB → 7.2 MB) |
დისკუსია
0 კომენტარი
ჯერ კომენტარი არ არის — იყავი პირველი.