SQLite vs MySQL: באיזה מסד נתונים לבחור?

שתי צורות שונות של מסד נתונים

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

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

-- SQLite: פותחים קובץ, ויש מסד נתונים.
sqlite3 app.db

-- MySQL: מתחברים לשרת שרץ.
mysql -h localhost -u root -p

הפקודה של SQLite פותחת (או יוצרת) קובץ. הפקודה של MySQL פותחת חיבור לתהליך שחייב כבר לרוץ, להיות מוגדר ולקבל התחברויות.

ארכיטקטורה: מוטמע מול לקוח ושרת

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

MySQL הוא ההפך. השרת mysqld מחזיק את הנתונים, מנהל חיבורים, אוכף הרשאות, מריץ את מתכנן השאילתות ומטפל בנעילות. האפליקציה שלכם היא לקוח ששולח מחרוזות SQL ברשת ומקבל בחזרה שורות תוצאה.

ההשלכות המעשיות:

• פריסה. SQLite מגיעה עם האפליקציה שלכם: קובץ הרצה אחד, קובץ נתונים אחד. MySQL צריך שרת נפרד להתקנה, לאבטחה, לניטור ולגיבוי.
• גישה ברשת. MySQL חושף פורט, כך שכמה שרתי אפליקציה יכולים להתחבר לאותו מסד נתונים. SQLite מניחה תהליך אחד (או כמה תהליכים שמשתפים פעולה) על אותה מכונה.
• הרשאות. ל-MySQL יש משתמשים, תפקידים ופקודות GRANT. מערכת ההרשאות היחידה של SQLite היא הרשאות הקבצים של מערכת ההפעלה על קובץ מסד הנתונים.

אף אחת מהצורות לא "טובה יותר". הן פותרות בעיות שונות.

מקביליות וכתיבות

כאן השניים באמת נפרדים. מנוע ה-InnoDB של MySQL מבצע נעילה ברמת השורה: חיבורים רבים יכולים לכתוב לשורות שונות באותו זמן בלי לחסום זה את זה.

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

-- SQLite: זה עובד היטב להרבה קוראים, כותב אחד בכל פעם.
PRAGMA journal_mode = WAL;

-- MySQL: הרבה כותבים, נעילה ברזולוציה עדינה.
-- (אין צורך בהגדרה מיוחדת: InnoDB עושה את זה כברירת מחדל.)

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

טיפוסי נתונים

ל-MySQL יש רשימה ארוכה וקפדנית של טיפוסים: TINYINT, INT, BIGINT, VARCHAR(n), DATETIME, DECIMAL(p,s), BLOB, JSON ועוד רבים. הצהירו על עמודה כ-INT, ו-MySQL תדחה מחרוזת.

SQLite משתמשת במקום זה ב_זיקת טיפוס_ (type affinity). טיפוסי עמודות הם רמזים, לא כללים נאכפים. אפשר לשים מחרוזת בעמודת INTEGER ו-SQLite תשמור אותה (אלא אם בוחרים בטבלאות STRICT, שנוספו בגרסה 3.37).

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    name TEXT,
    price REAL
);

INSERT INTO products (name, price) VALUES ('Coffee', 3.50);
INSERT INTO products (name, price) VALUES ('Tea', '2.75');  -- מחרוזת בעמודת REAL

SELECT id, name, price, typeof(price) FROM products;

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

הבדלי תחביר שבאמת תיתקלו בהם

רוב ה-SQL הבסיסי, SELECT, JOIN, WHERE, GROUP BY, זהה. ההבדלים מתרכזים בכמה תחומים:

• מפתחות ראשיים שעולים אוטומטית. SQLite משתמשת ב-INTEGER PRIMARY KEY (שעולה אוטומטית כברירת מחדל). MySQL משתמש ב-INT AUTO_INCREMENT PRIMARY KEY.
• ציטוט מחרוזות. MySQL מאפשר גרשיים הפוכים למזהים (`table`). SQLite משתמשת במרכאות כפולות ("table") לפי תקן SQL.
• פונקציות תאריך. ל-MySQL יש NOW(), CURDATE(), DATE_ADD(). ל-SQLite יש datetime('now'), date('now'), datetime('now', '+1 day').
• תחביר LIMIT. שניהם תומכים ב-LIMIT n OFFSET m, אז כאן יש תאימות.
• בוליאנים. ל-MySQL יש BOOLEAN (כינוי ל-TINYINT(1)). SQLite שומרת בוליאנים כ-0 ו-1 בעמודות INTEGER.

-- MySQL
CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    created_at DATETIME DEFAULT NOW()
);

-- SQLite
CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    created_at TEXT DEFAULT (datetime('now'))
);

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

ביצועים: זה תלוי בשאלה

לשאלה "האם SQLite מהירה יותר מ-MySQL?" אין תשובה אחת.

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

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

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

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

מתי כל אחד מהם הוא הבחירה הנכונה

בחרו ב-SQLite כש:

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

בחרו ב-MySQL כש:

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

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

מעבר ביניהם

להתחיל עם SQLite ולעבור ל-MySQL מאוחר יותר זו דרך מוכרת, ותוכנית טובה. הסכמות מתורגמות עם התאמות קטנות, והנתונים מיוצאים בצורה נקייה דרך .dump מה-CLI של SQLite. בעיקר תתקנו את תחביר העלייה האוטומטית, פונקציות תאריך, וכל תכונה ייחודית ל-SQLite (אינדקסים חלקיים בצורות מוזרות, WITHOUT ROWID, טבלאות STRICT) שאין לה מקבילה ישירה ב-MySQL.

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

הנקודה: הבחירה ב-SQLite היום לא נועלת אתכם. ה-SQL שאתם כותבים עובר הלאה, וכך גם ההבנה שלכם.

הבא: SQLite vs PostgreSQL

MySQL הוא ההשוואה הנפוצה ביותר, אבל PostgreSQL הוא מסד הנתונים השני שתראו מושווה ל-SQLite, וההבדלים שם שונים שוב. זה העמוד הבא.