למה אי אפשר לעשות SQL בצורת HASH-TABLE

[Y.Excel.Access]

חשבתי על רעיון, ואשמח לדעת מה הבעיה בו (למה לא חשבו עליו קודם )

בSQL יש חסרון בולט לעומת NOSQL שכל JOIN צריך לחפש בטבלה נפרדת, ובביג דטה זה יוצר חיפושים מרובים. ואפילו אם הטבלאות מאונדקסות כהלכה מ"מ במליארדי שורות זה עלול להגיע להרבה חיפושים לכל טבלה (שורש ריבועי - ל256 עד 8 חיפושים, ל 1024 עד 10 חיפושים, וכידוע).

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

מצד שני ל NOSQL צריך לשכפל נתונים ולנפח את הדטא או להגביל את השליפה לצורה מתוכננת מראש, כך שלא יצטרכו לבצע JOIN.

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

ומה אם כן רוצים למחוק?

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

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

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

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

[dovid]

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

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

1. אתה מניח שחלק גדול ממהירות השליפה בNOSQL מושגת על ידי חיה ששמה HASH MAP
2. כמדומה שאתה מניח שבSQL מהירות השליפה איטית יותר גם ללא שום JOIN.
3. אתה מניח שהסיבה שבSQL לא משתמשים בHASH-MAP קשורה לעובדה שיש לאפשר מחיקות רבות לעיתים קרובות.
   כפועל יוצא אתה שואל, למה לא עשו הגדרה שמבכרת את האינדוקס על פני גמישות המחיקות.
4. אתה מציע פתרון למחיקות, על ידי טבלה ייעודית שתסמן את השורות המחוקות והמחיקה בפועל תתבצע על פני זמן חופשי.

תשובותיי:

1. לא יודע. אני יודע שHASH TABLE זה סוג של אינדקס מעולה שמאפשר גם הכנסות מהירות (ואילו אינדקס פשוט הוא מהיר יותר אלא שחסרונו הוא הכנסות איטיות), לא יודע אם ולמה SQL לא משתמשים בו.
2. לא שמעתי מעולם שSQL שולף יותר לאט מNOSQL.
   ואם אתה מדבר כשיש JOIN, אז אכן הצרה היא צרורה כי מדובר על המון המון שליפות בדיוק כמו שהיטבת לכתוב.
   איפה האינדקס הטוב יעזור למקרי הJOIN?
   עיקר "הצרה" של הJOIN היא כי רק בגלל שלפי הספר כל ישות מתפרסת על פני טבלאות רבות במסד, ואי אפשר לשלוף בזה אחר זה כי מפסידים את האפשרות לתשאל לפי הצירוף ועוד.
   אם המתכנת יבחר לשמור בSQL בטבלה אחת כמות עצומה של שורות ויתשאל אותה בלי כל צירוף לטבלה אחרת, SQL הוא כמעט מושלם!
3. אני לא יודע למה מחיקה נחשבת לבעיה. אם מדובר על פינוי האיזורים שהתרוקנו, אז זו בעיה ותיקה שיש בSQL, ויש פתרונות רבים לבעיה (כמו להשאיר אותם ריקים בטווח המיידי, ככה עושים כל המסדי נתונים).
4. מסד נתונים אכן מפעיל המון תהליכים ברקע שמנסים לפזר מאמץ עיבוד ואחסון על פני הזמן. זה כולל איחוי של חלקים פנויים אחרי מחיקות, ועוד הרבה דברים. אחרי כל זה נותרים ההבדלים בין בNOSQL לSQL.

[dovid]

@Y-Excel-Access אני חייב לציין גם שההבדלים בין שני המשפחות הללו אמורה להעסיק ארכיטקטים של מערכות גדולות במיוחד ולא מתכנת רגיל. במציאות מפתח טוב אמור להסתדר מעולה עם שניהם בלי תחושה חמוצה על מגבלות הטכנולוגיה.
לפעמים שאלה כמו שלך נובעת מהתקלות במגבלה, וא"כ כדאי לך לחלוק איתנו את המקרה כי המגבלות הללו לא אמורים לעצור שום חלום.

[Y.Excel.Access]

תודה רבה על המענה!

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

@dovid כתב בלמה אי אפשר לעשות SQL בצורת HASH-TABLE:

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

ב HASH TALBE יש מעלה (כמו שכתבת במקו"א) שאפשר להגיע ישירות למיקום בזיכרון בלי לחפש (משתמשים בזה בSTRING שסדרים את כל התחלות המילים בטבלה כך אפשר לחפש את המשך המילה בלי צורך לחפש את תחילת המילה, קודם לכן, כי מיקומה בזיכרון ידוע, וכאן זה אותו דבר רק בINTREGER LONG). ואם אפשר לציין במפתח הזר את המיקום בזיכרון - את האינדקס הבלתי משתנה, זה עשוי לצמצם את הJOIN לפעולה אחת בלבד - גם למקום הזיכרון XYZ.

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

@dovid כתב בלמה אי אפשר לעשות SQL בצורת HASH-TABLE:

לא שמעתי מעולם שSQL שולף יותר לאט מNOSQL.

ב BIG DATA כן, מעשר מליון שורות ומעלה. (לפי מה שהבנתי לענ"ד - שוב, בגלל הצורך ב JOIN).

@dovid כתב בלמה אי אפשר לעשות SQL בצורת HASH-TABLE:

אתה מניח שחלק גדול ממהירות השליפה בNOSQL מושגת על ידי חיה ששמה HASH MAP

דבר ראשון אבהיר, יש הרבה NOSQL, ואני מתכוון ל KEY/VALUE כמו MONGODB.
ולענין ההנחה - לא, אני לא חושב שהמהירות בMONGO DB מושגת על ידי HASH MAP אלא על ידי קינון הנתונים ושכפולם לפי הצורך כך שלא יצטרכו להשתמש ב JOIN.

[צדיק תמים]

@Y-Excel-Access כתב בלמה אי אפשר לעשות SQL בצורת HASH-TABLE:

דבר ראשון אבהיר, יש הרבה NOSQL, ואני מתכוון ל KEY/VALUE כמו MONGODB.

מונגו היא לא key/value, היא מבוססת מסמכים, אולי התכוונת לredis

[yossiz]

@Y-Excel-Access לא הצלחתי לעקוב אחרי הלוגיקה שבדבריך, אולי הדברים שלך מבוססים על הנחות סמויות והבנות קודמות שלא ברורים לי
לגבי השאלה מה היתרון של אינדקס מבוסס על btree לעומת hash map יש הרבה תוצאות בגוגל על הנושא, ממה שראיתי:

• HASHMAP יותר מהר בשליפה של רשומה אחת
• BTREE שימושי לשליפה של טווח של שורות
• BTREE שימושי למיונים משא"כ HASHMAP