levelUP db שאלת בסיסיות

[softs]

@דוד ל.ט.

אינדקסים? פשוט מאוד טבלה נוספת שהkey הוא הערך לאינדוקס והvalue זה מערך של keys לטבלה המאונדקסת.

הוא לא תומך בטבלאות

פורסם במקור בפורום CODE613 ב30/08/2015 17:32 (+03:00)

[אהרן]

הא?

פורסם במקור בפורום CODE613 ב30/08/2015 17:37 (+03:00)

[dovid]

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

פורסם במקור בפורום CODE613 ב30/08/2015 17:46 (+03:00)

[אהרן]

לא הבנתי אפי' רבע מילה.
לצערי.

פורסם במקור בפורום CODE613 ב30/08/2015 18:31 (+03:00)

[רחמים]

יש כמה סוגי אינדקסים שכל אחד משפר את הביצועים בסוג נתונים שונה ובשאילתות שונות
אתה צריך למקד יותר, באיזה טיפוס נתונים מדובר, ואיזה סוג שליפה אתה עושה
לדוגמא האם מדובר במחרוזות או מספרים, האם השליפה היא באופרטור '=' וכדומה, או אופרטור BETWEEN
ולפי הנתונים האלו בונים אינדקס

פורסם במקור בפורום CODE613 ב30/08/2015 19:26 (+03:00)

[אהרן]

@רחמים

יש כמה סוגי אינדקסים שכל אחד משפר את הביצועים בסוג נתונים שונה ובשאילתות שונות
אתה צריך למקד יותר, באיזה טיפוס נתונים מדובר, ואיזה סוג שליפה אתה עושה
לדוגמא האם מדובר במחרוזות או מספרים, האם השליפה היא באופרטור '=' וכדומה, או אופרטור BETWEEN
ולפי הנתונים האלו בונים אינדקס

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

תודה רבה!!

פורסם במקור בפורום CODE613 ב30/08/2015 20:52 (+03:00)

[רחמים]

תסיר מהמילה המנוקדת את כל הניקוד ותקבל את ה'מפתח' ואז תיגש לפי המפתח לכל אפשרויות הניקוד

פורסם במקור בפורום CODE613 ב30/08/2015 20:57 (+03:00)

[אהרן]

@רחמים

תסיר מהמילה המנוקדת את כל הניקוד ותקבל את ה'מפתח' ואז תיגש לפי המפתח לכל אפשרויות הניקוד

יש חסרות ויתרות.

פורסם במקור בפורום CODE613 ב30/08/2015 20:58 (+03:00)

[רחמים]

תן דוגמא

פורסם במקור בפורום CODE613 ב30/08/2015 21:02 (+03:00)

[אהרן]

חודש = חֹדֶשׁ

פורסם במקור בפורום CODE613 ב30/08/2015 21:04 (+03:00)

[dovid]

תוסיף כל פעם גם את המילה המנוקדת כמפתח כשהערך הוא המילה הבלתי מנוקדת.
זה מה שהתכוונתי. אני חשבתי על מפתח מספרי, אבל במקרה שלך זה הכי טוב...
תראה מה התכוונתי:
מפתח ערך
מפתח - ערך
1 - א,ב,ג
2 - ב
3 - ג
4 - ד
5 - ה
א - 1
ב - 1,2
ג - 1,3
ד - 4
ה - 5

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

פורסם במקור בפורום CODE613 ב30/08/2015 21:19 (+03:00)

[ארכיטקט]

@אהרן

שעות שאני מחפש
האם אפשר לקבל את ה-key שיש בו value מסוים?

תודה!!

זה מחזיר אותי לפוסט הזה
ואני יכול לספר לך שהיום היתה לי שעה של קורת רוח, עם DBA ענק מהבודדים בארץ ברמת המקצועיות שלו, הוא עושה היום את הדטה בייס של טרם ועוד כמה חברות ענק. האיש הזה DBA משנת 1992!!!! כלומר כמעט מתחילת דרכו של מסד הנתונים הרלציוני, ועובד בזה כל היום כבר למעלה מ 20 שנה.

דיברתי איתו איך לא, על ביג דאטה. הוא אמר שלדעתו כל הנהירה אחרי ביג דאטה זה לא בגלל שאין אפשרות לממש את זה ב SQL אלא בגלל שאין מספיק אנשים שיודעים מספיק על SQL ומרימים ידיים כשהוא מתחיל לעבוד לאט. והסיבה האמיתית שהוא עובד לאט, זה בגלל שכדי לתכנן דטה בייס טוב, זה לא רק עניין של אינדקסים, אלא יש המון קומבינציות נוספות. לפי טענתו אין גבול לכמות המידע שמסד נתונים רגיל יכול לאחסן ולהחזיר מידע, גם אם זה זטה בייט של מידע. העניין הוא שרוב ה DBA בארץ נעצרים בשלב האינדקסים, אבל יש עוד הרבה עומק מעבר לכך, ויש בודדים שיודעים באמת איך דטה בייס עובד מהקישקע של הקישקע ומה אפשר לעשות בו עוד (למשל הוא אומר שאחת השיטות היא ליצור סכמה חדשה בזמן ריצה על מנת למטב חלק מהשאילתות, ויש גם מחלקת DLL שלמה של דוט נט, שעושה פרסינג ל SQL אף אחד כמעט לא יודע על המחלקה הזו, ויש לה מעט מאוד משתמשים, כי זה עשוי לרמה גבוהה מאוד שרק צוות הפיתוח של SQL SERVER יודעים עליו)
דיברתי איתו על התוכנית שלי הזו, הוא אמר שדטה בייס הוא לא האתגר, אלא דברים אחרים.
אז אני שמח שמצאתי לי חבר בעניין הזה. אין כמו SQL מסורתי ורלציוני!!!

פורסם במקור בפורום CODE613 ב31/08/2015 22:22 (+03:00)

[אהרן]

@ארכיטקט

@אהרן

לפני מספר ימים ראיתי סרט

פעם הבאה תזכור שיש חברים

פורסם במקור בפורום CODE613 ב31/08/2015 22:25 (+03:00)

[רחמים]

יש פה אלגוריתם

פורסם במקור בפורום CODE613 ב31/08/2015 22:16 (+03:00)

[ארכיטקט]

@אהרן

אשמח להסבר מהו הנקודה של חיפוש בינארי

חיפוש בינארי נקרא גם "אריה במדבר"

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

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

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

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

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

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

פורסם במקור בפורום CODE613 ב31/08/2015 22:11 (+03:00)

[dovid]

אני לא מכיר בכלל nosql ובפרט לא את leveldb או levelup וleveldown. בקיצור אני levelless... כל מה שאמרתי זה מהשערות.

בקשר לחיפוש בינארי: המילה בינארי זה זוגי. חיפוש בינארי עובד ע"י שמחפשים ערך באוסף של פריטים ממויינים (תמיד אפשר למיין, רק שיש לזה עלות חד פעמית גדולה, ועלות מסויימת קטנה בהוספת פריט בודד. במסד key value אז אינני יודע איך ממומש האחסון).
למה קוראים לזה חיפוש זוגי? כי מחלקים את האוסף לשתיים כלומר הולכים ובודקים את איבר האמצע (לא חייב להיות מדוייק), ובודקים אם זהו הערך, ואם לאו האם גדול או קטן. לפי התשובה נפסל החצי הלא מתאים (הקטן מהערך שמחפשים או להיפך), ושוב בודקים בחצי שנשאר באותה הדרך: בודקים את האיבר האמצעי וכו'. זה דרך חיפוש מהירה בהרבה מסריקת איבר איבר, ויחס היעילות מטפס ככל שיש יותר איברים. בעוד חיפוש גס מחייב פעולות בדיקה * מס' האיברים במקרה הגרוע, אז בחיפוש בינארי הנוסחה היא log מס' האיברים.
(log זו פונקציה שמחזירה את מס' הפעמים שצריך להעלות בחזקה את הבסיס (אצלנו זה שתיים כי כל פעם מחלקים ל2 עד שבמקרה הגרוע נשארים עם האחד האמיתי) כדי להגיע לסכום. אז log של מאה, יוצא 6.6. כלומר 2 בחזקת 6 ומשהו זה 100: 2 4 8 16 32 64 השביעי זה כבר 128. במקרה הגרוע ביותר של החיפוש תהיינה 7 פעולות בדיקה (שווה גדול או קטן)).

פורסם במקור בפורום CODE613 ב31/08/2015 11:06 (+03:00)

[אהרן]

טוב הבנתי :mrgreen:

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

ב-db לא מצאתי קבצי c, הכתיבה הבינארית נעשית על ידי JS ?
איך שהבנתי, בשביל להשתמש בווינדוס צריך אפשרות לקרוא קבצי C, מדוע ?

פורסם במקור בפורום CODE613 ב31/08/2015 01:16 (+03:00)

[אהרן]

@דוד ל.ט.

תוסיף כל פעם גם את המילה המנוקדת כמפתח כשהערך הוא המילה הבלתי מנוקדת.
תראה מה התכוונתי:
מפתח ערך
מפתח - ערך
1 - א,ב,ג
2 - ב
3 - ג
4 - ד
5 - ה
א - 1
ב - 1,2
ג - 1,3
ד - 4
ה - 5

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

הכוונה לזה?

{
  key: word1
  value: [nikud11, nikud12, nikud13]
}
{
  key: nikud11
  wordClear: word
  value: [nikud12, nikud13]
}
{
  key: nikud12
  wordClear: word
  value: [nikud11, nikud13]
}
{
  key: nikud13
  wordClear: word
  value: [nikud11, nikud12]
}

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

אבל בעיקר, הדוגמא שלך נראית לי מורכבת יותר, ואשמח מאוד להבין אותה!

פורסם במקור בפורום CODE613 ב30/08/2015 23:08 (+03:00)

[אהרן]

@דוד ל.ט.

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

יחי ההבדל 'הקטן'.
א"כ זה DB ממש מוגבל.

פורסם במקור בפורום CODE613 ב30/08/2015 10:38 (+03:00)

[dovid]

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

פורסם במקור בפורום CODE613 ב30/08/2015 10:26 (+03:00)