למה אתה צריך תמיכה אינסטרומנטלית עבור עימוד על מקשים?

שלום לכולם! אני מפתח עורפי כותב שירותי מיקרו ב-Java + Spring. אני עובד באחד מצוותי פיתוח המוצר הפנימיים בטינקוף.

בצוות שלנו, עולה לעתים קרובות שאלת אופטימיזציה של שאילתות ב-DBMS. אתה תמיד רוצה להיות קצת יותר מהיר, אבל אתה לא תמיד יכול להסתדר עם אינדקסים שנבנו בקפידה - אתה צריך לחפש כמה דרכים לעקיפת הבעיה. במהלך אחד מהשיטוטים האלה ברחבי האינטרנט בחיפוש אחר אופטימיזציות סבירות בעבודה עם מסדי נתונים, מצאתי הבלוג המועיל האינסופי של מרקוס וויננד, מחבר של SQL Performance Explained. זהו סוג נדיר של בלוג שבו אתה יכול לקרוא את כל המאמרים ברצף.

ברצוני לתרגם עבורכם מאמר קצר מאת מרקוס. אפשר לקרוא לזה במידה מסוימת מניפסט המבקש למשוך תשומת לב לבעיה הישנה, ​​אך עדיין רלוונטית, של ביצוע פעולת האופסט לפי תקן SQL.

במקומות מסוימים אוסיף את המחבר בהסברים והערות. אתייחס לכל המקומות האלה כ"בערך". ליותר בהירות

הקדמה קטנה

אני חושב שאנשים רבים יודעים כמה בעייתית ואיטית העבודה עם בחירת עמודים באמצעות אופסט. הידעתם שניתן להחליף אותו די בקלות בעיצוב יעיל יותר?

אז, מילת המפתח offset אומרת למסד הנתונים לדלג על n הרשומות הראשונות בבקשה. עם זאת, מסד הנתונים עדיין צריך לקרוא את n הרשומות הראשונות הללו מהדיסק, בסדר הנתון (שימו לב: החל מיון אם צוין), ורק לאחר מכן ניתן יהיה להחזיר רשומות מ-n+1 ואילך. הדבר המעניין ביותר הוא שהבעיה היא לא ביישום הספציפי ב-DBMS, אלא בהגדרה המקורית לפי התקן:

...השורות ממוינות תחילה לפי ה ולאחר מכן הגבלה על ידי הפלת מספר השורות שצוין ב- מההתחלה...
-SQL:2016, חלק 2, 4.15.3 טבלאות נגזרות (הערה: כרגע התקן הנפוץ ביותר)

נקודת המפתח כאן היא שהאופסט לוקח פרמטר בודד - מספר הרשומות שעליהן לדלג, וזהו. בעקבות הגדרה זו, ה-DBMS יכול רק לאחזר את כל הרשומות ולאחר מכן להשליך את המיותרות. ברור שההגדרה הזו של קיזוז מאלצת אותנו לעשות עבודה נוספת. וזה אפילו לא משנה אם זה SQL או NoSQL.

רק עוד קצת כאב

הבעיות בקיזוז לא מסתיימות שם, והנה הסיבה. אם בין קריאת שני עמודי נתונים מהדיסק, פעולה נוספת תכניס רשומה חדשה, מה יקרה במקרה זה?

כאשר משתמשים ב-offset לדילוג על רשומות מדפים קודמים, במצב של הוספת רשומה חדשה בין קריאה של עמודים שונים, סביר להניח שתקבלו כפילויות (שימו לב: הדבר אפשרי כאשר אנו קוראים עמוד אחר עמוד באמצעות הסדר לפי מבנה, אז באמצע הפלט שלנו הוא עשוי לקבל ערך חדש).

האיור מתאר בבירור מצב זה. הבסיס קורא את 10 הרשומות הראשונות, ולאחר מכן מוכנס רשומה חדשה, שמקזז את כל רשומות הקריאה ב-1. ואז הבסיס לוקח עמוד חדש מ-10 הרשומות הבאות ומתחיל לא מה-11, כפי שצריך, אלא מה- 10, משכפל את הרשומה הזו. קיימות חריגות נוספות הקשורות לשימוש בביטוי זה, אך זהו הנפוץ ביותר.

כפי שכבר גילינו, לא מדובר בבעיות של DBMS ספציפי או ביישומים שלהם. הבעיה היא בהגדרת עימוד לפי תקן SQL. אנו אומרים ל-DBMS איזה עמוד להביא או על כמה רשומות לדלג. מסד הנתונים פשוט לא מסוגל לייעל בקשה כזו, מכיוון שיש מעט מדי מידע לכך.

כדאי גם להבהיר שלא מדובר בבעיה במילת מפתח ספציפית, אלא בסמנטיקה של השאילתה. ישנם עוד כמה תחבירים זהים באופיים הבעייתי שלהם:

• מילת המפתח אופסט היא כפי שהוזכר קודם לכן.
• בנייה של שתי מילות מפתח מגבלה [היסט] (למרות שהגבלה עצמה לא כל כך גרועה).
• סינון לפי גבולות נמוכים, בהתבסס על מספור שורות (לדוגמה, row_number(), rownum וכו').

כל הביטויים האלה פשוט אומרים לך על כמה שורות לדלג, ללא מידע נוסף או הקשר.

בהמשך מאמר זה, מילת המפתח offset משמשת כסיכום של כל האפשרויות הללו.

חיים ללא OFFSET

עכשיו בואו נדמיין איך העולם שלנו היה נראה בלי כל הבעיות האלה. מסתבר שהחיים ללא קיזוז הם לא כל כך קשים: עם בחירה אפשר לבחור רק את השורות שעדיין לא ראינו (שימו לב: כלומר כאלו שלא היו בעמוד הקודם), תוך שימוש בתנאי איפה.

במקרה זה, אנו מתחילים מהעובדה שהבחירות מבוצעות על סט מסודר (סדר ישן וטוב על ידי). מכיוון שיש לנו סט מסודר, אנו יכולים להשתמש במסנן פשוט למדי כדי לקבל רק את הנתונים שנמצאים מאחורי הרשומה האחרונה של העמוד הקודם:

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

זה כל העיקרון של הגישה הזו. כמובן, הדברים נעשים יותר כיף כאשר מיון לפי עמודות רבות, אבל הרעיון עדיין זהה. חשוב לציין שעיצוב זה ישים לרבים NoSQL-החלטות.

גישה זו נקראת שיטת חיפוש או עימוד ערכת מפתחות. זה פותר את בעיית התוצאה הצפה (שימו לב: המצב עם כתיבה בין קריאת עמודים, שתואר קודם לכן) וכמובן, מה שכולנו אוהבים, זה עובד מהר ויציב יותר מהאופסט הקלאסי. היציבות טמונה בעובדה שזמן עיבוד הבקשות אינו גדל ביחס למספר הטבלה המבוקשת (הערה: אם ברצונכם ללמוד עוד על עבודתן של גישות שונות לעימוד, תוכלו עיין במצגת של המחבר. אתה יכול גם למצוא שם מדדים השוואתיים לשיטות שונות).

אחת המגלשות מדבר על זהשעימוד לפי מפתחות, כמובן, אינו כל יכול - יש לו מגבלות. המשמעותי ביותר הוא שאין לה את היכולת לקרוא דפים אקראיים (שימו לב: באופן לא עקבי). עם זאת, בעידן של גלילה אינסופית (שימו לב: בחלק הקדמי), זו לא בעיה כזו. ציון מספר עמוד ללחיצה היא החלטה גרועה בכל מקרה בעיצוב ממשק המשתמש (הערה: חוות דעת של כותב המאמר).

מה עם הכלים?

עימוד על מקשים לרוב אינו מתאים בגלל היעדר תמיכה אינסטרומנטלית בשיטה זו. רוב כלי הפיתוח, לרבות מסגרות שונות, לא מאפשרים לבחור איך בדיוק יתבצע העימוד.

המצב מחמיר לנוכח העובדה שהשיטה המתוארת דורשת תמיכה מקצה לקצה בטכנולוגיות בהן נעשה שימוש - מה-DBMS ועד לביצוע בקשת AJAX בדפדפן עם גלילה אינסופית. במקום לציין רק את מספר העמוד, כעת עליך לציין קבוצת מפתחות עבור כל העמודים בבת אחת.

עם זאת, מספר המסגרות התומכות בעימוד במפתחות הולך וגדל בהדרגה. הנה מה שיש לנו כרגע:

• jOOQ עבור Java;
• order_query עבור רובי;
• chunkator и דג'נגו Infinite Scroll Pagining עבור ג'נגו;
• SQL Alchemy sqlakeyset עבור Python;
• התמדה-להבה - API של קריטריונים עבור יישומי JPA;
• DBIx::Class::Wrapper עבור פרל;
• Massive.js, ממפה עבור Node.js תיעוד ערכת מפתחות.

(הערה: חלק מהקישורים הוסרו בשל העובדה שבזמן התרגום חלק מהספריות לא עודכנו מאז 2017-2018. אם אתה מעוניין, אתה יכול להסתכל במקור המקורי.)

ברגע זה יש צורך בעזרתכם. אם אתה מפתח או תומך במסגרת שעושה שימוש כלשהו בעימוד, אז אני מבקש, אני מפציר, אני מפציר בכם לספק תמיכה מקורית לעימוד על מקשים. אם יש לך שאלות או שאתה צריך עזרה, אני אשמח לעזור (форум, טויטר, טופס יצירת קשר) (הערה: מניסיוני עם מרקוס, אני יכול לומר שהוא ממש מתלהב מהפצת הנושא הזה).

אם אתם משתמשים בפתרונות מוכנים שלדעתכם ראויים לקבל תמיכה בעימוד לפי מפתחות, צרו בקשה או אפילו הציעו פתרון מוכן, במידת האפשר. אתה יכול גם קישור למאמר זה.

מסקנה

הסיבה לכך שגישה כה פשוטה ושימושית כמו עימוד לפי מפתחות אינה נפוצה היא לא שהיא קשה ליישום טכנית או דורשת מאמץ רב. הסיבה העיקרית היא שרבים רגילים לראות ולעבוד עם אופסט – גישה זו מוכתבת על ידי התקן עצמו.

כתוצאה מכך, מעט אנשים חושבים על שינוי הגישה לעימוד, ובשל כך, תמיכה אינסטרומנטלית ממסגרות וספריות מתפתחת בצורה גרועה. לכן, אם הרעיון והמטרה של עימוד ללא קיזוז קרובים אליכם, עזרו להפיץ אותו!

מקור: https://use-the-index-luke.com/no-offset
מחבר: מרקוס וויננד

מקור: www.habr.com