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

[yossiz]

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

[pcinfogmach]

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

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

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

[dovid]

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

[י.פל.]

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

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

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

[dovid]

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

[י.פל.]

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

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

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

[dovid]

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

[pcinfogmach]

@dovid @yossiz
הועלתה הצעה להשתמש עם דחיסה של zipvfs שזה בעצם דוחס את page blocks של המסד עצמו
האם זה עדיף על ההצעה הנוכחית של דחיסת הטקסט בלבד על ידי dictionary?

[yossiz]

@pcinfogmach
א. זה לא חינמי, זה עולה $4,000 אם הבנתי נכון
ב. אין לזה יתרון עבורך, הדחיסה תהיה פחות טובה

[yossiz]

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

[dovid]

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

[pcinfogmach]

@dovid @yossiz
מחילה לא הסברתי את עצמי מספיק
בתחילה הוצע לדחוס רק את עמודת הטקסט עם zstd
כעת השאלה היא האם יש דרך יעילה אולי לדחוס את שאר המטה דאטה
הנתונים שתכבתי בתחליה התבררו שהיו על DB ישן בDB הנוכחי שנתונים הנלווים לטקטס מהווים בערך מחצית מהמשקל של הDB
הנתונים הם עירבוביא חלקם טקסט וחלקם מספריים
גם ישנם הרבה עמודות שמאונדקסות לצורך lookup מהיר ויש הרבה שימוש בפעולות join על המטה דאטה

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

[dovid]

@pcinfogmach

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

[pcinfogmach]

@dovid

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

לגבי המטא־דאטה:
הרבה מהמטא־דאטה מורכב מקישורים.
סוגי הקישורים העיקריים הם:

1. קישורים ממפרשים לטקסט.
2. קישורי מראי מקומות לספר שממנו הם נלקחו (למשל: בראשית א, א).

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

בנוסף, קיימת מטא־דאטה גם בטבלת הטקסט עצמה, כגון מידע המסייע לעדכונים ולפעולות נוספות.

בקיצור, מדובר בפרויקט שלם ומורכב, ולכן אשמח אם תוכל לכוון אותי מעט יותר ולפרט אילו נתונים בדיוק חשוב לך לדעת.
מצורף פה קובץ מתוך הפרוייקט שלי שהוא פרוייקט מקביל שכולל את רוב הSQL שהתוכנה משתמשת בו אולי זה יהיה שימושי
queries.sql.ts
מצורף גם הסכמה של הDB
seforimdb-v2-schema.json

לגבי המושגים עליהם דיברת ב-2 איך אומרים באנגלית? "Way over my head"... לצערי אינני מכיר כלל את המושגים שעליהם דיברת. אם זה חשוב שאלמד עליהם אנא ציין זאת ואקיים בעצמי "צא ולמד"

[dovid]

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