PostgreSQL: מסד נתונים חופשי למידע אמין

מסד נתונים עם זהות עצמאית

PostgreSQL, המכונה גם Postgres, הוא מסד נתונים חופשי בגישה יחסית־אובייקטית. הוא אינו גרסה של MySQL. שורשיו בפרויקט POSTGRES באוניברסיטת קליפורניה בברקלי, שעבודת המימוש שלו החלה ב־1986. בהמשך נוספה תמיכה ב־SQL, הופיע Postgres95 וב־1996 נבחר השם PostgreSQL. זו היסטוריה של מחקר ופיתוח מתמשך, ולא רק החלפת שם מסחרי.

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

רישיון שמאפשר עצמאות

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

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

לשמור על כללי הנתונים בתוך המסד

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

CREATE TABLE community_projects (
    id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name text NOT NULL,
    slug text NOT NULL UNIQUE,
    member_count integer NOT NULL DEFAULT 0
        CHECK (member_count >= 0)
);

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

SQL, נתונים מורכבים והרחבות

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

אימות והרשאות אינם אותה פעולה

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

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

ביצועים מתחילים במדידה

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

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

שכפול אינו תחליף לתרגול שחזור

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

לא מספיק לשמור רק את הטבלאות: היישום, ההרחבות, ההרשאות והתצורה צריכים להיות ניתנים להקמה מחדש. להשוואה עם מערך אירוח נפוץ קראו את המאמר על PHP ו־MariaDB.