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

[המלאך.]

יש פה כמה נקודות.
מדובר פה על מסד נתונים של החיפוש הרגיל לאוצריא.
1 האם לספרייה המקורית בc יש יתרון על פני הספרייה לדארט (זה מיועד לאוצריא),
2 האם תמיכה בחישובים בריבוי הליבות ייאיץ את המהירות.
3 האם במקרה ובו זה ישוכתב בראסט או c עם ffi לדארט יהיה שיפור במהירות בהקשר של ה איטיות של הצינור - דארט שאינה שפת לוע לבל.
4 האם טעינת הבלוק הבא למחזור הצ'יינג' יועיל?

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

[dovid]

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

[הבל הבלים]

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

[dovid]

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

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

[הבל הבלים]

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

[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 בעת החיפוש נעשה לאחר שמנוע החיפוש החזיר את התוצאות וכדי להציג גזירים עבור תוצאות החיפוש.