| 3 | | |
| 4 | | === 1. Анализа на поглед 1: Активен каталог на производи (v_active_product_catalog) === |
| 5 | | |
| 6 | | 1. **Примарен филтер:** Примарниот филтер за овој поглед е според `variant_id` на производот (варијантата). |
| 7 | | 2. **Случај на употреба:** Се користи за брзо пребарување на производи и приказ на нивните варијанти во реално време на почетната продавница (Catalog Listing). Перформансите се критични бидејќи ова е најчесто повикуваниот поглед од корисниците. |
| 8 | | |
| 9 | | Тест прашалникот кој се извршува е следниот: |
| 10 | | {{{ |
| 11 | | SET search_path TO myschema; |
| 12 | | SELECT * FROM v_active_product_catalog WHERE variant_id = 234; |
| 13 | | }}} |
| 14 | | |
| 15 | | ==== А. Состојба ПРЕД индексирање ==== |
| 16 | | |
| 17 | | * **Време на извршување на прашалникот (Без индекси):** |
| 18 | | **1 s 194 ms** (Execution: 445 ms, Fetching: 749 ms) |
| 19 | | |
| 20 | | * **Најбавни операции (Bottleneck Analysis):** |
| 21 | | Од визуелниот план во !DataGrip, идентификувано е дека базата троши најмногу време на: |
| 22 | | * `Access Subquery Scan` — поради потребата да се пресмета агрегацијата `SUM(ii.quantity)` од табелата `inventory_items` без соодветна поддршка за брзо филтрирање во подпрашалникот. |
| 23 | | * `Unknown (Incremental Sort)` — етапно сортирање во RAM меморијата за да се подредат податоците за потребите на `GROUP BY` клаузулата. |
| 24 | | |
| 25 | | * **Време на операциите INSERT и UPDATE (Без индекси):** |
| 26 | | Со цел да се измери иницијалната брзина на запишување пред модификациите, извршени се следните трансакции: |
| 27 | | * **INSERT:** **12 ms** (Вкупно со fetching: 387 ms) |
| 28 | | {{{ |
| 29 | | BEGIN; |
| 30 | | EXPLAIN (ANALYZE, BUFFERS) |
| 31 | | INSERT INTO inventory_items (variant_id, warehouse_id, quantity) VALUES (12, 50, 152); |
| 32 | | ROLLBACK; |
| 33 | | }}} |
| 34 | | * **UPDATE:** **13 ms** (Вкупно со fetching: 393 ms) |
| 35 | | {{{ |
| 36 | | BEGIN; |
| 37 | | EXPLAIN (ANALYZE, BUFFERS) |
| 38 | | UPDATE inventory_items SET quantity = 19 WHERE variant_id = 504; |
| 39 | | ROLLBACK; |
| 40 | | }}} |
| 41 | | |
| 42 | | |
| 43 | | ==== Б. Воведување на индекси ==== |
| 44 | | |
| 45 | | За елиминирање на скенирањата на цели подпрашалници и мемориското сортирање, воведени се следните 1-2 карактеристични индекси на надворешните клучеви: |
| 46 | | |
| 47 | | {{{ |
| 48 | | CREATE INDEX idx_v1_products_category_id ON products(category_id, product_id); |
| 49 | | CREATE INDEX idx_v1_inventory_items_variant_id ON inventory_items(variant_id); |
| 50 | | ANALYZE products; |
| 51 | | ANALYZE inventory_items; |
| 52 | | }}} |
| 53 | | |
| 54 | | |
| 55 | | ==== В. Состојба ПОСЛЕ индексирање ==== |
| 56 | | |
| 57 | | * **Ново време на извршување на прашалникот (Со индекси):** |
| 58 | | **[18ms]** |
| 59 | | *(Времето е драстично намалено во рамките на прифатливото оперативни време под 2 секунди).* |
| 60 | | |
| 61 | | * **Најбавни операции сега:** |
| 62 | | Скапите операции `Access Subquery Scan` и меморискиот `Incremental Sort` целосно исчезнуваат. Базата сега ги извршува операциите преку директен, инстантен **Index Scan** користејќи ја однапред подредената B-Tree структура. |
| 63 | | |
| 64 | | * **Ново време на операциите INSERT и UPDATE (Со индекси):** |
| 65 | | * **INSERT:** **26 ms** |
| 66 | | * **UPDATE:** **38 ms** |
| 67 | | |
| 68 | | **Заклучок за Write-Impact:** Иако времето за запишување се зголеми (од 12ms на 26ms за внесување и од 13ms на 38ms за ажурирање) поради потребата од дополнително запишување во самите индексни табели, ова зголемување е во рамки на милисекунди и е целосно прифатливо. Придобивката од забрзувањето на главниот `SELECT` прашалник го оправдува овој минимален трошок. |
| | 3 | == Документација |
| | 4 | [[html(<a href="https://develop.finki.ukim.mk/projects/BlunkBuy/attachment/wiki/">CinemaDB_Faza_3.pdf</a>)]] |
