Query Optimization

View 1: Live offers for customer

1. Примарен случај на употреба на овој поглед е за добивање на моменталните активни понуди за еден корисник при побарување на такси.

2. Примарен филтер за овој поглед е атрибутот customer_id во релацијата offer

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

Ова време е задоволително (помало од 3 секунди), па затоа не е потребно да се извршува оптимизирање на прашалникот.

4. Нема потреба од правење на план за извршување поради тоа што времето е задоволително.

5. Иницијалното време за insert и update во табелата offer е:

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

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

View 2: Available drivers

1. Примарен случај на употреба на овој поглед е за добивање на слободните возачи во моментот за дадена компанија.

2. Примарен филтер за овој поглед е атрибутот company_id во релацијата employmenthistory.

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

Ова време не е прифатливо за нашата апликација, па затоа пристапуваме кон индексизање за оптимизација на прашалникот

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

5. Иницијалното време на insert и update во ride и driver_vehicle е:

6. Времето потребно за извршување на прашалникот после вметнување на индекс на customerpreferences по атрибутот company_id изнесува 629ms што е прифатливо време:

7. Времето потребно за извршување на insert и update во ride и driver_vehicle изнесува:

View 3: Unassigned requests

1. Примарен случај на употреба овој поглед ќе се користи за добивање на недоделените барања за такси од страна на компаниите во зависност од преференците на корисниците.

2. Примарен филтер би бил атрибутот company_id во customerpreference релацијата.

3. Иницијалното извршување на погледот е 5s и 109ms:

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

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

5. Иницијалното време на insert и update на табелата requests е:

6. Времето потребно за извршување на прашалникот после вметнување на индекс на customerpreferences по атрибутот company_id изнесува 2s 446ms што може да се подобри со преуредување на прашалникот:

7. Времето потребно за извршување на insert и update во request после индексирање:

8. И покрај тоа што се справивме со full scan на табелата ride сеуште времето е незадоволително. Па затоа за подобрување на перформансите прашалникот може да се реструктуира така што ќе се користи limit и offset за имплементација на пагинација при користење на апликацијата:

Овој поглед во иднина ќе биде оптимизиран со помош на PostGIS така што ќе се земаат само барања кои припаѓаат во рамките на полигоните на областите од интерес на компаниите и бројот на редици ќе се намали, а со тоа и потребното време за извршување.

View 4: Customer payments for rides

1. Примарен случај на употреба на погледот customer_payments_ride е добивање на извештај за сите уплати за возења кои еден корисник ги извршил.

2. Примарен филтер за овој поглед е атрибутот user_id од релацијата Customer.

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

4. Времето на извршување е задоволително и нема потреба од дополнително оптимизирање. Се зема во предвид и фактот дека корисниците кои ќе ја користат апликацијата најверојатно ретко ќе бараат увид во сите нивни плаќања.

5. Иницијално време на внес на нов запис во табелата Payment е 461ms.

6. Сметаме дека времето е доволно брзо за insert операција во табелата Payment, од таа причина нема потреба од индексирање.

View 5: Reviews on drivers

1. Примарен случај на употреба на погледот reviews_on_drivers е добивање на преглед на сите оценки и коментари кои биле оставени за еден возач.

2. Примарен филтер на овој поглед е атрибутот user_id од релацоијата Driver.

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

4. Времето на извршување е задоволително и нема потреба од дополнително оптимизирање.

5. Иницијално време за внес на нови вредности во табелата Review e 725ms.

6. Ова време е прифатливо за корисниците кои за едно возење смеат да остават само еден review.

View 6: Reports on drivers during rides

1. Примарен случај на употреба на погледот reports_on_drivers_rides е добивање на преглед на пријави поднесени од патници за возачите.

2. Примарен филтер над овој поглед е атрибутот user_id од ентитетот Driver.

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

4. Времето го сметаме за задоволително. Се зема во предвид дека доколку се додаде индекс, индексот е структура која дополнително зафаќа простор и при тоа ги успорува операциите како што се insert и update. Операцијата insert во табелата Report треба да биде брза според функционалноста која ја нуди апликацијата.

5. Иницијално времето на внес на нов запис-пријава во табелата Report e 100ms.

6. Ова време е идеално за ситуацијата, бидејќи репортите се пријави кои корисниците можат да ги поднесат за време на возењето и истите треба да бидат брзо внесени во системот.

View 7: Live ride monitor

1. Примарен филтер за погледот vw_live_ride_monitor ќе биде според id на компанија (company_id), со цел компаниите да можат да ги следат само нивните активни возења.

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

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

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

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

5. Времето изминато во извршување на query-то со индекси изнесува 1s 430ms, и тоа е прифатливо време.

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

View 8: User message driver

1. Примарен филтер за погледот user_message_driver ќе биде според id на клиент (user_id), id на возач (driver_id) или id на патување (ride_id), со цел да се филтрираат пораките за конкретна сесија или конкретен корисник.

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

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

4. Нема потреба од правење на план за извршување поради тоа што времето е задоволително.

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

View 9: Active ride vehicle details

1. Примарен филтер за погледот vw_active_ride_vehicle_details ќе биде според customer_user_id (id-то на патникот) или според ride_id (id-то на самото возење).

2. Примарен случај на употреба е екранот за следење на активното возење на корисникот (live-tracking), каде што патникот ги гледа моделот, брендот, регистарската табличка и проценетото време на пристигнување (ETA) на возилото кое доаѓа да го земе. За овој поглед перформансите се од критична важност, бидејќи се повикува често од страна на апликацијата додека возењето е со статус in_progress и не смее да има доцнење.

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

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

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

5. Времето изминато во извршување на query-то со индекси изнесува 746ms, и тоа е прифатливо време.

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