Hamıya salam! Mən Java + Spring-də mikroservislər yazan backend developerəm. Mən Tinkoff-da daxili məhsul inkişaf qruplarından birində işləyirəm.
Komandamızda DBMS-də sorğuların optimallaşdırılması məsələsi tez-tez yaranır. Həmişə bir az daha sürətli olmaq istəyirsiniz, lakin düşünülmüş şəkildə qurulmuş indekslərlə hər zaman məşğul ola bilməzsiniz - bəzi həll yolları axtarmalısınız. Verilənlər bazası ilə işləyərkən ağlabatan optimallaşdırmalar axtarmaq üçün internetdə gəzintilərdən birində tapdım , SQL Performance Explained kitabının müəllifi. Bu, ard-arda bütün məqalələri oxuya biləcəyiniz nadir blog növüdür.
Mən sizin üçün Markusun qısa məqaləsini tərcümə etmək istərdim. Onu müəyyən dərəcədə SQL standartına uyğun ofset əməliyyatının yerinə yetirilməsinin köhnə, lakin hələ də aktual probleminə diqqəti cəlb etməyə çalışan manifest adlandırmaq olar.
Bəzi yerlərdə müəllifi izahat və şərhlərlə tamamlayacağam. Mən bütün belə yerlərə “təqribən” kimi istinad edəcəyəm. daha aydınlıq üçün
Kiçik giriş
Düşünürəm ki, çoxları ofset vasitəsilə səhifə seçimləri ilə işləməyin nə qədər problemli və ləng olduğunu bilir. Onun daha səmərəli dizaynla olduqca asanlıqla əvəz oluna biləcəyini bilirdinizmi?
Beləliklə, ofset açar sözü verilənlər bazasına sorğuda ilk n qeydi atlamağı əmr edir. Bununla belə, verilənlər bazası hələ də diskdən bu ilk n qeydi verilmiş ardıcıllıqla oxumalıdır (qeyd: əgər göstərilibsə çeşidləmə tətbiq edilir) və yalnız bundan sonra n+1-dən sonra qeydləri qaytarmaq mümkün olacaq. Ən maraqlısı odur ki, problem DBMS-də konkret tətbiqdə deyil, standarta uyğun olaraq orijinal tərifdədir:
…sətirlər əvvəlcə aşağıdakılara görə sıralanır və sonra göstərilən sətirlərin sayını azaltmaqla məhdudlaşdırılır başdan…
-SQL:2016, Hissə 2, 4.15.3 Alınan cədvəllər (qeyd: hazırda ən çox istifadə olunan standartdır)
Burada əsas məqam ondan ibarətdir ki, ofset tək bir parametr götürür - ötürüləcək qeydlərin sayı, vəssalam. Bu tərifdən sonra DBMS yalnız bütün qeydləri götürə və sonra lazımsız olanları silə bilər. Aydındır ki, ofsetin bu tərifi bizi əlavə iş görməyə məcbur edir. Və bunun SQL və ya NoSQL olmasının heç bir əhəmiyyəti yoxdur.
Bir az daha ağrı
Ofsetlə bağlı problemlər bununla bitmir və bunun səbəbi budur. Əgər diskdən məlumatın iki səhifəsini oxumaq arasında başqa bir əməliyyat yeni bir qeyd daxil edərsə, bu halda nə baş verəcək?
Əvvəlki səhifələrdən qeydləri ötürmək üçün ofsetdən istifadə edildikdə, müxtəlif səhifələrin oxunuşları arasında yeni rekord əlavə etmək vəziyyətində, çox güman ki, dublikatlar əldə edəcəksiniz (qeyd: bu, quruluşa görə sıradan istifadə edərək səhifə-səhifə oxuduqda mümkündür, sonra çıxışımızın ortasında yeni bir giriş əldə edə bilər).
Şəkil bu vəziyyəti aydın şəkildə təsvir edir. Baza ilk 10 qeydi oxuyur, bundan sonra bütün oxunmuş qeydləri 1-ə əvəz edən yeni rekord daxil edilir. Sonra baza növbəti 10 qeyddən yeni səhifə götürür və lazım olduğu kimi 11-dən deyil, 10-dən başlayır. XNUMX-cu, bu rekordu təkrarlayır. Bu ifadənin istifadəsi ilə əlaqəli başqa anomaliyalar var, lakin bu, ən çox yayılmışdır.
Artıq aşkar etdiyimiz kimi, bunlar konkret DBMS və ya onların tətbiqi problemləri deyil. Problem SQL standartına uyğun olaraq səhifələşdirmənin müəyyən edilməsindədir. Biz DBMS-ə hansı səhifənin gətiriləcəyini və ya neçə qeydin keçəcəyini bildiririk. Verilənlər bazası sadəcə belə bir sorğunu optimallaşdıra bilmir, çünki bunun üçün çox az məlumat var.
Həmçinin aydınlaşdırmağa dəyər ki, bu, konkret açar sözlə deyil, sorğunun semantikası ilə bağlı problemdir. Problemli təbiətinə görə eyni olan daha bir neçə sintaksis var:
- Ofset açar sözü əvvəllər qeyd edildiyi kimidir.
- Limitin iki açar sözündən ibarət konstruksiyası [ofset] (baxmayaraq ki, limitin özü o qədər də pis deyil).
- Sətir nömrələmə əsasında aşağı sərhədlər üzrə filtrləmə (məsələn, sətir_nömrəsi(), sıra nömrəsi və s.).
Bütün bu ifadələr sadəcə olaraq sizə neçə sətir keçməyinizi bildirir, əlavə məlumat və ya kontekst yoxdur.
Bu məqalənin sonrakı hissəsində ofset açar sözü bütün bu seçimlərin xülasəsi kimi istifadə olunur.
OFFSET olmadan həyat
İndi bütün bu problemlər olmadan dünyamızın necə olacağını təsəvvür edək. Məlum oldu ki, ofsetsiz həyat o qədər də çətin deyil: bir seçim ilə harada bir şərtdən istifadə edərək, yalnız hələ görmədiyimiz cərgələri (qeyd: əvvəlki səhifədə olmayanları) seçə bilərsiniz.
Bu vəziyyətdə, seçimlərin sifarişli dəstdə (yaxşı köhnə sifariş) yerinə yetirilməsindən başlayırıq. Sifarişli dəstimiz olduğundan, yalnız əvvəlki səhifənin son qeydinin arxasında olan məlumatları əldə etmək üçün kifayət qədər sadə filtrdən istifadə edə bilərik:
SELECT ...
FROM ...
WHERE ...
AND id < ?last_seen_id
ORDER BY id DESC
FETCH FIRST 10 ROWS ONLYBu yanaşmanın bütün prinsipi budur. Əlbəttə ki, bir çox sütuna görə çeşidləyərkən işlər daha əyləncəli olur, lakin ideya hələ də eynidir. Qeyd etmək lazımdır ki, bu dizayn çoxları üçün uyğundur - qərarlar.
Bu yanaşma axtarış metodu və ya açar dəstlərin səhifələnməsi adlanır. O, üzən nəticə problemini həll edir (qeyd: əvvəllər təsvir edilmiş səhifə oxunuşları arasında yazı ilə bağlı vəziyyət) və əlbəttə ki, hamımızın sevdiyi şey klassik ofsetdən daha sürətli və daha sabit işləyir. Sabitlik ondan ibarətdir ki, sorğunun emal müddəti tələb olunan cədvəlin sayına mütənasib olaraq artmır (qeyd: səhifələşdirməyə müxtəlif yanaşmaların işi haqqında daha çox öyrənmək istəyirsinizsə, . Orada müxtəlif üsullar üçün müqayisəli meyarları da tapa bilərsiniz).
Slaydlardan biri açarlarla səhifələmə, əlbəttə ki, hər şeyə qadir deyil - onun məhdudiyyətləri var. Ən əhəmiyyətlisi onun təsadüfi səhifələri oxumaq qabiliyyətinin olmamasıdır (qeyd: uyğunsuz). Bununla belə, sonsuz sürüşmə dövründə (qeyd: ön tərəfdə) bu, belə bir problem deyil. Klikləmək üçün səhifə nömrəsinin göstərilməsi hər halda UI dizaynında pis qərardır (qeyd: məqalə müəllifinin rəyi).
Bəs alətlər?
Bu metod üçün instrumental dəstəyin olmaması səbəbindən düymələrdə səhifələmə çox vaxt uyğun deyil. Əksər inkişaf alətləri, o cümlədən müxtəlif çərçivələr, səhifələşdirmənin necə həyata keçiriləcəyini dəqiq seçməyə imkan vermir.
Vəziyyəti təsvir olunan metodun istifadə olunan texnologiyalarda - DBMS-dən sonsuz sürüşmə ilə brauzerdə AJAX sorğusunun yerinə yetirilməsinə qədər hərtərəfli dəstəyi tələb etməsi ilə daha da ağırlaşır. Yalnız səhifə nömrəsini göstərmək əvəzinə, indi bütün səhifələr üçün bir anda düymələr dəstini təyin etməlisiniz.
Bununla belə, düymələrdə səhifələşdirməni dəstəkləyən çərçivələrin sayı getdikcə artır. Hazırda əlimizdə olan budur:
- Java üçün;
- Ruby üçün;
- и Django üçün;
- Python üçün;
- — JPA tətbiqləri üçün API meyarları;
- Perl üçün;
- , Node.js üçün xəritəçi .
(Qeyd: tərcümə zamanı bəzi kitabxanalar 2017-2018-ci ildən yenilənmədiyi üçün bəzi keçidlər silinmişdir. Maraqlananlar orijinal mənbəyə baxa bilərsiniz.)
Məhz bu anda sizin köməyinizə ehtiyac var. Əgər siz səhifələşdirmədən hər hansı istifadə edən çərçivə hazırlayır və ya dəstəkləyirsinizsə, onda mən xahiş edirəm, xahiş edirəm, açarlarda səhifələmə üçün yerli dəstək göstərməyinizi xahiş edirəm. Suallarınız və ya köməyə ehtiyacınız varsa, kömək etməkdən məmnun olaram (, , ) (qeyd: Marcus ilə təcrübəmdən deyə bilərəm ki, o, həqiqətən də bu mövzunu yaymaqda həvəslidir).
Düymələrlə səhifələşdirmə üçün dəstəyə layiq olduğunu düşündüyünüz hazır həllərdən istifadə edirsinizsə, sorğu yaradın və ya hətta mümkünsə, hazır həll təklif edin. Bu məqaləyə də keçid edə bilərsiniz.
Nəticə
Düymələrlə səhifələmə kimi sadə və faydalı yanaşmanın geniş yayılmamasının səbəbi onun texniki cəhətdən həyata keçirilməsinin çətin olması və ya hər hansı böyük səy tələb etməsi deyil. Əsas səbəb odur ki, çoxları görməyə və ofsetlə işləməyə öyrəşiblər - bu yanaşma standartın özü tərəfindən diktə edilir.
Nəticədə, az adam səhifələşdirməyə yanaşmanı dəyişdirməyi düşünür və buna görə də çərçivələr və kitabxanalardan instrumental dəstək zəif inkişaf edir. Buna görə də, ofsetsiz səhifələşdirmə ideyası və məqsədi sizə yaxındırsa, onun yayılmasına kömək edin!
Mənbə:
Müəllif: Markus Winand
Mənbə: www.habr.com