אחסון וקריאה של מאות מליוני נתונים
-
שלום,
אני צריך לבנות DB שיכיל מאות מליוני נתונים (כבר בשלב ראשון), ולאפשר קריאה מהירה ומעבר לולאה על הערכים.
החלק המנחם הוא שהDB פשוט מאוד, טבלה אחת עם שלושה עמודות בסך הכל, זמן ושני ערכים מספריים, ללא קשרי גומלין או סינונים מורכבים, והשאילתה מקבלת נתח רוחבי משורה X עד שורה Y.
השאלה מתחלקת לשניים, א, באיזה DB כדאי להשתמש לאחסון, לכאורה NoSql בגלל כמות הנתונים, לא?
ב, בשלב שאיבת הנתונים (כרגע ב #C), אני לא רוצה לשאוב את כל הנתונים לפני הלולאה, כי אז זה יקח יותר מדי זמן וזכרון לא מיותר, מצד שני לשלוח בקשה על כל שורה בטבלה גם נשמע לא לענין, אז לשאוב כל פעם 100 שורות ולדרוס אותם, ואולי 10000 ?תודה מראש
פורסם במקור בפורום CODE613 ב17/11/2015 17:43 (+02:00)
-
השאלה מתחלקת לשניים, א, באיזה DB כדאי להשתמש לאחסון, לכאורה NoSql בגלל כמות הנתונים, לא?
אני אכן חושב שnoSql עדיף במידה ואין שאילתות כלל חוץ מהמפתח ראשי (מאתרים את הראשון וקוראים עד Y).
בשלב שאיבת הנתונים (כרגע ב #C), אני לא רוצה לשאוב את כל הנתונים לפני הלולאה, כי אז זה יקח יותר מדי זמן וזכרון לא מיותר, מצד שני לשלוח בקשה על כל שורה בטבלה גם נשמע לא לענין, אז לשאוב כל פעם 100 שורות ולדרוס אותם, ואולי 10000 ?
תודה מראשלא זה (שאיבה מראש) ולא זה (שאיבה חוזרת).
מתקדמים בשאיבת הנתונים יחד עם הלולאה.פורסם במקור בפורום CODE613 ב17/11/2015 17:59 (+02:00)
-
אשמח אם תוכל להרחיב קצת למה אתה מתכוון או אם יש לך איזה קישור לדוגמא
איך אביא דוגמה טרם בחרת מסד? אבל להרחיב אשמח:
כשאתה מתשאל מסד הוא עונה לך בstream - "זרם" בדיוק כמו הורדה של קובץ שיש לה התקדמות. כעת אם אתה "משהה" את ההורדה אז יש לך חיבור תפוס אבל רוחב פס פנוי.
אותו הדבר במסד, אם אתה מבקש מאה שורות ורוצה לעשות עיבוד על כל אחת, אז אתה מתחיל שאילתה ומבקש תשובות. מיד אחרי שמגיעה הראשונה אתה אומר "פוס". ומבצע את העיבוד. אחרי שאתה גומר אתה עושה "המשך" ומקבל את הבאה בתור.
השיטה הזאת ממומשת בDataReader שמתושאל בלולאה ע"י הפקודה Read שמשמעותה, קרא את השורה הבאה והמתן (הRead מחזיר כן/לא להודיע על סוף הנתונים, והשורה עצמה נכנסת לתוך משתנים של הDataReader).כל זה תאוריה ופילוסופיה, כי אם תשתמש בnoSql דרך C# תהיה לך מחלקה של C# שעוטפת את הטיפול במסד, ובמתודות שמבצעות שאילתה הם מחזירים IEnumerable שעוברים עליו בforeach, שזה בעצם עושה מאחורי הקלעים את אשר דיברתי (foreach לא מושך נתונים כי אם קורא כל פעם לMoveNext של הIEnumerator).
פורסם במקור בפורום CODE613 ב17/11/2015 18:39 (+02:00)
-
דוד, תודה רבה על התשובות
@דוד ל.ט.כל זה תאוריה ופילוסופיה, כי אם תשתמש בnoSql דרך C# תהיה לך מחלקה של C# שעוטפת את הטיפול במסד, ובמתודות שמבצעות שאילתה הם מחזירים IEnumerable שעוברים עליו בforeach, שזה בעצם עושה מאחורי הקלעים את אשר דיברתי (foreach לא מושך נתונים כי אם קורא כל פעם לMoveNext של הIEnumerator).
ראיתי שיש כמה וכמה סוגים, תוכל להמליץ לי על חברה מסויימת?
פורסם במקור בפורום CODE613 ב17/11/2015 19:01 (+02:00)
-
ת'אמת שמצאתי את עצמי מבולבל מהשפע העצום של הפתרונות..
אניח כאן את המידע הרלוונטי, אשמח לייעוץ והפניות.בסיס הרעיון הוא סימולטור שעובר על נתונים היסטוריים, מנתח, ומציג או מבצע פעולות בהתאם.
נניח שיש לי רשימה של 100 מליון שורות, כל שורה מורכבת מזמן ומספר, התוכנה מקבלת את הרשימה, עוברת עליה ומציגה גרפים, ניתוחים, בהתאם לדרישות הספציפיות של המשתמש.
אני צריך פילוח מהיר של הנתונים בקיבוץ לפי טווח זמן נבחר, דקה, 5 דקות, שעה וכדו'
יש שני חלקים בלולאה, החלק הראשון שעובר על כל שורה ושורה וחלק פנימי שמחשב בדיקות בהתאם לשורות אחרות בטבלה.השאלה הראשונה היא האם עדיף להוריד את הנתונים ולשמור אותם ב DB מקומי או לשלוף ישירות מהשרת?
בשביל החלק השני שמבצע חישובים ושאילתות ברור שעדיף לעשות את זה מול נתונים מקומיים גם בשביל מהירות הביצוע, ובפרט בשביל לא להעמיס על השרת בכמויות של שאילתות מהרבה משתמשים בו זמנית (או שאני טועה ?)
בשביל החלק הראשון שעובר על כל הערכים הבנתי ממה שכתבת שזה יכול להיות מהיר מספיק גם בשליפה ישירה מהשרת, גם בריבוי משתמשים?השאלה השניה, באיזה DB לבחור, האם מתאים לי כאן NOSQL כשבעצם רוב ככל השאילתות הם בעיקר פעולות רוחביות, כמו מציאת הערך המקסימלי בטווח X? מצד שני NOSQL הרבה יותר מהיר לקריאה וכתיבה וגם דחוס, מה שמאפשר הורדה מהירה.
מידע נוסף שיכול להיות רלוונטי:
הטבלה הראשית בשרת מתעדכנת באופן קבוע על בסיס יומי.
אין כתיבה / עדכון / מחיקה בתוך הטבלה המקומית (במידה ואני בוחר להוריד ולהשתמש ב DB מקומי), לצורך שמירת נתונים וביצועים אשתמש ב DB נפרד או מסמכים.
על בסיס המבנה הפשוט של הטבלה אין שאילתות מורכבות, רק ערך הגדול/קטן/ממוצע בטווח X עד Y וכדו'.מקווה שיצאתי ברור
תודה מראשפורסם במקור בפורום CODE613 ב18/11/2015 16:17 (+02:00)
-
אני לא רוצה להביע את דעתי האישית כאן, אבל מה שאני יכול להמליץ לך על DBA ברמה גבוהה מאוד, שמנהל דטה בייסים של חצי טרה ומעלה(!!!) אמנם עולה כסף, אבל שווה כל אגורה, אני אישית לקחתי ממנו ארבע שעות והחכמתי מאוד. שמו מרדכי דניאלוב, את המספר שלו אשלח לך באישי אם תרצה.
פורסם במקור בפורום CODE613 ב18/11/2015 23:35 (+02:00)
-
אחרי שחלקתי כבוד לגדולים ממני, אני מרשה לעצמי לפתוח את הפה.
אני צריך פילוח מהיר של הנתונים בקיבוץ לפי טווח זמן נבחר, דקה, 5 דקות, שעה וכדו'
כבר בשלב זה אני יכול לומר ש NoSql לא מתאים לך בעליל, שליפות ב NoSql הם מבוססים מפתח בלבד, ולא מבוססי ערך.
@אבייש שני חלקים בלולאה, החלק הראשון שעובר על כל שורה ושורה וחלק פנימי שמחשב בדיקות בהתאם לשורות אחרות בטבלה.
כנ"ל.
@אביהשאלה הראשונה היא האם עדיף להוריד את הנתונים ולשמור אותם ב DB מקומי או לשלוף ישירות מהשרת?
אתה צריך לתכנן את עצמך היטיב לפני שאתה עושה דברים כאלו, אתה מניח כאן שיש רק טבלה וקוד, זה לא נכון, תבנה את הדטה בייס בצורה שהוא יעשה את העבודה שהוא טוב בה, ואת הקוד שיעשה את מה שהוא טוב בו. אפשר למשל ליצור סכמה בזמן ריצה בתוך הדטה בייס (אם זה SQLSERVER כמובן) ולחסוך בביצועים בצורה מדהימה (את זה למדתי כמובן מדניאלוב) לפי מה שנראה אתה צריך לתכנן כאן ריקוד מתוזמן של הדטה בייס ביחד עם הקוד שלך ולא לשלוף רשומות כמו ערבי.
@אביבשביל החלק השני שמבצע חישובים ושאילתות ברור שעדיף לעשות את זה מול נתונים מקומיים גם בשביל מהירות הביצוע, ובפרט בשביל לא להעמיס על השרת בכמויות של שאילתות מהרבה משתמשים בו זמנית (או שאני טועה ?)
זה לא בדיוק ככה, יש חישובים שדטה בייס יודע לעשות יותר טוב (כלומר לא חישובים מתמטיים אלא חישובים הקשורים למידע הקיים בטבלאות) ושוב בשביל זה צריך לשבת על הפרוייקט שלך כמה שעות ולהבין אותו, וזה נקרא DBA.
בשביל החלק הראשון שעובר על כל הערכים הבנתי ממה שכתבת שזה יכול להיות מהיר מספיק גם בשליפה ישירה מהשרת, גם בריבוי משתמשים?
@אביהשאלה השניה, באיזה DB לבחור, האם מתאים לי כאן NOSQL כשבעצם רוב ככל השאילתות הם בעיקר פעולות רוחביות, כמו מציאת הערך המקסימלי בטווח X? מצד שני NOSQL הרבה יותר מהיר לקריאה וכתיבה וגם דחוס, מה שמאפשר הורדה מהירה.
חד משמעית לא מתאים NoSql, בשביל למצוא ערך מקסימלי, בארכיטקטורה של NoSql אתה צריך לאחזר את כל הרשומות ולמצוא מביניהם את המקסימום, ב SQL רגיל, יש דרכים לעשות זאת בחיפוש בינארי, כגון אם יש אינדקס וכדומה.
מידע נוסף שיכול להיות רלוונטי:
הטבלה הראשית בשרת מתעדכנת באופן קבוע על בסיס יומי.
אין כתיבה / עדכון / מחיקה בתוך הטבלה המקומית (במידה ואני בוחר להוריד ולהשתמש ב DB מקומי), לצורך שמירת נתונים וביצועים אשתמש ב DB נפרד או מסמכים.
על בסיס המבנה הפשוט של הטבלה אין שאילתות מורכבות, רק ערך הגדול/קטן/ממוצע בטווח X עד Y וכדו'.אתה לא כל כך ברור מי זאת הטבלה הראשית ומי זאת המקומית??
אני ממליץ לך ללמוד את הנושא הזה: https://he.wikipedia.org/wiki/ETLמקווה שיצאתי ברור
ברור לגמרי תהיה כשכל הפרוייקט שלך יהיה מול העיניים של מישהו, במצבך לפי הנראה הידע שלך במסדי נתונים לא כל כך רחב, ואסור לך לוותר על ליווי מקצועי של DBA.
בהצלחה!!!
פורסם במקור בפורום CODE613 ב18/11/2015 23:51 (+02:00)
-
אני לא רוצה להביע את דעתי האישית כאן, אבל מה שאני יכול להמליץ לך על DBA ברמה גבוהה מאוד, שמנהל דטה בייסים של חצי טרה ומעלה(!!!) אמנם עולה כסף, אבל שווה כל אגורה, אני אישית לקחתי ממנו ארבע שעות והחכמתי מאוד. שמו מרדכי דניאלוב, את המספר שלו אשלח לך באישי אם תרצה.
אשמח לקבל את המספר.
אגב, התחום שלו כולל גם שרתי אחסון ופיצולים למיניהם או שזה מקצוע אחר?
תודה על התשובה המפורטת, אקח ייעוץ מומחה ואעדכן בלנ"ד.פורסם במקור בפורום CODE613 ב19/11/2015 00:09 (+02:00)
-
אגב, התחום שלו כולל גם שרתי אחסון ופיצולים למיניהם או שזה מקצוע אחר?
יש מושג של מסד נתונים מבוזר בכמה צורות, בעיקרון יש פרטישן טייבל (כלומר אפשר לחלק טבלה אחת לכמה שרתים), ויש גם ארכיטקטורה של מחסן נתונים מבוזר לשליפות בלבד (כלומר לעשות אשכול של שרתים שכל אחד מהם מחזיק את הדטה בייס בנפרד ולפי הזמינות שלהם השאילתות מבוצעות, ואחת ליום או משהו כזה מעדכנים את השרתים בצורה שמורידים בכל פעם אחד ומעדכנים אותו כאשר כל השאר נשארים זמינים, כך שהשירות שלך אף פעם לא נפסק) במחסן נתונים אתה יכול להיות חופשי בלעשות אינדקסים מטורפים על מנת לייעל שליפות, כאשר מסד הנתונים הזה אינו ממוטב עבור עדכון והכנסת נתונים אלא עבור שליפות בלבד.
פורסם במקור בפורום CODE613 ב19/11/2015 00:46 (+02:00)
-
לדעתי לפתח משהו כזה מאפס זה להמציא את הגלגל
יש כלי BI מאוד מתקדמים שיודעים לטעון מאות מיליוני שורות ל RAM תוך דחיסה מצוינת של המידע ושליפת תוצאות בשברירי שניות
הבעיה איתם שהם לא לייב מול הדטהבייס אלא מתעדכנים לפי תזמון שצריך להגדיר וגם שהמיקוד שלהם הוא בממשקי משתמש (גרפים וכו') אבל יש כאלו עם API שמאפשר להשמיש אותם גם למטרות אחרות
לדוגמה כלי שאני מכיר היטב qlik senseפורסם במקור בפורום CODE613 ב19/11/2015 12:15 (+02:00)
