קטגוריה: mongodb

כשיש לך פטיש אוויר ביד …

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

כאשר אותו בחור הבין שבחרתי בסינטרה ולא ב wp, הוא לא הצליח להבין מדוע לא לבחור ב wp, היות ולדעתו ניתן לעשות עימה הכל.
ניסיתי להסביר לו כי מדובר בoverkill עצבני, כלומר לקחת פטיש אוויר לעשות חור בקיר לתלות תמונה, כאשר מסמר פשוט עם פטיש קל מספיק, הוא עדיין לא הבין את הבעיה, הרי אפשר לעשות אתרים ממש גדולים עם wp, אז מדוע אי אפשר לקחת אותו בשביל משהו פשוט ?

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

שימוש בסינטרה מאפשר לי לקחת פריימוורק כדוגמת foundation או bootstrap כ css ובנוסף לשלב את ember/angular או סתם את jquery/dojo בהתאם לצורך.

עבור מסדי נתונים, אני גם מקבל גמישות, כך שאם חלילה וחס אני נאלץ לגעת ב MySQL/MariaDB (לרוב להתחבר למסד נתונים קיים) אין בעיה (לפחות ההתחברות, עם הגועל זה משהו אחר), ואם אני בר מזל ויכול לבחור מסד נתונים, אז אבחר ב PostgreSQL , ואם יש צורך אז אבחר בכלל במונגו או אולי בכלל בRedis ?

אם אני צריך, אז אוסיף למשל סוג של job queue בהתאם לצורך הספציפי והרשימה לעבודה עוד ארוכה…

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

אבל כנראה גם הפעם מאסלו צדק, וכשיש  לך פטיש ביד, הכל נראה לך מסמר …

תובנות השוק מהרצאה שהעברתי

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

ההרצאה היתה על git וההבדלים בינו לבין svn. היות והוא הגיע למצב בו מפתחים כל הזמן דורכים אחד על השני, ורציתי להציג להם דרך אחרת או אולי נוספת לעבוד, לא במקום svn, אלא בנוסף (תודה לסוייר על המצגת שהוא יצר בזמנו בנושא, והסכים לתת לי אותה).

לאחר מכן, העברתי הרצאה על No(t only) SQL. בהרצאה העברתי הסבר מה זה בגדול אומר, איך מבינים בכלל מתי, ואיך הוא מתאים לנושא, התמקדתי בMongoDB ובRedis. שני מסדי נתונים אשר אני משתמש בהם.

הדגמתי להם לפי צורות העבודה שלהם, כיצד הם יכולים לשפר להם את הביצועים, למנוע בעיות עומסים שונים וכו'

בסוף ההרצאה ניגש אלי אחד העובדים – מפתח #C, ומתכנת באמת מוכשר, ואומר שזה הכל נחמד ויפה, והכרתי לו הרבה דברים חדשים, אבל אם אין הכשרות של זה בשוק (הישראלי), אין סיבה להשתמש בטכנולוגיות האלו.

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

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

לאחר השיחה הבנתי (שוב) – רוב האנשים והשוק אינם מסוגלים לראות מעבר לכאן ועכשיו. הם לא מסוגלים לדמיין כי דרכי העובדה שלהם צריכים להשתנות כאשר הם אינם מקבלים מענה נכון, היא פעולה מאוד חשובה, אך אם אנשי המקצוע אינם מכירים עוד כלים, הארגון תמיד יהיה תקוע באותו המקום עם אותן הבעיות.

או כפי שאברהם מאסלו אמר פעם – כאשר יש בידך פטיש, הכל נראה לך מסמר
אתה פשוט לא מסוגל להבין כי לפעמים יש שימוש גם למברג, שפכטל וכו' …

ניהול מפתחות

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

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

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

טיפים לעבודה בmongodb חלק ראשון

עשיתם מהלך מדהים וזה במקום להשתמש בכלים "רגילים" הבנתם (אני מקווה) שמסד נתונים מבוסס מסמכים מתאים יותר עבור המשימה הספציפית שלכם (כלומר אם זה לא המצב, אז בבקשה תשקלו בשנית), והחלטתם כמוני ללכת לmongodb ליישם את זה.

אחד המקומות הראשונים שנופלים במונגו הוא בעדכון מידע (בחלק הבא אדבר על חיפוש מידע). ישנם כמה צורות לעדכון מידע. למשל השימוש ב save מול update אשר שניהם מבצעים את אותה הפעולה רק בגישות שונות. אבל יותר מזה, השימוש ב update לרוב בהתחלה אינו מבוצע נכון וגורם לתסכול רב (לפחות לי זה קרה).

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

אבל ההבדל האמיתי הוא ש save מקבל אובייקט ומוסיף או מעדכן אותו כמו שהוא, בעוד ש update מקביל לפעולת where ב SQL, מאפשר לנו למצוא משהו לפני כן, ואם הוא נמצא מעדכן ואם הוא לא נמצא אנחנו יכולים להגיד לו בפרמטר של upsert להגיד לו להוסיף את הרשומה. כך שאנחנו חייבים גם להיזהר כאן כי במידה וחשוב לנו לעדכן רק כאשר המידע נמצא, ולא לעדכן אם הוא לא, אז פעולת where תתאים לנו, אבל רק אם נעבוד איתה נכון (קרי upsert יהיה false).

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

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