Индекси и оптимизација на прашалници

---

Членови на тим:

• Никола Маркоски (235013)
• Шенол Фејзоски (231075)

View1: Договори по продавач (vw_contracts_per_vendor)

1. Примарен филтер за погледот vw_contracts_per_vendor ќе биде според неговото id (vendor_id на продавачот).

2. Примарен случај на употреба ќе е преглед на сите активни и историски договори за одреден продавач. За овој поглед ни се важни перформансите, бидејќи без него се губи време при извршување.

3. Иницијалното време за извршување на погледот е 5s 887ms. Ова не е прифатливо време за апликацијата па затоа пристапуваме кон индексирање.

4. Најбавната операција е full scan на табелата:

• Client_Vendor_Contract - 7k cost

Времето изминато во извршување на операциите insert и update пред индексирање изнесува:

5. По креирање на индексите:

CREATE INDEX idx_project_contract_id ON Project (contract_id);
CREATE INDEX idx_cvc_vendor_id ON Client_Vendor_Contract (vendor_id);

Забелешка: Иницијално беше разгледано и креирање на индексот idx_cvc_client_id ON Client_Vendor_Contract (client_id), меѓутоа по мерење на перформансите се утврди дека овој индекс ги влошува перформансите на сите погледи кои филтрираат по client_id, поради ниска селективност на колоната. Затоа индексот беше отстранет.

Времето изминато во извршување на query-то со индекси изнесува:

6. Времето изминато во извршување на операциите insert и update по индексирање изнесува:

---

View2: Договори по клиент (vw_contracts_per_client)

1. Примарен филтер за погледот vw_contracts_per_client ќе биде според неговото id (client_id на клиентот).

2. Примарен случај на употреба ќе е преглед на сите активни и историски договори за одреден клиент. За овој поглед ни се важни перформансите, бидејќи без него се губи време при извршување.

3. Иницијалното време за извршување на погледот е 399ms. Ова не е прифатливо време за апликацијата па затоа пристапуваме кон индексирање.

4. Најбавната операција е full scan на табелата:

• Client_Vendor_Contract - 7k cost

Времето изминато во извршување на операциите insert и update пред индексирање изнесува:

5. Иницијално беше разгледано индексирање преку idx_cvc_client_id, меѓутоа мерењата покажаа дека тој индекс го влошува времето на извршување (399ms → 4s 421ms) поради ниска селективност — колоната client_id враќа многу редови по вредност, па планерот прибегнува кон scatter reads наместо секвенцијален скен. Поради тоа, индексот беше отстранет.

Иако индексите idx_project_contract_id и idx_cvc_vendor_id од View1 се присутни, планот за извршување останува непроменет — табелата Client_Vendor_Contract сеуште се скенира секвенцијално со ист cost од 7k, бидејќи овие индекси не се применливи за филтрирање по client_id. Разликата во времето на извршување од ~100ms е во рамките на нормална варијација и не може да се припише на индексирањето. Се заклучува дека овој поглед не може да се оптимизира преку индексирање.

6. Времето на извршување на операциите insert и update останува непроменето. Забележаните разлики во мерењата се должат на надворешни фактори како cache состојба и системска активност, а не на индексирањето.

---

View3: Проекти по продавач (vw_projects_per_vendor)

1. Примарен филтер за погледот vw_projects_per_vendor ќе биде според неговото id (vendor_id на продавачот).

2. Примарен случај на употреба ќе е преглед на сите проекти поврзани со одреден продавач. За овој поглед ни се важни перформансите, бидејќи без него се губи време при извршување.

3. Иницијалното време за извршување на погледот е 445ms. Ова не е прифатливо време за апликацијата па затоа пристапуваме кон индексирање.

4. Најбавните операции се full scan на табелите:

• Project - 26k cost
• Client_Vendor_Contract - 7k cost

Времето изминато во извршување на операциите insert и update пред индексирање изнесува:

5. Иако овој поглед не е аналитички и би имал потреба од индексирање, индексите idx_project_contract_id и idx_cvc_vendor_id креирани во View1 ги покриваат потребните колони за овој поглед. Забележано е дека присуството на idx_cvc_client_id го влошуваше планот за извршување (445ms → 7s 377ms), па по негово отстранување перформансите се вратени и понатаму подобрени. Времето изминато во извршување на query-то изнесува:

6. Времето изминато во извршување на операциите insert и update по индексирање изнесува:

---

View4: Проекти по клиент (vw_projects_per_client)

1. Примарен филтер за погледот vw_projects_per_client ќе биде според неговото id (client_id на клиентот).

2. Примарен случај на употреба ќе е преглед на сите проекти поврзани со одреден клиент. За овој поглед ни се важни перформансите, бидејќи без него се губи време при извршување.

3. Иницијалното време за извршување на погледот е 626ms. Ова не е прифатливо време за апликацијата па затоа пристапуваме кон индексирање.

4. Најбавните операции се full scan на табелите:

• Project - 26k cost
• Client_Vendor_Contract - 7k cost

Времето изминато во извршување на операциите insert и update пред индексирање изнесува:

5. Иницијално беше разгледано индексирање преку idx_cvc_client_id, меѓутоа мерењата покажаа дека тој индекс го влошува времето на извршување (626ms → 2s 636ms) поради ниска селективност на client_id колоната. По отстранување на тој индекс, перформансите на овој поглед се подобрени преку индексите idx_project_contract_id и idx_cvc_vendor_id креирани во View1. Времето изминато во извршување на query-то изнесува:

6. Времето изминато во извршување на операциите insert и update по индексирање изнесува:

---

View5: Клиенти по индустрија (vw_clients_per_industry)

1. Примарен филтер за погледот vw_clients_per_industry ќе биде според неговото id (industry_id на индустријата).

2. Примарен случај на употреба ќе е преглед на сите клиенти кои припаѓаат на одредена индустрија. За овој поглед ни се важни перформансите, бидејќи без него се губи време при извршување.

3. Иницијалното време за извршување на погледот е 94ms. Иако на прв поглед ова изгледа прифатливо, беше разгледано дали индексирање би го подобрило времето.

Времето изминато во извршување на операциите insert и update изнесува:

4. По тестирање на индексот idx_client_industry_id ON Client (industry_id), мерењата покажаа дека индексот го влошува времето на извршување (94ms → 1s 166ms). Табелата Client е доволно мала (500 cost) за планерот да претпочита секвенцијален скен. Поради тоа, индексот беше отстранет и се заклучува дека нема потреба од индексирање за овој поглед.

5. Нема потреба да се преуреди прашалникот.

6. Времето на извршување на операциите останува исто.

---

View6: Нерешени тикети за спорови (vw_unresolved_dispute_tickets)

1. Примарен филтер за погледот vw_unresolved_dispute_tickets ќе биде според project_id на проектот или assigned_management_user_id на корисникот.

2. Примарен случај на употреба ќе е преглед на сите активни нерешени тикети за спорови доделени на одреден менаџмент корисник или поврзани со одреден проект. За овој поглед ни се важни перформансите, бидејќи без него се губи време при извршување.

3. Иницијалното време за извршување на погледот е 731ms. Ова не е прифатливо време за апликацијата па затоа пристапуваме кон индексирање.

4. Најбавната операција е full scan на табелата:

• Dispute_Ticket - 9k cost

Времето изминато во извршување на операциите insert и update пред индексирање изнесува:

5. По креирање на индексите:

CREATE INDEX idx_dispute_ticket_review_id ON Dispute_Ticket (review_id);
CREATE INDEX idx_dispute_ticket_is_resolved ON Dispute_Ticket (is_resolved);

Времето изминато во извршување на query-то со индекси изнесува (731ms → 194ms):

6. Времето изминато во извршување на операциите insert и update по индексирање изнесува:

---

View7: Претплати на продавачи (vw_vendor_subscriptions)

1. Примарен филтер за погледот vw_vendor_subscriptions ќе биде според неговото id (vendor_id на продавачот).

2. Примарен случај на употреба ќе е преглед на активните и историските претплати за одреден продавач. За овој поглед ни се важни перформансите, бидејќи без него се губи време при извршување.

3. Иницијалното време за извршување на погледот е 37ms. Ова е прифатливо време за апликацијата, па затоа нема потреба од индексирање.

Времето изминато во извршување на операциите insert и update изнесува:

4. Нема потреба да се преуреди прашалникот.

5. Времето на извршување на операциите останува исто.

---

View8: Просечна оценка по продавач (vw_avg_rating_per_vendor)

1. Примарен филтер за погледот vw_avg_rating_per_vendor ќе биде според неговото id (vendor_id на продавачот).

2. Примарен случај на употреба ќе е преглед на просечната оценка на секој продавач врз основа на рецензии од проекти. Овој поглед е аналитички по природа (пресметува агрегатни вредности со AVG и COUNT) и не бара директно индексирање. Сепак, перформансите на овој поглед се подобрени поради индексирањето применето во View1.

3. Иницијалното време за извршување на погледот е 1m 24s 217ms.

4. Иако овој поглед е аналитички и не бара директно индексирање, перформансите се подобрени поради индексите idx_project_contract_id и idx_cvc_vendor_id креирани во View1. Времето изминато во извршување на query-то по индексирање изнесува:

5. Времето на извршување на операциите insert и update останува непроменето бидејќи не се додадени нови индекси во овој поглед.

---

View9: Вкупен буџет по клиент (vw_budget_per_client)

1. Примарен филтер за погледот vw_budget_per_client ќе биде според неговото id (client_id на клиентот).

2. Примарен случај на употреба ќе е преглед на вкупниот буџет потрошен по клиент низ сите проекти и договори. Овој поглед е аналитички по природа (пресметува агрегатни вредности со SUM и COUNT) и не бара директно индексирање.

3. Иницијалното време за извршување на погледот е 320ms.

4. Иако овој поглед е аналитички и не бара директно индексирање, перформансите се подобрени поради индексите idx_project_contract_id и idx_cvc_vendor_id креирани во View1. Времето изминато во извршување на query-то по индексирање изнесува:

6. Времето на извршување на операциите insert и update останува непроменето бидејќи не се додадени нови индекси за овој поглед.

---

View10: Вкупен буџет по продавач (vw_budget_per_vendor)

1. Примарен филтер за погледот vw_budget_per_vendor ќе биде според неговото id (vendor_id на продавачот).

2. Примарен случај на употреба ќе е преглед на вкупниот буџет потрошен по продавач низ сите проекти и договори. Овој поглед е аналитички по природа (пресметува агрегатни вредности со SUM и COUNT) и не бара директно индексирање. Сепак, перформансите на овој поглед се подобрени поради индексирањето применето во View1.

3. Иницијалното време за извршување на погледот е 319ms.

4. Иако овој поглед е аналитички и не бара директно индексирање, перформансите се подобрени поради индексите idx_project_contract_id и idx_cvc_vendor_id креирани во View1. Времето изминато во извршување на query-то по индексирање изнесува:

5. Времето на извршување на операциите insert и update останува непроменето бидејќи не се додадени нови индекси за овој поглед.

---

View11: Број на проекти по статус по клиент (vw_project_count_by_status_per_client)

1. Примарен филтер за погледот vw_project_count_by_status_per_client ќе биде според неговото id (client_id на клиентот).

2. Примарен случај на употреба ќе е преглед на бројот на проекти групирани по статус за одреден клиент. Овој поглед е аналитички по природа (пресметува агрегатни вредности со COUNT и GROUP BY) и не бара директно индексирање.

3. Иницијалното времe за извршување на погледот е 317ms.

4. Иако овој поглед е аналитички и не бара директно индексирање, перформансите се подобрени поради индексите idx_project_contract_id и idx_cvc_vendor_id креирани во View1. Времето изминато во извршување на query-то по индексирање изнесува:

5. Времето на извршување на операциите insert и update останува непроменето бидејќи не се додадени нови индекси за овој поглед.

---

View12: Број на проекти по статус по продавач (vw_project_count_by_status_per_vendor)

1. Примарен филтер за погледот vw_project_count_by_status_per_vendor ќе биде според неговото id (vendor_id на продавачот).

2. Примарен случај на употреба ќе е преглед на бројот на проекти групирани по статус за одреден продавач. Овој поглед е аналитички по природа (пресметува агрегатни вредности со COUNT и GROUP BY) и не бара директно индексирање. Сепак, перформансите на овој поглед се променети поради индексирањето применето во View1.

3. Иницијалното време за извршување на погледот е 317ms.

4. Иако овој поглед е аналитички и не бара директно индексирање, перформансите се променети поради индексите idx_project_contract_id и idx_cvc_vendor_id креирани во View1. Времето изминато во извршување на query-то по индексирање изнесува:

5. Тука може да се забележи дека перформансите се 'полоши' после индексирање, но бидејќи погледот е аналитички, и истите индекси ги подобрија повеќето од другите погледи, не правиме промени.

6. Времето на извршување на операциите insert и update останува непроменето бидејќи не се додадени нови индекси за овој поглед.