Сайн уу! Би Java + Spring дээр бичил үйлчилгээ бичдэг backend хөгжүүлэгч юм. Би Tinkoff дахь дотоод бүтээгдэхүүн хөгжүүлэлтийн багуудын нэгэнд ажилладаг.
Манай багт DBMS дахь асуулга оновчтой болгох асуулт байнга гарч ирдэг. Та үргэлж бага зэрэг хурдан байхыг хүсдэг, гэхдээ сайтар боловсруулсан индексүүдээр үргэлж амжилтанд хүрч чадахгүй - та зарим нэг тойрон гарах арга замыг хайх хэрэгтэй. Өгөгдлийн сантай ажиллахдаа боломжийн оновчлолыг хайж интернетээр тэнүүчлэхдээ би олж мэдсэн , SQL Performance Explained номын зохиогч. Энэ бол та бүх нийтлэлийг дараалан унших боломжтой ховор төрлийн блог юм.
Би танд Маркусын богино өгүүллийг орчуулахыг хүсч байна. Үүнийг SQL стандартын дагуу офсет үйлдлийн гүйцэтгэлийн хуучин боловч хамааралтай асуудалд анхаарлаа хандуулахыг зорьсон манифест гэж нэрлэж болно.
Зарим газарт би зохиогчийг тайлбар, тайлбараар нэмж оруулах болно. Би ийм бүх газрыг "ойролцоогоор" гэж нэрлэх болно. илүү тодорхой болгохын тулд
Жижиг танилцуулга
Офсетээр хуудас сонгох нь ямар асуудалтай, удаан ажилладгийг олон хүн мэддэг гэж бодож байна. Үүнийг илүү үр ашигтай загвараар хялбархан сольж болно гэдгийг та мэдэх үү?
Тиймээс, офсет түлхүүр үг нь мэдээллийн санд хүсэлтийн эхний n бичлэгийг алгасахыг хэлдэг. Гэсэн хэдий ч өгөгдлийн сан нь эдгээр эхний n бичлэгийг өгөгдсөн дарааллаар дискнээс унших шаардлагатай хэвээр байна (тэмдэглэл: хэрэв зааж өгсөн бол эрэмбэлэх хэрэгтэй), зөвхөн дараа нь n+1-ээс хойш бичлэгийг буцаах боломжтой болно. Хамгийн сонирхолтой зүйл бол асуудал нь DBMS дахь тодорхой хэрэгжилтэд биш, харин стандартын дагуу анхны тодорхойлолтод байгаа юм.
…мөрүүдийг эхлээд эрэмбэлж дараа нь -д заасан мөрийн тоог эхнээс нь хасах замаар хязгаарлана...
-SQL:2016, 2-р хэсэг, 4.15.3 Үүсмэл хүснэгтүүд (тэмдэглэл: одоогоор хамгийн их ашиглагддаг стандарт)
Энд гол зүйл бол офсет нь нэг параметрийг авдаг - алгасах бичлэгийн тоо, тэгээд л болоо. Энэ тодорхойлолтыг дагаснаар DBMS нь зөвхөн бүх бүртгэлийг сэргээж, шаардлагагүйг нь устгаж болно. Оффсетийн энэхүү тодорхойлолт нь биднийг нэмэлт ажил хийхийг албаддаг нь ойлгомжтой. Энэ нь SQL эсвэл NoSQL эсэх нь хамаагүй.
Жаахан илүү өвдөлт
Оффсетийн асуудал үүгээр дуусдаггүй бөгөөд яагаад гэдгийг эндээс харна уу. Хэрэв дискнээс хоёр хуудас өгөгдлийг унших хооронд өөр үйлдэл шинэ бичлэг оруулбал энэ тохиолдолд юу болох вэ?
Өмнөх хуудсуудын бичлэгийг алгасахын тулд офсетийг ашиглах үед өөр өөр хуудсуудыг унших хооронд шинэ бичлэг нэмэх тохиолдолд та давхардсан байх магадлалтай (тэмдэглэл: энэ нь бид дарааллаар нь дарааллаар нь хуудас унших үед боломжтой, дараа нь бидний гаралтын дунд энэ нь шинэ оруулга авч болно).
Зураг нь энэ байдлыг тодорхой харуулж байна. Суурь нь эхний 10 бичлэгийг уншсаны дараа шинэ бичлэг оруулах бөгөөд энэ нь уншсан бүх бичлэгийг 1-ээр нөхдөг. Дараа нь суурь нь дараагийн 10 бичлэгээс шинэ хуудас авч, байх ёстой 11-ээс биш, харин 10, энэ рекордыг давхардуулж байна. Энэ илэрхийлэлийг ашиглахтай холбоотой бусад гажиг байдаг боловч энэ нь хамгийн түгээмэл зүйл юм.
Бидний олж мэдсэнээр эдгээр нь тодорхой DBMS эсвэл тэдгээрийн хэрэгжилтийн асуудал биш юм. Асуудал нь SQL стандартын дагуу хуудаслалыг тодорхойлоход оршино. Бид DBMS-д аль хуудсыг дуудах эсвэл хэдэн бичлэг алгасахыг хэлдэг. Мэдээллийн сан нь ийм хүсэлтийг оновчтой болгох боломжгүй, учир нь энэ талаар хэтэрхий бага мэдээлэл байна.
Энэ нь тодорхой түлхүүр үгтэй холбоотой асуудал биш, харин асуулгын семантиктай холбоотой гэдгийг тодруулах нь зүйтэй. Асуудлын шинж чанараараа ижил төстэй хэд хэдэн синтакс байдаг:
- Офсет түлхүүр үг нь өмнө дурдсанчлан байна.
- Хоёр түлхүүр үгийн бүтэц хязгаар [офсет] (хэдийгээр хязгаар нь өөрөө тийм ч муу биш).
- Мөрийн дугаарлалт (жишээ нь, row_number(), rownum гэх мэт) дээр үндэслэн доод хязгаараар шүүх.
Эдгээр бүх илэрхийлэл нь танд хэдэн мөр алгасах, ямар ч нэмэлт мэдээлэл, контекстийг хэлэх болно.
Энэ өгүүллийн сүүлд офсет түлхүүр үгийг эдгээр бүх сонголтуудын хураангуй болгон ашигласан болно.
OFSET-гүй амьдрал
Одоо энэ бүх асуудалгүйгээр манай дэлхий ямар байхыг төсөөлцгөөе. Оффсетгүй амьдрал тийм ч хэцүү биш болох нь харагдаж байна: Сонголтоор та зөвхөн бидний хараахан хараагүй мөрүүдийг (тэмдэглэл: өмнөх хуудсанд байгаагүй мөрүүдийг) хаана байх нөхцөлийг ашиглан сонгож болно.
Энэ тохиолдолд бид сонголтуудыг захиалгат багц (хуучин сайн захиалга) дээр гүйцэтгэдэг гэдгээс эхэлнэ. Бидэнд захиалгат багц байгаа тул бид өмнөх хуудасны сүүлийн бичлэгийн ард байгаа өгөгдлийг авахын тулд маш энгийн шүүлтүүр ашиглаж болно:
SELECT ...
FROM ...
WHERE ...
AND id < ?last_seen_id
ORDER BY id DESC
FETCH FIRST 10 ROWS ONLYЭнэ бол энэ аргын бүх зарчим юм. Мэдээжийн хэрэг, олон баганаар эрэмбэлэх үед бүх зүйл илүү хөгжилтэй болдог, гэхдээ санаа нь хэвээр байна. Энэ загвар нь олон хүмүүст хамааралтай гэдгийг анхаарах нь чухал юм - шийдвэрүүд.
Энэ аргыг хайх арга буюу түлхүүрийн хуудасны хуудас гэж нэрлэдэг. Энэ нь хөвөгч үр дүнгийн асуудлыг шийддэг (тэмдэглэл: хуудасны хооронд бичих нөхцөл байдал өмнө нь тайлбарласан) бөгөөд мэдээжийн хэрэг, бидний дуртай зүйл бол сонгодог офсетээс илүү хурдан бөгөөд тогтвортой ажилладаг. Тогтвортой байдал нь хүсэлтийг боловсруулах хугацаа нь хүссэн хүснэгтийн тоотой пропорциональ нэмэгдэхгүй байгаа явдал юм (тэмдэглэл: хэрэв та хуудаслах янз бүрийн аргын талаар илүү ихийг мэдэхийг хүсвэл . Та мөн өөр өөр аргуудын харьцуулсан жишиг үзүүлэлтүүдийг эндээс олж болно).
Слайдуудын нэг Түлхүүрээр хуудаслах нь мэдээжийн хэрэг бүхнийг чадагч биш - энэ нь өөрийн хязгаарлалттай. Хамгийн гол нь тэр санамсаргүй хуудсуудыг унших чадваргүй (тэмдэглэл: тогтмол бус). Гэсэн хэдий ч төгсгөлгүй гүйлгэх эрин үед (тэмдэглэл: урд талд) энэ нь тийм ч асуудал биш юм. Товших хуудасны дугаарыг зааж өгөх нь UI дизайн дахь буруу шийдвэр юм (тэмдэглэл: нийтлэлийн зохиогчийн үзэл бодол).
Хэрэгслийн талаар юу хэлэх вэ?
Түлхүүрүүд дээр хуудас бичих нь энэ аргыг хэрэглэхэд туслах хэрэгсэл байхгүй тул ихэнхдээ тохиромжгүй байдаг. Ихэнх хөгжүүлэлтийн хэрэгслүүд, түүний дотор янз бүрийн фреймворкууд нь яг яаж хуудаслахыг сонгох боломжийг танд олгодоггүй.
Тайлбарласан арга нь DBMS-ээс эхлээд AJAX хүсэлтийг хөтөч дээр эцэс төгсгөлгүй гүйлгэж гүйцэтгэх хүртэл ашигладаг технологид төгсгөл хүртэл дэмжлэг шаарддаг тул нөхцөл байдлыг улам хүндрүүлж байна. Зөвхөн хуудасны дугаарыг зааж өгөхийн оронд та бүх хуудсанд нэг зэрэг түлхүүрүүдийг зааж өгөх хэрэгтэй.
Гэсэн хэдий ч товчлуурууд дээр хуудаслахыг дэмждэг фреймворкуудын тоо аажмаар нэмэгдэж байна. Одоогоор бидэнд байгаа зүйл бол:
- Java-д зориулсан;
- Ruby-ийн хувьд;
- и Джангогийн хувьд;
- Python-д зориулсан;
- - JPA хэрэгжилтийн API шалгуур;
- Perl-ийн хувьд;
- , Node.js-д зориулсан зураглагч .
(Жич: орчуулга хийх үед зарим номын сангууд 2017-2018 он хүртэл шинэчлэгдээгүй байсан тул зарим холбоосыг хассан. Хэрэв та сонирхож байвал эх сурвалжаас нь харж болно.)
Яг энэ мөчид таны тусламж хэрэгтэй байна. Хэрэв та хуудасны тэмдэглэгээг ашигладаг тогтолцоог боловсруулж эсвэл дэмждэг бол би танаас түлхүүрүүд дээр хуудас бичихэд дэмжлэг үзүүлэхийг хүсч байна. Хэрэв танд асуулт байвал эсвэл тусламж хэрэгтэй бол би туслахдаа баяртай байх болно (, , ) (тэмдэглэл: Маркустай хийсэн туршлагаасаа харахад тэр энэ сэдвийг түгээхдээ үнэхээр урам зоригтой байгаа гэж хэлж болно).
Хэрэв та түлхүүрээр хуудаслах дэмжлэг авах нь зүйтэй гэж бодож байгаа бэлэн шийдлүүдийг ашиглаж байгаа бол хүсэлт гаргаж эсвэл боломжтой бол бэлэн шийдлийг санал болго. Та мөн энэ нийтлэлийг холбож болно.
дүгнэлт
Түлхүүрээр хуудаслах гэх мэт энгийн бөгөөд ашигтай арга яагаад өргөн тархаагүй байгаагийн шалтгаан нь үүнийг техникийн хувьд хэрэгжүүлэхэд хэцүү эсвэл маш их хүчин чармайлт шаарддаггүй. Гол шалтгаан нь олон хүн офсетийг харж, ажиллахад дассан байдаг - энэ аргыг стандарт өөрөө зааж өгдөг.
Үүний үр дүнд цөөхөн хүн хуудасны хандлагыг өөрчлөх талаар боддог бөгөөд үүнээс болж фреймворк, номын сангуудын хэрэглүүрийн дэмжлэг муу хөгжиж байна. Тиймээс, офсетгүй хуудас бичих санаа, зорилго танд ойрхон байвал үүнийг түгээхэд тусална уу!
Эх сурвалж:
Зохиогч: Маркус Винд
Эх сурвалж: www.habr.com