Защо се нуждаете от инструментална поддръжка за страниране на ключове?

Здравейте всички! Аз съм бекенд разработчик, който пиша микроуслуги в Java + Spring. Работя в един от вътрешните екипи за разработка на продукти в Tinkoff.

В нашия екип често възниква въпросът за оптимизиране на заявките в СУБД. Винаги искате да сте малко по-бързи, но не винаги можете да се справите със замислено конструирани индекси - трябва да потърсите някои заобиколни решения. По време на едно от тези скитания из мрежата в търсене на разумни оптимизации при работа с бази данни, открих Безкрайно полезният блог на Marcus Wynand, автор на SQL Performance Explained. Това е онзи рядък тип блог, в който можете да прочетете всички статии подред.

Бих искал да преведа кратка статия от Маркъс за вас. Може да се нарече до известна степен манифест, който се стреми да привлече вниманието към стария, но все още актуален проблем за изпълнението на операцията за отместване според стандарта SQL.

На места ще допълвам автора с пояснения и коментари. Ще наричам всички такива места като „приблизително“. за повече яснота

Малко въведение

Мисля, че много хора знаят колко проблемна и бавна е работата със селекции на страници чрез отместване. Знаете ли, че той може доста лесно да бъде заменен с по-ефективен дизайн?

И така, ключовата дума offset казва на базата данни да пропусне първите n записа в заявката. Базата данни обаче все още трябва да прочете тези първи n записа от диска в дадения ред (забележка: приложете сортиране, ако е посочено) и едва тогава ще бъде възможно да върне записи от n+1 нататък. Най-интересното е, че проблемът не е в конкретната имплементация в СУБД, а в оригиналната дефиниция според стандарта:

…редовете първо се сортират според и след това ограничен чрез премахване на броя редове, посочени в от началото...
-SQL:2016, част 2, 4.15.3 Изведени таблици (забележка: в момента най-използваният стандарт)

Ключовият момент тук е, че отместването приема един-единствен параметър - броя на записите за пропускане и това е всичко. Следвайки тази дефиниция, СУБД може само да извлече всички записи и след това да изхвърли ненужните. Очевидно това определение за компенсиране ни принуждава да вършим допълнителна работа. И дори няма значение дали е SQL или NoSQL.

Само още малко болка

Проблемите с офсета не свършват дотук и ето защо. Ако между четенето на две страници с данни от диска друга операция вмъкне нов запис, какво ще се случи в този случай?

Когато отместването се използва за пропускане на записи от предишни страници, в ситуация на добавяне на нов запис между четения на различни страници, най-вероятно ще получите дубликати (забележка: това е възможно, когато четем страница по страница, използвайки поръчката по конструкция, тогава в средата на нашия изход може да получи нов запис).

Фигурата ясно изобразява тази ситуация. Базата чете първите 10 записа, след което се вмъква нов запис, който компенсира всички прочетени записи с 1. След това базата взема нова страница от следващите 10 записа и започва не от 11-ия, както трябва, а от 10-ти, дублира този запис. Има и други аномалии, свързани с използването на този израз, но това е най-често срещаното.

Както вече разбрахме, това не са проблеми на конкретна СУБД или техните реализации. Проблемът е в дефинирането на страниране според стандарта SQL. Казваме на СУБД коя страница да извлече или колко записа да пропусне. Базата данни просто не е в състояние да оптимизира такава заявка, тъй като има твърде малко информация за това.

Също така си струва да се изясни, че това не е проблем с конкретна ключова дума, а по-скоро със семантиката на заявката. Има още няколко синтаксиса, които са идентични по своя проблемен характер:

• Ключовата дума offset е както беше споменато по-рано.
• Конструкция от две ключови думи limit [offset] (въпреки че limit сам по себе си не е толкова лош).
• Филтриране по долни граници въз основа на номериране на редове (например row_number(), rownum и т.н.).

Всички тези изрази просто ви казват колко реда да пропуснете, без допълнителна информация или контекст.

По-късно в тази статия ключовата дума offset се използва като обобщение на всички тези опции.

Живот без ОФСЕТ

Сега нека си представим какъв би бил нашият свят без всички тези проблеми. Оказва се, че животът без отместване не е толкова труден: с select можете да изберете само онези редове, които все още не сме видели (забележка: тези, които не са били на предишната страница), като използвате условие в where.

В този случай изхождаме от факта, че селектирането се изпълнява върху подреден набор (добрият стар ред по). Тъй като имаме подреден набор, можем да използваме доста прост филтър, за да получим само данните, които са зад последния запис на предишната страница:

    SELECT ...
    FROM ...
    WHERE ...
    AND id < ?last_seen_id
    ORDER BY id DESC
    FETCH FIRST 10 ROWS ONLY

Това е целият принцип на този подход. Разбира се, нещата стават по-забавни при сортиране по много колони, но идеята остава същата. Важно е да се отбележи, че този дизайн е приложим за много NoSQL- решения.

Този подход се нарича метод за търсене или пагиниране на набор от ключове. Той решава проблема с плаващия резултат (забележка: ситуацията с писане между четения на страници, описана по-рано) и, разбира се, това, което всички обичаме, работи по-бързо и по-стабилно от класическия офсет. Стабилността се крие във факта, че времето за обработка на заявката не се увеличава пропорционално на броя на заявената таблица (забележка: ако искате да научите повече за работата на различните подходи за страниране, можете разгледайте презентацията на автора. Можете също да намерите сравнителни показатели за различни методи там).

Един от слайдовете говори за товаче странирането по ключове, разбира се, не е всемогъщо - има своите ограничения. Най-важното е, че тя няма способността да чете произволни страници (забележка: непоследователно). Въпреки това, в ерата на безкрайното превъртане (забележка: в предния край), това не е такъв проблем. Посочването на номер на страница за кликване е лошо решение в дизайна на потребителския интерфейс така или иначе (забележка: мнението на автора на статията).

Какво ще кажете за инструментите?

Странирането на ключовете често не е подходящо поради липсата на инструментална поддръжка за този метод. Повечето инструменти за разработка, включително различни рамки, не ви позволяват да изберете как точно да се извърши пагинацията.

Ситуацията се утежнява от факта, че описаният метод изисква поддръжка от край до край в използваните технологии - от СУБД до изпълнение на AJAX заявка в браузъра с безкрайно превъртане. Вместо да посочите само номера на страницата, сега трябва да посочите набор от ключове за всички страници наведнъж.

Въпреки това, броят на рамките, които поддържат пагинация на ключове, постепенно нараства. Ето с какво разполагаме в момента:

• jOOQ за Java;
• поръчка_заявка за Руби;
• чункатор и Django Infinite Scroll Pagination за Джанго;
• SQL Alchemy sqlakeyset за Python;
• пламък-постоянство — API на критерии за внедряване на JPA;
• DBIx::Class::Wrapper за Perl;
• Massive.js, картограф за Node.js Документация за набор ключове.

(Забележка: някои връзки бяха премахнати поради факта, че към момента на превода някои библиотеки не са били актуализирани от 2017-2018 г. Ако се интересувате, можете да погледнете оригиналния източник.)

Точно в този момент е необходима вашата помощ. Ако разработвате или поддържате рамка, която използва по някакъв начин пагинация, тогава моля, призовавам ви, умолявам ви да предоставите естествена поддръжка за страниране на ключове. Ако имате въпроси или нужда от помощ, ще се радвам да помогна (форума, Twitter, форма за контакти) (забележка: от моя опит с Маркъс мога да кажа, че той е наистина ентусиазиран да разпространява тази тема).

Ако използвате готови решения, които смятате, че заслужават да имат поддръжка за страниране по ключове, създайте заявка или дори предложете готово решение, ако е възможно. Можете също да направите връзка към тази статия.

Заключение

Причината, поради която толкова прост и полезен подход като странирането по ключове не е широко разпространен, не е, че е трудно за изпълнение технически или изисква големи усилия. Основната причина е, че мнозина са свикнали да виждат и работят с офсет - този подход се диктува от самия стандарт.

В резултат на това малко хора мислят за промяна на подхода към пагинацията и поради това инструменталната поддръжка от рамки и библиотеки се развива слабо. Ето защо, ако идеята и целта за безофсетно страниране ви е близка, помогнете за разпространението й!

Източник: https://use-the-index-luke.com/no-offset
Автор: Маркус Уинанд

Източник: www.habr.com