הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
מדוע אני אוהב MySQL...
אני יודע שיש אנשים שלא סובלים MySQL ומעדיפים כל דבר על פניו. יש הרבה ביקורות כלפי MySQL ויש לו לא מעט בעיות... אבל, מתוך ניסיון עבודה עם MySQL, Sqlite3, PostgreSQL וניסיון מועט בעבודה עם Firebird ו־MS SQL... אני מעדיף MySQL ובמקום השני Sqlite3.
מודע? כי הוא לא דורשים ממך תואר ב־DBA כדי להשתמש בו. הוא נותן לך כלים טובים ונוחים, לשמור, לנהל ולשלוף מידע בצורה פשוטה ונוחה; והסיבה העיקרית לכך:
הם עושים את הדבר הנפוץ פשוט
דוגמה 1: יצירת unique row id
אני יודע עידו כל־כך לא אהב איך שזה עובד ב־MySQL. אבל זה עובד בצורה פשוטה מאוד. יותר מזה היא מתנהגת בצורה הגיונית (לפחות בעיני).
דוגמה: אם אני יצרתי schema:
create table users (
id integer NOT NULL AUTO_INCREMENT,
name varchar(32) NOT NULL
);
ואז מייבא נתונים קיימים:
insert into users(id,name) values(1,'Yossi');
insert into users(id,name) values(2,'Moshe');
ואז מוסיף משתמש חדש:
insert into users(name) values('Artyom');
אני אקבל id=3 כפי שניתן לצפות. מצד שני, ב־PostgreSQL אני חייב לעדכן sequence אחרי הכנסה של ערך ידני, אחרת אקבל התנגשויות.
ב־Firebird אתה בכלל חייב תואר שלישי ב־DBA כי ליצור auto-increment כי זה נעשה רק עם trigger.
או קיי, אבל מה אם אני רוצה לעשות משהו מסובך באמת שלא נתמך ע"י auto_increment פשוט? אז גם זה אפשרי עם כתיבת trigger. אבל המקרה הנפוץ הוא פשוט.
דוגמה 2: הוספה או עדכון
עוד משהו שתמיד הפריע לי ב־SQL הסטנדרטי, כיצד אני עושה Update אם ערך קיים או insert אם הוא לא קיים?
פעולה מאוד נפוצה שאני ממש לא מבין לא היא לא חלק מ־SQL סטנדרטי... ב־MySQL וגם ב־Sqlite יש replace וגם יש לך אופציות שונות איך להתנהג אם ערך קיים: להתעלם, לעדכן, לעשות rollback וכד'.
איך עושים את זה ב־PgSQL? כותבים פרוצדורה של... תעשו חיפוש בגוגל, אני רוצה לדעת אם מישהו ימצא פתרון בפחות מ־5 שורות SQL... כנ"ל Firebird ו־MS SQL. למשל, כך עושים את זה ב־Firebird, מישהו היה מנחש?
אני יודע ש־MySQL אינו בסיס נתונים מושלם, יש לו הרבה בעיות ונקודות בהן אפשר ליפול... אבל יש לו יתרון אחד גדול, אתה לא חייב להיות DBA כדי להשתמש בו.
תגובות
אחת הדרישות לניהול מידע במסדי נתונים זה להבין מה אתה צריך ואיך אתה צריך לשמור אותם. אחרי שאתה יודע איך אתה צריך לשמור אותם, אתה צריך לדעת איך אתה הולך להשתמש במידע הזה ואז אתה יודע איך ליצור אינדקסים בצורה נכונה. הבעיה במסדי נתונים היא שככול שהשימוש במידע גובר לאורך זמן, ויש לך יותר שינויים ותוספות, ככה האינדקסים שלך משתנים, ולפעמים אתה בכלל צריך לסוג פעולות מסויים סוג מסויים של אינדקס ולסוג אחר של פעולות אינדקס אחר, אבל בלי לדעת את זה אתה בחיים לא תצליח לבנות טבלה כמו שצריך, וגם אם נעזוב כרגע תחביר של דברים, אתה חייב להבין מה אתה עושה.
אין לי תואר של איש DBA, כמעט כל פעם שאני עובד עם מסדי נתונים, אני לומד עוד ועוד דברים, אבל העניין הוא לא כמה קל לכתוב את השאילתא, אם אני צריך ליצור פעם אחת טריגר והוא ירוץ בעצמו, או לא. העניין הוא האם אני מבין ומסוגל בכלל להשיג את המטרה.
למשל עם כל הכבוד שיש לי ל sqlite (ויש לי המון כבוד אליו), יש לו הרבה דברים בסיסיים מאוד שכל מסד נתונים "גדול" שאני מכיר מכיל, והוא לא. למשל לעשות pivot table בין מידע הוא לא דבר כזה טבעי.
בFirebird אתה יכול לעבוד עם חריגות (קרי Exceptions) ואתה יכול לנצל שגיאות בשביל לטפל בדברים בצורות שונות, ואפילו ליצור Exception משל עצמך, שגם התוכנית שלך בשפת ++C תדע לנצל בקוד טבעי. אז כן על הנייר stored procedure נחשב ליותר מסובך, אבל נראה אותך מתמודד עם רבע מהדברים שאפשר לעשות עם stored procedure ב mysql. (כן אני יודע שיש לה תמיכה בזה, אבל היא ממש לא מתקרבת ל PosgreSQL ו Firebird).
ברור... אפילו דבר יותר בסיסי Foreign Keys...
אבל הנקודה שלי היא שונה... צריך לפשט דברים נפוצים.
כל בסיסי נתונים "מתוחכמים" האלה כמו Firebird ו־PgSQL צריכים לדאוג להיות הרבה יותר ידידותיים למפתח. ראה דוגמה שניה.
זאת הייתה הנקודה. כל־עוד Firebird דורש ממני לכתוב trigger עבור sequence / autoincrement / unique id אני כנראה אחשוב פעמים לפני שאחליט להשתמש בו/לתמוך בו, אפילו ש"דולפינים עלולים לגרום לי לבכות" ;)
אני לא יודע כמה יצא לך לעבוד ב production מסחרי, או כמה ניסיון יש לך בכתיבת שאילתות מאוד מורכבות של כמה עשרות שורות בהוראת select אחת.
אחד הייתרונות של PgSQL ושל Firebird אל מול MySQL הוא שהם מסוגלים לספק כלים טובים יותר לעבודה מאשר כמה עשרות שורות של הוראת select.
ב Firebird למשל, כל הנושא של אינדקסים הרבה יותר גמיש מכל מסד נתונים אחר שאני מכיר, היות ובמידה ואתה מתחייל לפנות לשדה אחד שהוא לא אינדקס, אבל אתה בודק בעיקר דרכו, הוא יתחיל לסדר לך את הנתונים לפי השדה הזה. שזה ד"א בדיוק ההפך מלהיות איש DBA.
אם אתה כל כך לא רוצה לכתוב הרבה כאשר אתה יוצר טבלה, תשתמש בכלים כדוגמת Flame Robin הוא כותב בשבילך את היצירה של הטריגר אם לומדים לעבוד איתו, אבל משאיר לך את האפשרות גם לכתוב בעצמך.
אבל הטענה שלך שבגלל שבזמן יצירת הטבלה אתה צריך לכתוב יותר קוד, היא טענה טפלה לדעתי האישית, ולא משקפת את השיקול של האם המסד נתונים מספק לך את מה שאתה צריך. אני יודע שאחרי שבזמן production המסד נתונים mysql התנהג בצורה לא מתועדת, ושפגעה פיזית בלקוח שלי, שהשיקול אם להשתמש בו שוב פעם הוא לא כזה טריוויאלי ודורש שיקול הרבה יותר כבד מ"האם אני צריך לכתוב עוד 10 שוקות sql פעם אחת, ולקבל אמינות גבוהה יותר או לא".
יש בעיות עם הצורה ש-MySQL מנהל את ה-auto increment שלו, במיוחד עקב הצורך שלו לנעול את הטבלה או בניית האינדקס מחדש ב-alter table על ה-auto increment.
השימוש ב-sequence מדוייק ונכון הרבה יותר, וכך גם mysql היו צריכים ליישם אותו, ההחלטה שגויה בעת הריח של האק מובילה לבעיות וביצועים ירודים. ראו גם כאן: http://techblog.tilllate.com/2008/04/13/pitfalls-with-mysql-and-auto_increment/
בנוסף ב-pgsql אין צורך ב-trigger. הגדרת עמודה כ-serial עושה זאת עבורך אוטומטית (יצירת sequence וערך ברירת מחדל של nextval).
באופן אישי אשמח כשהשימוש ב-mysql ייעלם והוא יפסיק להרוס לי את החיים. לפעמים הוא מרגיש ממש כמו צעצוע. אתה מוזמן לקרוא את הודעות הדוא"ל שאני מקבל בווטסאפ על corrupt tables, הרי דביאן מגדירים משתמש מיוחד שכל תפקידו לטפל בתחזוקה שלו כולל בדיקת הטבלאות (וכאן הוא יותר קשה מהאחרים) או העצבים שאני מקבל מ-replications שיוצאים באופן קבוע מסינכרון. לתחזק ולהשתמש בו בפועל מצריך ממני יותר DBA מאשר האחרים.
דביאן מגדירים משתמש נוסף כדי של־root (המשתמש על מערכת הקבצים) יהיו הרשאות מלאות בפועל. מאוד שימושי בזמן התקנת חבילות.
ב־pgsql זה לא ממש נחוץ: משתמש המערכת postgres הוא בעל ההרשאות הללו. ו־root יכול להצע פעולות התקנה ותחזוקה ע"י su postgres
הי ארתיום,
בדרך-כלל אני מאוד אוהב את מה שאתה כותב. הפעם לא, וברמה האידיאולוגית. תחשוב רגע על המשפט הבא:
"אני אוהב את VB6, כי לא צריך תואר במדעי המחשב בשביל לתכנת איתו".
אני לא יודע על "תואר של DBA", אבל צריך הבנה של בסיסי נתונים בשביל לעבוד איתם. ספציפית, sqlite לא מתאים לשימוש ב-production עם נתונים חשובים, כי הוא לא שומר אפילו על דברים אלמנטריים כמו סוג הנתונים (זה שהגדרת טור כ-int לא יפריע לך לדחוף לתוכו מחרוזות). ל-MySql יש בעיות משלו, לא כאלה בוטות, אבל מאותה המשפחה (לא בדקתי בגרסה 5, אבל הוא נהג לקבל 30 בפברואר בתור תאריך, ולקצץ מחרוזות ארוכות-מדי בלי הודעת שגיאה).
העובדה שבסיס-הנתונים מאפשר לך לירות לעצמך ברגל בכזאת קלות היא לא יתרון. כלומר, היא יתרון שיווקי, אבל אוי למי שסומך על משענות-הקנה-הרצוץ האלו.
אז בואו ננסח את זה אחרת. אני אוהב בסיס נתונים כזה שמאפשר לי לעשות דברים נפוצים בקלות.
באותה מידה, אם יש לי אוסף כלים לתכנות, אני רוצה שיהיה לי מימוש של hash או rb-tree מוכן, מאשר אני אכתוב אותו בכל פעם מחדש.
כנ"ל בסיסי נתונים:
גם לא מסכים, sqlite אולי לא מתאים בתור data-warehouse אבל הוא כן בסיס נתונים מצוין (והוא אכן כזה) שנמצא בשימוש מאוד רחב, כולל רכיבי ייצור מורכבים.
להגיד דבר כזה זה בדיוק כמו להגיד ש־Perl/PHP לא שומר על טיפוס משתנה ולכן, אתה לא יכול להשתמש בו בייצור כי אתה יכול לחבר מחרוזת עם int.
כנ"ל, אתה יכול לירות לעצמך ברגל ברוב שפות התכנות בקלות מאוווווד רבה, למשל, ב־C++ אתה יכול לכתוב
ולהרוג את היישום שלך בקלות. האם זה אומר שאסור לכתוב ב־C++? (אגב, מישהו פה יגיד שכן ;) )
באמת, כמו כל כלי אחר, MySQL הוא לא ממממממש אידיאלי, אבל אני בטוח שבכל בסיס נתונים, כמו Oracle/MS SQL/PgSQL/Firebird אם לחפור אפשר למצוא המון רגליים לירות בהן.
MySQL היסטורית ותפיסתית הוא מאוד task oriented. למשל, full text indexing שקיים עוד מתקופה של MySQL 4 לא קיים ב־Firebird ולא ב־PgSQL (או אם אני לא טועה רק ב־Pg האחרונים).
מדוע הוא קיים? צורך web הנפוץ ביותר. ככל שאני עובד איתו יותר, אני מבין שלמעשה, הוא עושה אופטימיזציה לדבר הנפוצים --- תכונות שיש להם ביקוש בקהילה האמתית.
לגבי הקיצוץ של מחרוזות ארוכות, MySQL יודע לתת שגיאה כאשר המידע לא תואם את ההגדרה של העמודה, הבעיה היא שהאופציה הזאת (משהו strict, לא זוכר כרגע) לא מופעלת באופן דיפולטיבי ב my.cnf, לפחות לא על centos.
האמת היא שלא ברור לי למה זה ככה באופן דיפולטיבי, אם אני מגדיר VARCHAR(100), אני מצפה שאני לא אוכל להכניס מידע ארוך יותר מ 100 תווים... סוג של באג בהגדרת הקונפיגורציה הבסיסית.
ארתיום, כמו שכתבתי בעבר, אינדקסים זה לא דבר כזה פשוט ליצור. אם כל האינדקס שלך הוא רשימה עולה ואתה משתמש רק ברשימה הזו אז אוקי, הרווחת כמה שורות קוד שלא כתבת, אבל אם האינדוקס שלך הוא מעט יותר רציני מזה (לא שרשימת מספרים בסדר עולה היא לא צורך), אז אין ל MySQL שום יתרון.
עכשיו במידה ואתה מגיע למצב שאתה צריך לשמור על סדר עולה, אבל לא תמיד יש לך נתונים בטבלת mysql (הבעיה שאני נתקלתי בה), פתאום ברגע שתאתחל את השרת או את mysql או שתנסה לגשת למידע בזמן כתיבה ע"י אותו process תקבל פתאום deadlock רק בגלל שהזנת נתונים.
גם ב Firebird וגם ב PgSQL אתה לא תגיע ל deadlock על זה. אתה לוקח בתור highlight את הכתיבה ואת זה שקל מאוד ליצור auto inc, אבל מה עם כל מה שקשור אליו מסביב ?
הכמות אנרגיה של כל דבר מסביב ל auto inc אם אתה חורג ולו מעט למה ש MySQL התכוונו אליו, דורש ממך לתזמן שאילתות, דורש ממך לנהל לבד את ה auto inc או אחרי כל אתחול להשתמש ב alter table ולשנות ידנית את הערך של האינדקס, וזה בלי לדבר על מליון בעיות אחרות שיש שלא קשורות לאינדוקס בכלל.
אתה אומר שזה שאפשר לירות בעצמך ברגל, לא אומר שום דבר לגבי יכולות. שמע אין מסד נתונים טוב, יש אבל מסדי נתונים רעים ורעים מאוד. לדעתי, MySQL הוא מהרעים.
לגבי Full Text Search, ההשוואה שלך מול Firebird (בלבד) היא לא נכונה היות והפילוסופיה של firebird שונה משאר המסדי נתונים. הפילוסופיה של firebird אומרת שאתה מרחיב את היכולות של המסד נתונים שלך בהתאם לצורך שלך. כלומר אתה משתמש פיזית בספרייה משותפת עם פונקציות בשביל להרחיב את Firebird ממש כמו שאתה עושה binding לשפות אחרות. ל firebird יש full text search רק לא בברירת מחדל, אלא בתור כלי שמגיע בנוסף. בוא נשאל אותך שאלה כזו: מה קורה אם ה Full Text Search של MySQL לא עובד בשיטה שאתה רוצה ? האם תגיד "אין מה לעשות" או האם תנסה לבנות משהו משל עצמך מחוץ לMySQL או אולי תנסה למצוא איזה Patch שיתקן/ישנה משהו ?
וסתם שאלה, אתה לא זה שכתב פוסט על זה שאומנם ++C לא מגיע עם שום ספרייה יותר ממשהו בסיסי, אבל זה לא הופך אותו ללא שמיש ? זה לא קצת צבוע ממך להיות עם הגישה הזו בצורה סלקטיבית ?
הטענות שיש לי למשל על ++C הוא שמאוד קל לך לירות בעצמך ברגל. ולמרות כל הטכנולוגיות בפנים, כאשר אתה רוצה לעשות משהו שימושי, או שאתה צריך לוותר על חלק מהטכנולוגיות, או שתשתמש בספרייה כלשהי שתהיה צד שלישי לעניין, דבר שגורם למצב די מגוכך עם השפה ומראה שעודף טכנולוגיות בשפה לא הופך אותה לטובה יותר, אלא רק ללא שימושית, למרות שכולם מנסים להוכיח שהיא כן, כמות האנשים שמצליחים כל כך מעטה שזה מדהים.
צפריר: נכון, אך לא סותר את מה שכתבתי - משמש גם לבדיקת טבלאות הרוסות. לא זכור לי שראיתי צורך במשהו דומה בבסיסי נתונים האחרים הומזכרים כאן.
תחזוקה? זכור לי מסד נתונים שעד לא מזמן היה צריך עוזרת בית צמודה (VACCUM)
vaccum זה משהו אחד, טבלאות הרוסות זה משהו אחר.
אם אני לא טועה, נושא של טבלאות הרסות רלוונטי רק ל־MyISAM ולא ל־InnoDB כי MyISAM לא תומכת בלוג טרנזקציות.
היום, אלא אם יש לך סיבות מיוחדות כמו אינדקסים מיוחדים (שבין כה לא נתמכים לרוב ע"י pg/firebird) אין שום סיבה להשתמש ב־MyISAM.
הוסף תגובה:
חובה לאפשר JavaScript כדי להגיב.