להגדיר את levelUp db כserver נפרד שמקשיב לארוע, כיצד, והאם כדאי?
-
שלושה שאלות:
א. איך להתמודד עם ספריית db שלא מאפשרת יותר מקליינט אחד
ב. האם חלוקת האפליקציה יעילה במקרה שספריית הDB בכל מקרה תהיה על מופע אחד וממילא מעבד אחד
ג. איך עובדים DB רגילים חיצוניים.כל השאלות קשורות מאוד אחת לשניה והם נכונות מאוד.
א. בדיוק כפי שאמרת. להקים מופע מיוחד לנושא השמירה.
כתובת לוקלית זה מבודד עוד יותר כך שזה יכול להיות בכלל מופע אחד ולא סתם אחד הפורקים (אולי לזה התכוונת) וזה אכן טוב יותר.ב. יעילה ועוד איך, כי הdb עלול להיות ברובו IO, שלא תוקע את הevent loop.
פרקטית, אתה יכול ליצור מופע משותף לכל הפורקיםג. בדיוק נגעת בנקודה:
בDB אחרים ישנה תוכנה שרצה על אותו המחשב או על אחר (עוד יותר יעיל) והיא מאזינה לרוב בפרוטוקול TCP ובכתובת פנימית.
זה מפזר את ההתקנה והתחזוקה של האפליקציה על פני שתי נושאים: שירות הנתונים, והאפליקציה עצמה.
ככה זה גם במסדים המסורתיים וגם בNoSql.
אלא שיש סוג נוסף שנקרא Embedded Databases שזה בעצם אומר שהקוד שלך הוא עצמו שרת הנתונים (אלא שהוא משתמש עם ספריה בשביל כל המורכבות של השמירה והשליפה וכו'). יש לזה מעלות אבל גם חסרונות בדיוק מסוג הדילמה שלך כעת. -
@dovid אמר בלהגדיר את levelUp db כserver נפרד שמקשיב לארוע, כיצד, והאם כדאי?:
ב. האם חלוקת האפליקציה יעילה במקרה שספריית הDB בכל מקרה תהיה על מופע אחד וממילא מעבד אחד
לא בגלל שמוקצה לו מעבד אחד, אלא כיון במקרה הספציפי בו 99% מהקריאות ל-DB מגיע מהאפליקציה כך שהגישה ל-DB הוא ממש מקומי, לא מהווה יתרון במהירות מול תקשורת לאפליקציה אחרת, קודם כל, ברמה הכללית,
וגם אם התשובה היא כן צריך לכמת אותה מול החסכון בפעולות החישוב ע"י החלוקה לליבות.
סייג נוסף, ה-DB כתוב ב-C (המופע בnodej-s הינו קוד אוביקט המכיל פונקציות וגשר ל-DB), לכן יתכן (אינני יודע) שה-DB עצמו כן יודע לבזר את העבודה על כל הליבות (הרי ב-C אפשר לשכפל תהליכים עם שיתוף קטעי זכרון).@dovid אמר בלהגדיר את levelUp db כserver נפרד שמקשיב לארוע, כיצד, והאם כדאי?:
כתובת לוקלית זה מבודד עוד יותר.
איך יוצרים כתובת לוקלית ו\או תקשורת TCP ב-nodejs ל-DB?
וכתובת לוקלית מבודדת יותר ממה?זה יכול להיות בכלל מופע אחד ולא סתם אחד הפורקים (אולי לזה התכוונת) וזה אכן טוב יותר.
כן התכוונתי לאחד הפורקים, עכשיו אני מבין שזה לא יתכן כיון שעותק האפליקציה שתענה לקריאה הינו אקראי, ויתכן שזה יהיה העותק שלא מכיר את הכתובת המיועדות ל-DB.
אבל אני גם לא מבין מה הכוונה "מופע אחד"?@dovid אמר בלהגדיר את levelUp db כserver נפרד שמקשיב לארוע, כיצד, והאם כדאי?:
בDB אחרים ישנה תוכנה שרצה על אותו המחשב או על אחר (עוד יותר יעיל) והיא מאזינה לרוב בפרוטוקול TCP ובכתובת פנימית.
זה מפזר את ההתקנה והתחזוקה של האפליקציה על פני שתי נושאים: שירות הנתונים, והאפליקציה עצמה.נכון
אבל כאמור, בדרך כלל ה-DB הינו מרכזי שמרכז את כלל המידע (גם אם של נישה מסוימת) ומגוון אפליקציות ניגשות אליו
השאלה אם זה נכון למקרה שה-DB הינו ממש חלק אינטגראלי מהאפליקציה במובן שהאפליקציה משתמשת המון ב-DB וה-DB משמש רק את אותה.מצד שני זה שונה מ-
@dovid אמר בלהגדיר את levelUp db כserver נפרד שמקשיב לארוע, כיצד, והאם כדאי?:
אלא שיש סוג נוסף שנקרא Embedded Databases שזה בעצם אומר שהקוד שלך הוא עצמו שרת הנתונים (אלא שהוא משתמש עם ספריה בשביל כל המורכבות של השמירה והשליפה וכו'). יש לזה מעלות אבל גם חסרונות בדיוק מסוג הדילמה שלך כעת.
יש גם מאגרי מידע שיושבים על הזכרון כמופע באפליקציה
חושב שעדיף שהם ישוכפלו לכל פורק, ולחסוך את בלגן השיתוף, במקרה זה זה מתאפשר כיון שהם סטטיים. -
@אהרן אמר בלהגדיר את levelUp db כserver נפרד שמקשיב לארוע, כיצד, והאם כדאי?:
@dovid אמר בלהגדיר את levelUp db כserver נפרד שמקשיב לארוע, כיצד, והאם כדאי?:
ב. האם חלוקת האפליקציה יעילה במקרה שספריית הDB בכל מקרה תהיה על מופע אחד וממילא מעבד אחד
לא בגלל שמוקצה לו מעבד אחד, אלא כיון במקרה הספציפי בו 99% מהקריאות ל-DB מגיע מהאפליקציה כך שהגישה ל-DB הוא ממש מקומי, לא מהווה יתרון במהירות מול תקשורת לאפליקציה אחרת, קודם כל, ברמה הכללית,
וגם אם התשובה היא כן צריך לכמת אותה מול החסכון בפעולות החישוב ע"י החלוקה לליבות.
סייג נוסף, ה-DB כתוב ב-C (המופע בnodej-s הינו קוד אוביקט המכיל פונקציות וגשר ל-DB), לכן יתכן (אינני יודע) שה-DB עצמו כן יודע לבזר את העבודה על כל הליבות (הרי ב-C אפשר לשכפל תהליכים עם שיתוף קטעי זכרון).הייתרון לא מושג בזכות גישות חיצוניות. גם אם כל הגישה היא מאותו מחשב ואותו אפליקציה מיניה וביה יש ייתרון בגלל שאר פעולות האפליקציה שיפוצלו מבחינה עיבודית ואילו הDB לא ייתקע את הליבה שלו כי הוא עובד לרוב בIO.
העלות של החלוקה לליבות לא ראויה לציון לדעתי (כל עוד יש cpu blocking באפליקציה).
בקשר לleveldb אני חושב שזה לא מרובה תהליכים אפילו שזה כתוב בC, ייתכן ואני טועה, תוכל לבדוק זאת.איך יוצרים כתובת לוקלית ו\או תקשורת TCP ב-nodejs ל-DB?
וכתובת לוקלית מבודדת יותר ממה?מה בדיוק השאלה?
בדרך כלל בכל אופן משתמשים בספריות מוכנות אבל לא הבנתי מה שאלתך.עכשיו אני מבין שזה לא יתכן כיון שעותק האפליקציה שתענה לקריאה הינו אקראי, ויתכן שזה יהיה העותק שלא מכיר את הכתובת המיועדות ל-DB.
זה לא מדוייק, יש להם מספרי תהליכים, ויש גם פורק שנקרא master, בקיצור תוכל לעשות באחד משהו ולא באחרים אבל זה אכן נשמע לי לא בריא ולא תפקידו של הפורק שזה שכפול מלא של התנהגות (למעט ניהול המופעים שבד"כ עושים באחד - במסטר).
אבל אני גם לא מבין מה הכוונה "מופע אחד"?
proccess נפרד לגמרי. פשוט שירות נוד שיטפל רק בנתונים.
אבל כאמור, בדרך כלל ה-DB הינו מרכזי שמרכז את כלל המידע (גם אם של נישה מסוימת) ומגוון אפליקציות ניגשות אליו
השאלה אם זה נכון למקרה שה-DB הינו ממש חלק אינטגראלי מהאפליקציה במובן שהאפליקציה משתמשת המון ב-DB וה-DB משמש רק את אותה.זה לא השיקול, המעלה של DB נפרד הוא לא רק לטובת ריבוי אפליקציות או קליינטים. זה מיטוב של יכולת הDB. בבית אתה יותר טוב מאשר בתור אורח. גם זה מידור ומידול, זה טוב שהשואב אבק עובד גם אם התנור נתקע - וקל לבודד את היחידות כשהם הופכים להיות כל אחת למספיק משמעותית בזכות עצמה.
יש גם מאגרי מידע שיושבים על הזכרון כמופע באפליקציה
חושב שעדיף שהם ישוכפלו לכל פורק, ולחסוך את בלגן השיתוף, במקרה זה זה מתאפשר כיון שהם סטטיים.אפשר לתקשר בין הפורקים, אבל נטו טקסט ולא שיתוף של אובייקטים.
-
העלות של החלוקה לליבות לא ראויה לציון לדעתי (כל עוד יש cpu blocking באפליקציה).
בשביל זה אני קודם משדר את השאילתות ל-DB ואז מפעיל את הקוד החישובי, בהנחה שכשהאפליקציה מגיעה לשלב החישובי, ה-DB עדיין עובד במקביל.
מה בדיוק השאלה?
בדרך כלל בכל אופן משתמשים בספריות מוכנות אבל לא הבנתי מה שאלתך.פשוט דוגמת קוד ליצירת תקשורת TCP בלוקלהוסט.
אבל עדיף שאפתח אשכול נפרד לשלות בניתובים.proccess נפרד לגמרי. פשוט שירות נוד שיטפל רק בנתונים.
fork לא פותח proccess נפרד לגמרי?? ממה שקראתי הוא גם משכפל מופעים של נוד.
-
עבודה עם TCP היא בדיוק אותו דבר למקומי ומרוחק.
בד"כ כשבונים שתי מערכות נוד באותה מכונה יש צורות תקשורת שעוטפים את הTCP ומקילים את החיים, למשל כמו ZeroMQ.פורק זה תהליכי משנה נראה לי. אבל פורק זה כפל של אותו קוד בדיוק. ופה אנחנו מדברים על מופע לצרכי הנתונים.
קח בחשבון גם אופציה לא להשתמש בפורק בכלל אלא לעבוד עם Workers שזה נשמע לי טבעי יותר לסוג האפליקציה שלך.
-
עבודה עם TCP היא בדיוק אותו דבר למקומי ומרוחק.
רק שכותבים IP פנימי?
בד"כ כשבונים שתי מערכות נוד באותה מכונה יש צורות תקשורת שעוטפים את הTCP ומקילים את החיים, למשל כמו ZeroMQ.
אנסה ללמוד אותו.
פורק זה תהליכי משנה נראה לי. אבל פורק זה כפל של אותו קוד בדיוק. ופה אנחנו מדברים על מופע לצרכי הנתונים.
כפל של אותו של אותו קובץ
אבל אפשר לתת שם לכל פורק ואז להכניס התניה לפי השם.לעבוד עם Workers שזה נשמע לי טבעי יותר לסוג האפליקציה שלך.
חשבתי ע"ז
ככל שהבנתי נכון, הכוונה שמריצים חתיכות קוד מתוך האפלקציה בתהליך שונה, אכן?
א"כ, זה היה נראה לי מורכב יותר לניהול בכלל, ולשימוש בכל הליבות בכלל, אני צריך לדאוג לחלק את עבודת החישוב בדיוק חלקי מס' הליבות. לא?
והכי חשוב, אפשר לשתף רק באפר'ס (שאינני מבין מתי הוא שימושי) ולא אוביקטים. -
fork עשוי למקרה שאתה רוצה שכלל האפליקציה ירוץ במקביל על כמה מעבדים, כל אחד באופן די עצמאי.
במקרה שלך אני מתרדם שיש כמה חלקים באפליקציה לא מבוזרים (הDB והמאגרים על הזיכרון) ולכן מתאים יותר שדוקא פיסות הקוד שלוקחות זמן יישלחו לעיבוד מקבילי, והתוצאה חוזרת לך כאירוע.
אני לא מספיק מכיר נוד, אז קשה לי לענות. אולי תעבור לדוטנט
-
@dovid אמר בלהגדיר את levelUp db כserver נפרד שמקשיב לארוע, כיצד, והאם כדאי?:
fork עשוי למקרה שאתה רוצה שכלל האפליקציה ירוץ במקביל על כמה מעבדים, כל אחד באופן די עצמאי.
אפשר לתת שם לכל פורק ואז עם התניה (בדיקת שם התהליך) להכתיב פעולה שונה.
זה יותר נוח כי זה חוסך להריץ כמה קבצים בכל פעם (אן שאלמד bash אחת ולתמיד..).@dovid אמר בלהגדיר את levelUp db כserver נפרד שמקשיב לארוע, כיצד, והאם כדאי?:
במקרה שלך אני מתרדם שיש כמה חלקים באפליקציה לא מבוזרים (הDB והמאגרים על הזיכרון) ולכן מתאים יותר שדוקא פיסות הקוד שלוקחות זמן יישלחו לעיבוד מקבילי, והתוצאה חוזרת לך כאירוע.
אני חושב שבמקרה שלי, החישובים הוא הפעולה הראשית ויהיה מורכב ומלוכלך לחלק אתם לתהליכים משניים
מה גם שמבדיקות שעשיתי, אין לי cpubloking רציני, פונקציות שהחשבתי למורכבות לוקחות כ-1ms
אבל גליתי משהו מעניין
שאם הרצת ה-db "קר", הוא תוקע את ה-cpu
כלומר החיפושים הראשונים איטיים עד שהוא "מתחמם" (תופס יותר cpu נראה לי), ואז הוא עובד מהר
היו לא מעט מקרים שהרצתי סידרת חיפושים ב-db
והפונקציה שרצה אחרי (אחרי שמתקבלות כל התשובות, לא הקול-בק שמפעיל הdb עם התשובה) מתעכבת לעיתים 100ms, שזה רוב רובו של זמן הרצת האפליקציה!לפי זה דוד צודק שיעזור להוציא את ה-db להרצה נפרדת (את התקשורת אני מבצע באמצעות socket), זה אמור לחתוך את הזמן לרבע.
בבדיקה. אעדכן בל"נ.
