מתי להשתמש ב-SQLite: שימושים, מגבלות ומתי לוותר עליו

השאלה המרכזית

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

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

השתמשו ב-SQLite כשהנתונים נמצאים עם האפליקציה

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

-- A typical "data lives with the app" schema:
-- a desktop note-taking app's local store.
CREATE TABLE notes (
    id        INTEGER PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT,
    created   TEXT DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO notes (title, body) VALUES
    ('Groceries', 'milk, bread, coffee'),
    ('Ideas',     'sqlite tutorial outline');

SELECT id, title, created FROM notes;

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

• אפליקציות דסקטופ ומובייל. כל אפליקציית iOS ו-Android שצריכה אחסון מקומי מובנה משתמשת ב-SQLite מתחת למכסה המנוע. כך גם Firefox, Chrome ורוב הדפדפנים.
• כלי CLI. git, מנהלי חבילות ומנהלי dotfiles כולם משתמשים במסדי נתונים משובצים.
• מכשירים משובצים. נתבים, מכוניות, מטוסים: כל דבר שצריך מסד נתונים בנפח של כמה מאות קילובייטים.
• חבילות בדיקות. קובץ SQLite טרי (או מסד נתונים :memory:) לכל בדיקה מהיר ומבודד יותר מהרמת Postgres.

אם הנתונים שלכם לא צריכים להיות משותפים בין כמה מכונות, SQLite הוא כנראה התשובה הנכונה.

השתמשו ב-SQLite לאתרים שעיקרם קריאה

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

-- A blog's posts table.
CREATE TABLE posts (
    slug      TEXT PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT NOT NULL,
    published TEXT
);

CREATE INDEX idx_posts_published ON posts(published DESC);

INSERT INTO posts VALUES
    ('hello-world', 'Hello, World', 'First post.', '2024-01-01'),
    ('sqlite-rocks', 'Why SQLite',  'Single-file DB.', '2024-02-15');

SELECT slug, title FROM posts ORDER BY published DESC LIMIT 10;

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

מצב WAL (write-ahead logging, מוסבר בהמשך) מעלה את התקרה משמעותית בכך שהוא מאפשר לקוראים ולכותב לעבוד במקביל. הרבה אתרים בפרודקשן מגישים מיליוני בקשות ביום על SQLite עם WAL.

השתמשו ב-SQLite למטמונים מקומיים ולנתוני טיוטה

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

-- A cache table for an HTTP client.
CREATE TABLE http_cache (
    url        TEXT PRIMARY KEY,
    body       BLOB NOT NULL,
    expires_at INTEGER NOT NULL
);

INSERT INTO http_cache (url, body, expires_at)
    VALUES ('https://api.example.com/users/1', x'7b2269...', 1735689600);

DELETE FROM http_cache WHERE expires_at < strftime('%s', 'now');
SELECT count(*) FROM http_cache;

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

אל תשתמשו ב-SQLite להרבה כותבים מקביליים

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

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

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

אז SQLite יהפוך לצוואר הבקבוק. Postgres ו-MySQL משתמשים בנעילה ברמת השורה ונבנו בדיוק בשביל זה. פנו אליהם.

-- The error you'll see when writers pile up:
Error: database is locked

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

אל תשתמשו ב-SQLite על פני כמה מכונות

SQLite הוא ספרייה שרצה בתוך התהליך. האפליקציה קוראת וכותבת לקובץ ישירות, כלומר הקובץ חייב להיות על דיסק שהאפליקציה יכולה לבצע עליו read() ו-write() עם קריאות רגילות של מערכת הקבצים.

זה פוסל:

• כמה שרתי אפליקציה מאחורי מאזן עומסים, שכולם רוצים לחלוק מסד נתונים אחד. (מערכות קבצים ברשת כמו NFS עובדות טכנית, אבל משחיתות את הקובץ תחת עומס. אל.)
• פונקציות serverless שבהן כל הפעלה רצה על מכונה אחרת.
• Pods של Kubernetes שצריכים מסד נתונים משותף, אלא אם אתם משתמשים בפריסה של pod יחיד עם volume קבוע.

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

אל תשתמשו ב-SQLite כשצריך משתמשים ברמת מסד הנתונים

ל-SQLite אין מושג של משתמשים, תפקידים או הרשאות. מסד הנתונים הוא קובץ: מי שיכול לקרוא את הקובץ יכול לקרוא הכול, ומי שיכול לכתוב אליו יכול לכתוב הכול. בקרת גישה היא התפקיד של מערכת ההפעלה.

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

רשימת בדיקה מהירה להחלטה

עברו על הרשימה הזו. אם עניתם "כן" על כולן, SQLite הוא כנראה בחירה מצוינת:

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

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

מה לקחת מכאן

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

הבא בתור: התקנת SQLite

מספיק תאוריה. הדף הבא מראה איך להכניס את SQLite למחשב שלכם (הוא כבר נמצא ב-macOS וברוב הפצות Linux, וב-Windows מדובר בהורדה אחת) ואיך לוודא את ההתקנה משורת הפקודה.