קובץ XML עם יוניק פיילד
-
שלום לכולם, אני רוצה ליצור קובץ XML כ"קדם" דטה בייס, כלומר לייבא מיליוני רשומות לXML ולאחר מכן לייבא את הקובץ לmysql הסיבה היא פשוטה, אינני רוצה לתקשר יותר מידי עם מסד הנתונים, ולהכביד עליו. אני מעדיף שהזלחן יעשה את העבודה שלו בנפרד, ומידי פעם לעדכן את הדטה בייס.
דא עקא, הואיל ויש לנו בעיה של כפילות ערכים באינדקס, אני רוצה למנוע גם את העבודה הזאת מהדטה בייס, ולכן כבר בXML לסנן את החומר, כך שלא יווצרו כפילויות, האם זה אפשרי (אני בטוח שזה אפשרי באמצעות קוד שיבדוק את זה וימחק את המיותר, השאלה אם זה אפשרי להגן על דבר כזה ברמת הקובץ עצמו??? כבר בכניסת הנתונים וכל זה למנוע עבודה מיותרת של השרת, הואיל ומדובר במיליוני אם לא מילארדי רשומות) ומה הדרך האידיאלית לעשות זאת מבחינת ביצועים (דומני שיהיו שיאמרו לעבוד עם nosql בתור "מקדים" לmysql הואיל והוא יותר קליל בתקשורת איתו, ותומך גם באינדקסים) אם מישהו יודע דבר או חצי דבר על הנושא אשמח לשמוע.
פורסם במקור בפורום CODE613 ב14/10/2014 12:51 (+03:00)
-
לדעתי תשמש עם זה.
מסד נתונים kay value קטן וטוב. למשל תוכנת ביטקוין עובדת עליו.
https://www.npmjs.org/package/levelתשתמש במפתח בתור שדה יחודי וב value תכניס json או איזה ערך שאתה רוצה. ה valve זה מערך של בתים.
פורסם במקור בפורום CODE613 ב14/10/2014 14:13 (+03:00)
-
לדעתי תשמש עם זה.
מסד נתונים kay value קטן וטוב. למשל תוכנת ביטקוין עובדת עליו.
https://www.npmjs.org/package/levelתשתמש במפתח בתור שדה יחודי וב value תכניס json או איזה ערך שאתה רוצה. ה valve זה מערך של בתים.
אין שום דוקומנטציה??? 2 פקודות זה מה שצריך לדעת? הכנסה ושליפה, אפילו מחיקה ועדכון לא ראיתי שם....
פורסם במקור בפורום CODE613 ב15/10/2014 14:25 (+03:00)
-
הכל על אותו מחלקה של leveldown שזה מימוש של leveldb.
https://github.com/google/leveldb
לכן כל המחלקות קוראות את זה. רק ש down זה יותר הבסיס. ו up זה תוספות על הבסיס.
תשתמש ב up.פורסם במקור בפורום CODE613 ב16/10/2014 22:27 (+03:00)
-
ארכיטקט, "בשביל לא להכביד על מערכת אחת דרושה מערכת אחרת" כך נשמעת השאלה.
מילא אם המערכת הא' הייתה מיועדת לפעולה אחרת בעיקר, אז מונעים ממנה עומס של פעולה שהיא לא ממוטבת לעשותה, אבל זו אותה פעולה בדיוק.הרציונל האמיתי של השאלה כנראה הוא למנוע עומס על המכונה (= מחשב) בה נמצאת מערכת א' משום שהיא איטית/יקרה/ברשת לעומת המכונה של מערכת ב' שמהירה/זולה/מקומית. כך שבעצם לא משנה בכלל המערכות אלא אפשר לעובד בשתיהם בMySql (להתקין גם במכונה בה המחשב "זוחל". אפשר להשתמש במגוון מסדי נתונים אחרים כמובן ואף במה שהציע magicode).
לגבי הרעיון של XML. סכמת XSD שהיא הנורמה כיום להגדרת נתונים בXML, תומכת בערך בלעדי, ובעוד אילוצים ואף קשרי גומלין. המשמעות של התמיכה הזו מסתכמת בכך שמי שיפר את האילוץ אז המסמך ייחשב ללא תקף. כי XML זה לא מערכת/מנוע/דרך פעולה, זה סה"כ מוסכמה איך לכתוב נתונים. אז זה לא ממש אמור לשנות לך. אתה יכול להחליט היום על מוסכמה כל שהיא, זה יפתור את הבעיה? המימוש של האילוץ של ערך יחידני תמיד נעשה ע"י המחשב, במקרה MySQL אז התוכנה שלהם דואגת לזה, ובXML אז התוכנה שלך היא זו שתעבוד קשה. שים לב שאין מצב שתעשה זאת ביעילות בה עושה זאת הMySql ואף לא תגיע לקרסולי קרסוליה של יעילות זו.
פורסם במקור בפורום CODE613 ב20/10/2014 13:40 (+03:00)
-
ראשית תודה רבה לדוד על התשובה המושקעת.
אסביר את עצמי: אינני מצפה לפרפטום מובילה שתפתור לי את בעיית האנרגיה, אולם אני מסתמך באופן מעט רופף (כלומר מעט רופף והחלק הנותר - לופת) על מבחני ביצועים של mysql מול mongoDB כאשר באופן ברור וחד משמעי mysql הוא חזק הרבה יותר בשליפות, ואילו mongodb חזק מאוד בעדכונים (וזאת עיקר הסיבה שהמציאו את עולם ה nosql) מה שאני מבין מכך ותומך בתזה שלך, שזה כמו סדין קצר, תמשוך לכאן יתקצר שם, כלומר: יעילות בשליפות, זה בגלל שהעדכון של החומר ואיחסונו בדיסק הקשיח נעשה בצורה מיטבית, מה שמביא אותנו לאיטיות בביצועים בעדכונים. ואילו יעילות בעדכונים, זה בגלל שהאיחסון בדיסק הקשיח נעשה בצורה לא מיטבית ולכן התוצאה היא איטיות בשליפות.
ברור שמנוע חיפוש צריך מקסימום אופטימיזציה בשליפות, ואין חולק על כך. מה שאני רוצה לחסוך זה "רק" את החלק הזה של ייחודיות ה Key, לזרוק את זה על המנוע הלא יעיל של nosql ופעם או פעמיים ביום לעשות תחזוקה של מסד הנתונים המרכזי ע"י הכנסה ועדכון "רק" של הרשומות הדורשות זאת, כלומר מה שכבר קיים בשני הצדדים, אין בו צורך ויימחק מהמאגר, ברור שבצורה כזו אני אמור לחסוך זמן עיבוד.
אז מה ההבדל בין זה לפרפטום מובילה, אתה יכול לקחת את נהג המשאית עם אופנוע לצפון, שם תמתין לו משאית שסוחבת מאה טון לכיוון ירושלים, אבל אם אתה מניח את המשאית מראש בירושלים כדי להוביל את הנהג לצפון ומשם לקחת את החומר, זה פשוט בזבוז.
לא עשיתי בדיקת מעבדה של ביצועים, אבל זה נראה באמת ככה (לדוגמא, בויקיפדיה העברית יש כ 37000 קטגוריות, ל level לקח 7 שניות לספור את כמות הרשומות שלו, ואילו ל mysql משהו כמו 2 ms, אבל בהכנסת החומר, באמת היה ל mysql יותר קשה לקח כמה דקות לעשות אינסרט ל 37 אלף רשומות....פורסם במקור בפורום CODE613 ב20/10/2014 19:43 (+03:00)
-
לכל מנוע של מסד נתונים יש יעוד. וגם לא מתאים לך למדוד את הביצועים של מסד נתונים לפי זה.
אני ראיתי שאתה מחפש אפשרות לאחסן באופן זמני מידע שמבוסס על שדה יחודי.
אז אמרתי תשתמש ב leveldb ששם אתה יכול לאחסן כמויות גדולות של חומר עם מפתח יחודי.
וזה בדיוק היעוד שלו. לכן הוא לא סופר את הכמות של המפתחות שנמצאים אצלו.
וזה מוביל אותי לשאלה איך הוא לא סופר הרי עם זה עובד לפי חיפוש בינארי הוא חייב לדעת כמה מפתחות יש לו. אחרת הוא הוא ידע מה האמצע? אני יותר נוקט שלא מימשו את הפונקציה count במחלקה וזה כמו שתעשה loop ב mysql שסופר את הכל.מכאן ברור איך mysql שולף ב 2 ms את הcount של הטבלה בזכות זה שהוא יודע שיש שדה יחודי יוצא שכמות השונים באינדקס זהה לגודל הטבלה. אפשר לראות את הגדלים של המספר השדות השונים באינדקס בסטיסטיקה של טבלה בmysql.
פורסם במקור בפורום CODE613 ב20/10/2014 23:29 (+03:00)
-
אגב יש לך מושג מה ההבדל בין המחלקה שציטטת לבין
לבין
והאם כולם עובדים על אותו מנוע??? ואם כבר התקנתי level והכנסתי נתונים.
ארכיטקט
מימשת את זה?
https://www.npmjs.org/package/levelupלמישהו פה יש לזה דוגמאות אמיתיות מהחיים?
תודה רבה!
פורסם במקור בפורום CODE613 ב28/08/2015 16:02 (+03:00)
