키의 페이지 매김을 위한 도구적 지원이 필요한 이유는 무엇입니까?

안녕하세요 여러분! 저는 Java + Spring으로 마이크로서비스를 작성하는 백엔드 개발자입니다. 저는 Tinkoff의 내부 제품 개발 팀 중 한 곳에서 일하고 있습니다.

우리 팀에서는 DBMS에서 쿼리를 최적화하는 문제가 자주 발생합니다. 항상 좀 더 빠른 속도를 원하지만 신중하게 구성된 인덱스로는 항상 성공할 수는 없습니다. 몇 가지 해결 방법을 찾아야 합니다. 데이터베이스 작업 시 합리적인 최적화를 찾기 위해 웹을 돌아다니는 동안 나는 다음과 같은 사실을 발견했습니다. Marcus Wynand의 끝없이 유용한 블로그, SQL Performance explained의 저자입니다. 이것은 모든 기사를 연속해서 읽을 수 있는 보기 드문 유형의 블로그입니다.

나는 당신을 위해 Marcus의 짧은 기사를 번역하고 싶습니다. 이는 오래되었지만 여전히 SQL 표준에 따른 오프셋 작업 성능과 관련된 문제에 관심을 끌려는 선언문이라고 할 수 있습니다.

어떤 곳에서는 저자에게 설명과 의견을 추가할 것입니다. 나는 그러한 모든 장소를 "대략"이라고 부르겠습니다. 더 명확하게 하기 위해

작은 소개

많은 사람들이 오프셋을 통한 페이지 선택 작업이 얼마나 문제가 많고 느린지 알고 있다고 생각합니다. 좀 더 효율적인 디자인으로 아주 쉽게 교체할 수 있다는 사실을 알고 계셨나요?

따라서 offset 키워드는 데이터베이스에 요청의 처음 n개 레코드를 건너뛰도록 지시합니다. 그러나 데이터베이스는 주어진 순서대로 디스크에서 처음 n개의 레코드를 읽어야 하며(참고: 지정된 경우 정렬 적용), 그런 다음에만 n+1부터 레코드를 반환할 수 있습니다. 가장 흥미로운 점은 문제가 DBMS의 특정 구현에 있는 것이 아니라 표준에 따른 원래 정의에 있다는 것입니다.

...행은 먼저 다음에 따라 정렬됩니다. 그런 다음 처음부터...
-SQL:2016, Part 2, 4.15.3 파생 테이블(참고: 현재 가장 많이 사용되는 표준)

여기서 중요한 점은 offset이 단일 매개변수(건너뛸 레코드 수)를 취한다는 것입니다. 이 정의에 따라 DBMS는 모든 레코드만 검색한 다음 불필요한 레코드를 삭제할 수 있습니다. 분명히 이러한 오프셋 정의로 인해 우리는 추가 작업을 수행해야 합니다. 그리고 그것이 SQL인지 NoSQL인지는 중요하지 않습니다.

조금만 더 아프면 돼

오프셋 문제는 여기서 끝나지 않습니다. 그 이유는 다음과 같습니다. 디스크에서 두 페이지의 데이터를 읽는 사이에 다른 작업이 새 레코드를 삽입하는 경우 이 경우에는 어떻게 될까요?

이전 페이지의 레코드를 건너뛰기 위해 오프셋을 사용하는 경우, 서로 다른 페이지를 읽는 사이에 새 레코드를 추가하는 상황에서 중복이 발생할 가능성이 높습니다(참고: 이는 구성별 순서를 사용하여 페이지별로 읽을 때 가능합니다. 출력 중간에 새로운 항목이 나타날 수 있습니다).

그림은 이러한 상황을 명확하게 묘사합니다. 베이스는 처음 10개의 레코드를 읽은 후 새 레코드가 삽입되어 모든 읽기 레코드를 1만큼 오프셋합니다. 그런 다음 베이스는 다음 10개의 레코드에서 새 페이지를 가져와 11번째 레코드부터 시작하지 않고 다음부터 시작합니다. 10일, 이 기록을 복제했습니다. 이 표현의 사용과 관련된 다른 예외 사항이 있지만 이것이 가장 일반적입니다.

이미 알고 있듯이 이는 특정 DBMS나 그 구현의 문제가 아닙니다. 문제는 SQL 표준에 따라 페이지 매김을 정의하는 데 있습니다. 우리는 가져올 페이지나 건너뛸 레코드 수를 DBMS에 알려줍니다. 이에 대한 정보가 너무 적기 때문에 데이터베이스는 이러한 요청을 최적화할 수 없습니다.

이는 특정 키워드의 문제가 아니라 쿼리의 의미에 대한 문제라는 점을 명확히 하는 것도 가치가 있습니다. 문제가 있는 특성상 동일한 구문이 몇 가지 더 있습니다.

• offset 키워드는 앞서 언급한 바와 같습니다.
• 두 개의 키워드를 구성하는 것은 Limit [offset]입니다(한계 자체는 그렇게 나쁘지는 않지만).
• 행 번호 매기기(예: row_number(), rownum 등)를 기준으로 하한으로 필터링합니다.

이러한 모든 표현은 추가 정보나 맥락 없이 건너뛸 줄 수만 알려줍니다.

이 기사의 뒷부분에서는 offset 키워드가 이러한 모든 옵션의 요약으로 사용됩니다.

오프셋 없는 삶

이제 이러한 모든 문제가 없다면 우리 세상이 어떤 모습일지 상상해 봅시다. 오프셋 없는 생활은 그리 어렵지 않습니다. 선택을 사용하면 where의 조건을 사용하여 아직 보지 못한 행(참고: 이전 페이지에 없었던 행)만 선택할 수 있습니다.

이 경우, 선택이 순서가 지정된 세트(오래된 순서 기준)에서 실행된다는 사실부터 시작합니다. 순서가 지정된 세트가 있으므로 매우 간단한 필터를 사용하여 이전 페이지의 마지막 레코드 뒤에 있는 데이터만 가져올 수 있습니다.

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

이것이 이 접근법의 전체 원칙입니다. 물론 많은 열을 기준으로 정렬하면 상황이 더 재미있어지지만 아이디어는 여전히 동일합니다. 이 디자인은 많은 사람들에게 적용 가능하다는 점에 유의하는 것이 중요합니다. NoSQL-결정.

이 접근 방식을 탐색 방법 또는 키 세트 페이지 매김이라고 합니다. 이는 부동 결과 문제(참고: 앞에서 설명한 페이지 읽기 사이에 쓰기 문제)를 해결하며 물론 우리 모두가 좋아하는 점은 기존 오프셋보다 더 빠르고 안정적으로 작동한다는 것입니다. 안정성은 요청 처리 시간이 요청된 테이블 수에 비례하여 증가하지 않는다는 사실에 있습니다. (참고: 페이지 매김에 대한 다양한 접근 방식의 작업에 대해 자세히 알아보려면 다음을 수행하십시오. 저자의 프레젠테이션을 살펴보세요. 다양한 방법에 대한 비교 벤치마크도 찾을 수 있습니다.

슬라이드 중 하나 그것에 대해 이야기물론 키에 의한 페이지 매김은 전능하지 않으며 한계가 있습니다. 가장 중요한 점은 그녀가 임의의 페이지를 읽는 능력이 없다는 것입니다(참고: 일관되지 않음). 그러나 끝없는 스크롤(참고: 프런트엔드) 시대에는 이러한 문제가 발생하지 않습니다. 클릭을 위해 페이지 번호를 지정하는 것은 어쨌든 UI 디자인에서 잘못된 결정입니다(참고: 기사 작성자의 의견).

도구는 어떻습니까?

키에 대한 페이지 매김은 이 방법에 대한 도구적 지원이 부족하기 때문에 종종 적합하지 않습니다. 다양한 프레임워크를 포함한 대부분의 개발 도구에서는 페이지 매김 수행 방법을 정확하게 선택할 수 없습니다.

설명된 방법에는 DBMS부터 끝없는 스크롤을 통해 브라우저에서 AJAX 요청 실행까지 사용되는 기술에 대한 엔드투엔드 지원이 필요하다는 사실로 인해 상황이 더욱 악화됩니다. 이제 페이지 번호만 지정하는 대신 모든 페이지에 대한 키 세트를 한 번에 지정해야 합니다.

그러나 키에 대한 페이지 매김을 지원하는 프레임워크의 수가 점차 늘어나고 있습니다. 현재 우리가 가지고 있는 것은 다음과 같습니다:

• jOOQ 자바의 경우;
• 주문_쿼리 루비의 경우;
• 청커터 и Django 무한 스크롤 페이지 매김 장고의 경우;
• SQL 연금술 sqlakeyset 파이썬의 경우;
• 불타오르는 지속성 — JPA 구현을 위한 기준 API;
• DBIx::클래스::래퍼 펄의 경우;
• Massive.js, Node.js용 매퍼 키세트 문서.

(참고: 번역 당시 일부 라이브러리가 2017-2018년 이후 업데이트되지 않았기 때문에 일부 링크가 제거되었습니다. 관심이 있는 경우 원본 소스를 볼 수 있습니다.)

지금 이 순간 당신의 도움이 필요합니다. 페이지 매김을 사용하는 프레임워크를 개발하거나 지원하는 경우 키에 대한 페이지 매김에 대한 기본 지원을 제공하도록 요청하고 촉구합니다. 질문이 있거나 도움이 필요하시면 기꺼이 도와드리겠습니다(форум, 트위터, 문의 양식) (참고: Marcus에 대한 내 경험으로 볼 때 그는 이 주제를 전파하는 데 정말 열정적이라고 말할 수 있습니다.)

키별 페이지 매기기를 지원할 가치가 있다고 생각되는 기성 솔루션을 사용하는 경우 가능하면 요청을 작성하거나 기성 솔루션을 제공하십시오. 이 기사에 링크를 걸 수도 있습니다.

결론

키에 의한 페이지 매김과 같은 간단하고 유용한 접근 방식이 널리 보급되지 않은 이유는 기술적으로 구현하기 어렵거나 큰 노력이 필요하기 때문이 아닙니다. 주된 이유는 많은 사람들이 오프셋을 보고 작업하는 데 익숙하기 때문입니다. 이 접근 방식은 표준 자체에 의해 결정됩니다.

결과적으로 페이지 매김 접근 방식을 변경하는 것에 대해 생각하는 사람은 거의 없으며 이로 인해 프레임워크와 라이브러리의 도구 지원이 제대로 개발되지 않습니다. 그러므로, 오프셋 없는 페이지 매김에 대한 아이디어와 목표가 여러분에게 가깝다면 이를 널리 알리는 데 도움을 주세요!

출처 : https://use-the-index-luke.com/no-offset
저자: 마르쿠스 위난드

출처 : habr.com