בירור בירור מספר דברים בשיטת zstd

[dovid]

אז אם ככה השאלה נשארת האם בשביל דחיסה/פרישה, יש ייתרון בשימוש בספריה אחרת שהיא בשפה יותר low-level.
דעתי היא שההפרש לא שווה את העלות - מפתחים במה שהכי נח. לו יצוייר שיש משהו יעיל יותר, זה לא יהיה בר אבחנה, בטל בשישים באיטיות מסביב.

[yossiz]

@המלאך. כתב בבירור בירור מספר דברים בשיטת zstd:

אשמח להשערתכם

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

[dovid]

@yossiz כתב בבירור בירור מספר דברים בשיטת zstd:

אם יש ערך לעוד השערה...

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

[המלאך.]

@dovid @yossiz כשאמרתי חיפוש רגיל התכוונתי למבוסס אינדקס.
זהו מבחינתי חיפוש רגיל,

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

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

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

[dovid]

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

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

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

[pcinfogmach]

@dovid אתה צודק שבאנו לפה אחרי דיון ארוך ומכיון שההרגשה היתה שאין לנו מספיק הבנה בנושא החלטנו להעביר את הדיון לפה כדי לקבל חוות דעת מקצועית.

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

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

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

משקל המסד כיום: ~7 GB, כאשר כ-6 GB הם תוכן הספרים עצמם, והשאר (~1.5 GB) נתונים נלווים.
הועלתה הצעה להקטין את גודל המסד על ידי שימוש בדחיסה מילונית באמצעות ספריית zstd, כך שתוכן כל שורה (כלומר עמודת הטקסט של כל שורה בDB) יאוחסן בפורמט דחוס – מבלי לשנות את מבנה המסד הקיים ואת יתרונותיו.
בדיקה ראשונית הניבה תוצאות מרשימות: המסד ירד מ-6 GB לכ-1.5 GB (טבלת תוכן הספרים בלבד), ובסה"כ מ-7 GB לכ-2.8 GB.

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

מתוך שאלות אלו הועלה גם לדיון השאלות הבאות

@המלאך. כתב בבירור בירור מספר דברים בשיטת zstd:

1 האם לספרייה המקורית של zstd בc יש יתרון על פני הספרייה לדארט
2 האם חישובים בריבוי ליבות ייאיץ את המהירות.

[yossiz]

@pcinfogmach רק שיהיה ברור: אתם לא מדברים על האינדקס של Tantivy? כי זה כבר דחוס ואי אפשר לדחוס אותו יותר

בדיקה ראשונית הניבה תוצאות מרשימות

האם בדקתם דחיסת כל שורה בנפרד או דחיסת ספרים שלימים?

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

[pcinfogmach]

@yossiz כתב בבירור בירור מספר דברים בשיטת zstd:

האם בדקתם דחיסת כל שורה בנפרד או דחיסת ספרים שלימים?

דחיסת כל שורה בנפרד.

[pcinfogmach]

@yossiz כתב בבירור בירור מספר דברים בשיטת zstd:

ג. שאלה די כללית...

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

[yossiz]

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

[pcinfogmach]

@yossiz כתב בבירור בירור מספר דברים בשיטת zstd:

האם יש כל כך הרבה דרכים איך להשתמש ב-ZSTD?

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

[yossiz]

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

[dovid]

@yossiz כתב בבירור בירור מספר דברים בשיטת zstd:

אין לי מושג אם זה באמת יארוך 3 ימים...

זה היה מליצה, או מחשב פצצה וזה לוקח שניה, או 286 IBM ושלוש ימים (כנראה פחות)...

אני לא מבין איך אתה מסכים שהם יעשו חיפוש על שורות דחוסות!
@pcinfogmach היום החיפוש עובד עם LIKE של SQLLITE??

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

[yossiz]

@dovid האינדקס מאוחסן בנפרד. הדחיסה רק על הטקסט המלא של הספר
כתבו שהם משתמשים בTantivy

[pcinfogmach]

@dovid כתב בבירור בירור מספר דברים בשיטת zstd:

@pcinfogmach היום החיפוש עובד עם LIKE של SQLLITE??

כמו ש @yossiz ציין החיפוש נעשה על ידי מנוע חיפוש tantivy.
השימוש בDB בעת החיפוש נעשה לאחר שמנוע החיפוש החזיר את התוצאות וכדי להציג גזירים עבור תוצאות החיפוש.

[dovid]

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

[י.פל.]

@dovid כתב בבירור בירור מספר דברים בשיטת zstd:

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

והשליחה לאינדקס עצמו?
כרגע אינדוקס לוקח דקות בודדות.
לקורא ולפענח כמות כזו של חומר - זה גם נכלל ב"לחם חוקו"? כלומר - האם זה לא יאט את האינדוקס במידה ניכרת?
תודה על המענה המפורט!

[dovid]

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

[י.פל.]

@dovid כתב בבירור בירור מספר דברים בשיטת zstd:

אם ככה אז האינדקוס יכול בכלל להתבצע בבית המפיץ פעם אחת ולתמיד.

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

[dovid]

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