Changes between Version 18 and Version 19 of QueryOptimization


Ignore:
Timestamp:
06/12/26 15:19:09 (4 days ago)
Author:
231093
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • QueryOptimization

    v18 v19  
    1621626. Ова време е идеално за ситуацијата, бидејќи репортите се пријави кои корисниците можат да ги поднесат за време на возењето и истите треба да бидат брзо внесени во системот.
    163163
    164 
     164== View 7: Live ride monitor
     165
     1661. Примарен филтер за погледот vw_live_ride_monitor ќе биде според id на компанија (company_id), со цел компаниите да можат да ги следат само нивните активни возења, а уште ќе се користи и според име на возач
     167
     1682. Примарен случај на употреба ќе е следење на сите активни возења во реално време (live monitoring) од страна на такси компаниите. За овој поглед ни се исклучително важни перформансите, бидејќи без него се губи време при извршување и се губи ефектот на „реално време“.
     169
     1703. Иницијалното време за извршување на погледот е 12 s 477 ms. Ова не е прифатливо време за апликацијата па затоа пристапуваме кон индексирање.
     171
     172[[Image(advdb 1.png, width=820px)]]
     173
     1744. Најбавната операција е full scan на табела ride.
     175
     176[[Image(advdb 2.png, width=820px)]]
     177
     178и таа може да се подобри со индекси. Времето изминато во извршување на операциите insert и update изнесувa:
     179
     180[[Image(advdb 3.png, width=820px)]]
     181
     1825. Времето изминато во извршување на query-то со индекси изнесува 1s 430ms, и тоа е прифатливо време.
     183
     184[[Image(advdb 4.png, width=820px)]]
     185[[Image(advdb 5.png, width=820px)]]
     186[[Image(advdb 6.png, width=820px)]]
     187
     1886. Времето изминато во извршување на операциите insert и update по индексирање изнесува:
     189[[Image(advdb 7.png, width=820px)]]
     190
     191== View 8: User message driver
     192
     1931. Примарен филтер за погледот user_message_driver ќе биде според id на клиент (user_id), id на возач (driver_id) или id на патување (ride_id), со цел да се филтрираат пораките за конкретна сесија или конкретен корисник.
     194
     1952. Примарен случај на употреба ќе е вчитување и приказ на историјата на пораки испратени од клиентот до возачот за време на активно возење (chat функционалност во самата апликација). За овој поглед ни се исклучително важни перформансите, бидејќи секое доцнење при вчитувањето на пораките директно го нарушува корисничкото искуство за комуникација во реално време (real-time chat).
     196
     1973. Иницијалното време за извршување на погледот е 1s 260ms. Ова е прифатливо време за апликацијата.
     198
     199[[Image(advdb 10.png, width=820px)]]
     200
     2014. Најбавните операции се full scan на chatmessage табелата и тие можат да се подобрат со индекси.
     202
     203[[Image(advdb 11.png, width=820px)]]
     204
     205Времето изминато во извршување на операциите insert и update изнесува
     206
     207[[Image(advdb 12.png, width=820px)]]
     208[[Image(advdb 13.png, width=820px)]]
     209
     2105. Времето изминато во извршување на query-то со индекси изнесува 346ms, и тоа е прифатливо време.
     211
     212[[Image(advdb 14.png, width=820px)]]
     213[[Image(advdb 15.png, width=820px)]]
     214[[Image(advdb 16.png, width=820px)]]
     215
     2166. Времето изминато во извршување на операциите insert и update по индексирање изнесува:
     217
     218[[Image(advdb 17.png, width=820px)]]
     219[[Image(advdb 18.png, width=820px)]]
     220
     221== View 9: Active ride vehicle details
     222
     2231. Примарен филтер за погледот vw_active_ride_vehicle_details ќе биде според customer_user_id (id-то на патникот) или според ride_id (id-то на самото возење).
     224
     2252. Примарен случај на употреба е екранот за следење на активното возење на корисникот (live-tracking), каде што патникот ги гледа моделот, брендот, регистарската табличка и проценетото време на пристигнување (ETA) на возилото кое доаѓа да го земе. За овој поглед перформансите се од критична важност, бидејќи се повикува често од страна на апликацијата додека возењето е со статус in_progress и не смее да има доцнење.
     226
     2273. Иницијалното време за извршување на погледот е 5 s 754 ms. Ова не е прифатливо време за апликацијата па затоа пристапуваме кон индексирање.
     228
     229[[Image(advdb 19.png, width=820px)]]
     230
     2314. Најбавната операција е full scan на табелата ride
     232
     233[[Image(advdb 20.png, width=820px)]]
     234
     235и таа може да се подобри со индекси. Времето изминато во извршување на операциите insert и update изнесувa.
     236
     237[[Image(advdb 21.png, width=820px)]]
     238
     2395. Времето изминато во извршување на query-то со индекси изнесува 746ms, и тоа е прифатливо време.
     240
     241[[Image(advdb 22.png, width=820px)]]
     242[[Image(advdb 23.png, width=820px)]]
     243[[Image(advdb 24.png, width=820px)]]
     244
     2456. Времето изминато во извршување на операциите insert и update по индексирање изнесува:
     246
     247[[Image(advdb 25.png, width=820px)]]