מה ג'וליה אוונס למדה על הרצת SQLite מאחורי אתר Django

ג'וליה אוונס פרסמה רשימות על הרצת SQLite מאחורי אתר Django — הפרויקט הרביעי שלה שמשתמש במסד המוטמע. לדבריה, העצה להשתמש ב-SQLite בפרודקשן באתר קטן נכונה, אך הניסיון הבהיר משהו שהפוסטים השונים מדלגים עליו: SQLite הוא עדיין מסד נתונים, מסדי נתונים מורכבים, ותפעולם הוא מיומנות בפני עצמה.

ANALYZE ושאילתה של חמש שניות

ההפתעה הראשונה הייתה שאילתת חיפוש מלא באמצעות הרחבת FTS5 של SQLite על טבלה בת 4,000 שורות שנמשכה חמש שניות. הרצת ANALYZE קיצרה אותה מיד לכעשירית השנייה. ANALYZE אוסף סטטיסטיקות שמתכנן השאילתות משתמש בהן כדי לבחור תוכנית טובה יותר; אוונס מספרת שהיא עדיין לא יודעת בדיוק מה היה שגוי בתוכנית המקורית, והיא חושדת בסיבוכיות ריבועית בשוגג. היא משתמשת ב-SQLite בפרויקטי ווב מאז 2022, ורק כעת גילתה ש-ANALYZE קיים.

ניקוי שורות מסובך מכפי שהוא נראה

מחיקת שורות מיותרות — למשל משימות שהושלמו והושארו על ידי django-tasks-db — יצרה בעיות יותר מפעם אחת. כשפקודת הניקוי נמשכת יותר מחמש שניות, תהליך עבודה אחר מנסה לכתוב למסד, חורג ממגבלת חמש השניות שהוגדרה, קורס וגורר איתו את המכונה הווירטואלית. הפתרון עד כה הוא ניקוי בקבוצות קטנות כך שאף שאילתה לא תחרוג מהמגבלה. לדברי אוונס, התקרית הבהירה לה למה יש מי שזקוק למסד כמו Postgres שמאפשר כמה כותבים במקביל, ובהמשך היא עשויה לקבוע חלון תחזוקה מתוכנן לניקויים.

גיבויים: restic ו-Litestream

שגרת הגיבוי הנוכחית מוציאה את המסד עם VACUUM INTO, מכווצת אותו ושולחת אותו ל-S3 באמצעות restic — תחילה בשחרור המאגר, משום שגיבוי שנהרג משאיר נעילה, ואחר כך במחיקת תמונות מצב ישנות. לאחרונה היא החלה לבדוק את Litestream לשכפול מצטבר עם חלון שמירה של 400 שעות, בין היתר מפני שהרצות restic נהרגו לעתים מחוסר זיכרון. הגיבויים מנוטרים במתג אדם מת, אך היא מודה שמעולם לא בדקה שחזור מהם.

בנושא הביצועים אוונס רגועה בכוונה: היא כותבת שאילתות דרך ה-ORM של Django בלי לעקוב אחר תוכניות איטיות, והמסד עומד על כ-10,000 שורות והיא מצפה שיישאר קטן. כשטבלאות לא צריכות לשכון יחד היא מפצלת אותן לכמה קבצים — גישה שיישמה גם ב-Mess with DNS, שרץ על SQLite כבר ארבע שנים, מאז 2022.