הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
הפתעה לא נעימה מ־MySQL.
אני יודע ש־MySQL זה לא בסיס נתונים מושלם, בעל מיליון ואחד פיצ'רים מעולים הדרושים לכל בסיס נתונים ארגוני. אבל יש לו יתרון אחר גדול... הוא מהיר מאוד, הרבה יותר מהיר מ־PostgreSQL ו־Sqlite3 (לפחות לפי הניסיון שלי).
בחיפוש של מקום פנוי בדיסק שלי גיליתי קובץ ibdata1 בגודל של 260MB. בהתחשב בעובדה, שכל בסיסי הנתונים שהגדרתי, הם כמעט ריקים, זה היה חשוד מאוד. אומנם, יצרתי מספר בסיסי נתונים גדולים בעבר, אבל לא ציפיתי שכל זה עדיין יישאר.
חופש על "mysql shrink database" הביא אותי להבנה: לא ניתן לעשות כיווץ לטבלאות InnoDB, אלא אם אתה מגדיר ב־my.cnf, שכל טבלה תנוהל בקובץ נפרד:
[mysqld]
innodb_file_per_table
אבל איך לכווץ בסיסי נתונים קיימים? לא ניתן! אפשר לשמור dump של אותו בסיס נתונים. לשנות הגדרות mysql, למחוק את הקובץ ibdata1 באופן ידני ולייבא את הנתונים מקובץ קיים מחדש.
לאחר מכן, פעולה כמו:
optimize table xyz;
פשוט תעבדו לך, מחיקת בסיס נתונים תגרום למחיקת המידע מדיסק ואפילו delete from xyz; תגרום לריקון הקובץ! למזלי, לא היו לי בסיסי נתונים יקרים (הכל היה לצורך ניסויים), כך שיכולתי פשוט למחוק אותם ולוותר על תהליך dump. עם כל זה המצב היה מאוד מאכזב:
- מדוע הטבלאות לא מופרדות לקבצים שונים מלכתחילה?
- מדוע Debian לא דאגו לעשות את ההגדרות האלו כברירת מחדל?
- מי בכלל צריך לנהל מידע של כל בסיסי נתונים אפשריים בקובץ יחיד? לא צריך להסביר מדוע זה מסוכן.
מוסר השכל: אם אתה DBA של MySQL או סתם נפלה עליך משימה לנהל שרת MySQL, תמיד תגדיר עבודה עם קבצים מרובים, אחרת, יום אחד אתה תהיה בצרות. כמו מספר אנשים שנכלאו למצב בו, אין מספיק מקום פנוי בדיסק, כדי לעשות dump; וגם אין מספיק מקום בשרת בגלל הקבצים הענקיים שמסרבים לקטון.
תגובות
עוד משהו להוסיף לרשימה של "למה לא לעבוד עם MySQL" ... כמות הבעיות שאני מוצא עם MySQL כל פעם (בנוסף לבעיות הישנות שאני מכיר) גורמות לי כל פעם מחדש לחפש מסד נתונים אחר. אני יותר ויותר נוטה לכיוון של Firebird SQL או מסד הנתונים (שאני לא כל כך מסתדר איתו) PosgreSQL.
זוהי כמובן דעתי האישית מתוך הרבה כשלונות והבעיות הלא הגיוניות לפעמים שאני מוצא ב MySQL.
עידו (מי שכתב את התגובה שלפני), שווה לך לעשות בירור קצת יותר רציני לפני שאתה בוחר ב Firebird. אני אישית בעל השכלה וניסיון של DBA, ולפני שבועיים התחלתי לעבוד עם מוצר אשר משתמש ב Firebird. המוצר לא הוגדר היטב על ידי DBA, ו Firebird עצמו עושה המון בעיות. למשל, בעיות ביצועים קשות בזמן שליפה, מחסור בכלים נוחים לכל סביבה, מחסור בפיצ'רים שאתה רגיל אליהם ממסדי נתונים אחרים, וכו'.
להגיד לך את האמת, שכנעת אותי (כמעט). אז החלטתי להוסיף תמיכה ב־Firebird במערכת הבלוג שלי, כמו שהיא קיימת עבור MySql, PostgreSQL ו־SQlite3.
התחלתי להמיר את ה־schema של בסיס הנתונים (mysql ו־postgresql ) וגיליתי שכדי לעשות auto-increment או sequence על עמודה, אני צריך לבנות trigger... תשמע, זה היה "קצת" מאכזב.
אשמח אם תוכל להסביר לי כיצד לעשות autoincrement בקלות.
שלא לדבר על זה שלקח לי די הרבה זמן להבין כיצד אני מגדיר בסיס נתונים חדש (כל הוראות בגוגל אמרו משהו שלא עבד).
אם מישהו יוכל לעזור לי להסב את הטבלאות, (כדי שאני אשבור את הראש חצי יום מול google) אני מבטיח להריץ בדיקת ביצועים של mysql מול firebird על היישום שלי.
בנוסף, מישהו מוכן להסביר לי מדוע "begin;" מתלונן לי על "unknown tocken"???
איך אני עושה טרנזקציות ב־firebird?
"מדוע Debian לא דאגו לעשות את ההגדרות האלו כברירת מחדל?"
אין לי תשובה טובה, אבל אתה מוזמן לברר עם ה-maintainer, או לפתוח על זה wishlist bug.
משה, firebird בניגוד לשאר המסדי נתונים ה"רגילים" בנוי בשיטה של "הרחב" אותו בהתאם לצורך שלך. מה שיוצר מצב שאתה בונה אפליקציה שלמה שכל מה שהיא עושה זה מספקת לך כלים לעבוד עם מסד הנתונים שלך בצורה ממש נוחה. כלומר "מסד נתונים X לא מכיל את הפקודה sum ולכן הוא לא מתאים לי" לא עובד עם firebird. אם במקרה לא היה לו את הפעולה הזו, אתה יוצר udf שכן יכיל אותו. בתור איש DBA, אתה יודע שכל מסד נתונים חזק בצד אחד וחלש בצד אחר. הבעיה עם MySQL היא, שתוך כדי עבודה מגלים הרבה חסרונות ממש ענקיים במסד הזה, ואתה מגלה שהייתרון של מנוע כדוגמת InnoDB מביא גם כמה חסרונות אחרים שאתה לא יכול להרשות לעצמך. עם Firebird אתה חייב ללמוד לעבוד, כי התפיסה שלו שונה לגמרי ממה שאתה מכיר בשאר מסדי הנתונים. היו לי כמה שנות ניסיון עם Interbase ואני מכיר כמה אנשים (כולל מאיר) שגם הם מסתדרים לא רע עם המסד נתונים הזה.
ארתיום: אפילו ב PosgreSQL יש לך טריגרים ל auto inc. הסיבה ד"א ממש נחמדה: אתה יכול להחליט איך האינדוקס יתבצע. יהיה לי יותר קל לעזור לך אם תציג לי בעיות ספציפיות מההתחלה כולל מה שאתה עושה. יש לך את האימל שלי (ועכשיו שחזרתי לארץ, אני אוכל גם לקרוא אותו :) )
לא ממש אכפת לי כיצד זה ממומש. מצידי, שיקרא לפונקציית Pascal שתעשה עדכון של counter אטומי בזכרון משותף ויקמפל את הטריגר בזמן אמת, כל עוד...
אני יכול להגדיר את הפעולה בשורה אחת (או אפילו מילה אחת בשורה).
אני לא רוצה לכתוב טריגר של 6--7 שורות רק כדי לעשות auto-increment פשוט.
אני יכול לעשות את זה בקלות ב־PostgreSQL, MySQL, Sqlite3. אני לא רואה סיבה שזה ייקח יותר מאמץ ב־Firebird.
השאלה השניה: כיצד אני מתחיל טרנזקציה ב־firebird, הוא משום מה לא מקבל "begin".
תנסה begin transaction (לא, אני מעולם לא פתחתי firebird, אבל סביר שהפקודה המלאה תתקבל אם הקיצור נדחה).
דבר ראשון יצרתי בשבילך (טוב נו, גם בשבילך :)) מיני מדריך לעבודה עם Firebird. דבר שני, בברירת מחדל, Firebird עובד עם טרנזאקציות לפי חיבור. כל חיבור שלך למסד הנתונים הו טראנזאקציה לכל דבר ועניין. לכן כל פעולה שאתה עושה צריכה תאורטית להסתיים עם commit (או rollback).
בד"כ כשאני (הייתי) מתכנת לFirebird, הייתי משתמש בפקודה Connection.Transaction ולא עושה את זה ברמת ה SQL.
לא, זה לא עובד :(
תודה ראיתי :)
או קיי, זה קצת מפריע לי, כי ברוב מסדי נתונים:My/Lighte/Pg יש טרנזקציות ברמת פקודה (auto commit), אלא אם אתה מתחיל טרנזקציה מפורשת.
צריך לחשוב איך זה ישפיע על עבודה... במילים אחרות, אם אני רוצה קוד שיעבוד עם כל בסיסי נתונים, אני חייב לעשות טרנזקציה מסביב כל פעולה שאני רוצה לבצע. זה די מפריע במיוחד שאני לא ממש צריך לאחד פעולות בלתי תלויות לאותה טרנזקציה, ואני גם לא רוצה לשלוח begin-commit מסביב שורה בודדת.
אפשר להפעיל איכשהו את auto commit ב־firebird כדי שאוכל להשתמש באותו קוד בין מערכות שונות?
הוסף תגובה:
חובה לאפשר JavaScript כדי להגיב.