בלוגים

אפשרויות האינדקסים ב PostgreSQL

אינדקסים פונקציונליים

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

נניח, למשל,  שבטבלה t יש שדה f והרבה קריאות מהטבלה משתמשות בתנאי: אות הראשונה של f שווה ל"אות"

ניתן ליצור אינדקס:

CREATE INDEX f_name_first_idx ON t ((substr(f, 1, 1)));

לאחר מכן קריאה הבאה תשתמש באינדקס החדש:

SELECT * FROM t WHERE (f, 1, 1) = 'a';

אינדקסים חלקיים

אינדקס חלקי הוא אינדקס עם תנאי WHERE.

שימוש באינדקסים

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

אם לא - נבנה אותם. צריכים לזכור שעודף האינדקסים טומן בתוכו בעיות:

צילומי ההרצאות מהמיטאפ + ניוזלטר

שלום לכל חברי הקבוצה!

והפעם יש עדכונים רבים:

 

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

Npgsql: Open Source .NET Support for PostgreSQL
by Shay Rojansky

DaTabl.eS/QL: Open Source Thin Layer over SQL that Doubles its Functionality
by Eli Marmor

אופטימיזציה של מסד הנתונים ויישומים

להרצה מהירה של השאילתות במסד הנתונים בעיקר נדרשים:

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

תחזוקת מסד הנתונים בצורה תקינה

סעיף זה מתאר את הפעולות שצריכות להתבצע מעת לעת עבור כל מסד נתונים.

הגדרות של Planner/Optimizer

ההתאמות הבאות מאפשרות לPlanner להעריך נכון את הערך של פעולות שונות ולבחור את תכנית הביצוע הטובה ביותר עבור שאילתות.

ישנם 3 הגדרות מתזמנות, שכדאי לשים לב:

default_statistics_target

פרמטר זה מציין את כמות הנתונים הסטטיסטיים שנאספת על ידי הפקודה ANALYZE. הגדלת הפרמטר תגרום למערכת לעבוד יותר, אך היא יכולה לאפשר לבנות תכניות מהירות יותר, ע"י שימוש במידע הנוסף שהתקבל. נתונים סטטיסטיים עבור שדה אפשר להגיד ע"י ALTER TABLE ... SET STATISTICS.

הגדרות אחרות (המשך)

- full_page_writes, תבחר באפשרות off, אם fsync = off. אחרת, כאשר on נבחר, PostgreSQL כותב את התוכן של כל רשומה ביומן בשינוי הראשון של הטבלה. זה נחוץ משום שהנתונים עשויים להיות שמורים באופן חלקי בלבד, אם בזמן התהליך נפלה מערכת ההפעלה. זה יגרום שבדיסק יהיה מידע חדש מעורבב עם הישן. רישום ביומן יכול להיות לא מספיק על מנת לשחזר את הנתונים באופן מלא לאחר נפילת מערכת ההפעלה. full_page_writes מבטיח התאוששות בצורה נכונה, ע"י עלייה בכמות הנתונים שייכתבו ביומן (הדרך היחידה להפחית את כמות הנתונים ביומן היא להגדיל checkpoint_interval).

הגדרות נוספות

- commit_delay (במיקרו-שניות, 0 כברירת מחדל) ו commit_siblings (ברירת מחדל 5) מגדירים את מרווח הזמן בין הכנסת הטרנזקציה למאגרי היומן ושמירה שלה בדיסק.

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

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

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

fsync, synchronous_commit והאם ניתן לגעת בהם

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

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

PostgreSQL Bi-Directional Replication

Bi-Directional Replication או BDR, זאת התוספת הפונקציונלית החדשה ל PostgreSQL, המספקת כלים מתקדמים לשכפול הגיוני.

כרגע זה עדיין פתרון צעיר, אך כבר מוכן לשימוש. BDR מאפשר ליצור תצורות multi-master אסינכרוניות, .מבוזרות גאוגרפית באמצעות רפליקציה מובנית Logical Log Streaming Replication או LLSR
עם זאת, BDR אינו כלי Clustering, כפי שכאן אין Database transactions managers.