תחומים - פורום חרדי מקצועי

@dovid

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@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 האם חישובים בריבוי ליבות ייאיץ את המהירות.

@מד
כלומר קו מפריד יותר עבה או משהו אחר?

לפני זה זה היה נפתח רק בחלוית צד בוורד
המראה הוא ככה

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

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

שאלתי היא: מה לדעתכם הבעיה? האם מדובר בבעיה עיצובית או תיכנונית? או שאני טועה ואין כאן שום בעיה?

תמיד הציק לי שב־WinForms וב-Wpf, גם כשהאפליקציה כולה משתמשת ב־Dark Theme, שורת הכותרת (Title Bar) נשארת לבנה. זה יוצר מראה לא אחיד ולא כל כך אסתטי.
לאחרונה מצאתי ספרייה נחמדה שפותרת את הבעיה בצורה פשוטה ויעילה: DarkNet.
הספרייה מאפשרת להפעיל מצב כהה מקורי של Windows עבור שורת הכותרת באפליקציות WinForms ו-WPF, וזמינה גם דרך NuGet.

@הנגבי כתב בהקלדה עיוורת בעברית בניחוח בוגר ומעניין - גרסת בטא:

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

אני מבין
אבל השאלה היא - למה זה נצרך?

@הנגבי כתב בהקלדה עיוורת בעברית בניחוח בוגר ומעניין - גרסת בטא:

דוחות התכוונתי למעקב אחרי ההתקדמות.

התוכנה שומרת היכן אתה אוחז

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

@הנגבי כתב בהקלדה עיוורת בעברית בניחוח בוגר ומעניין - גרסת בטא:

האותיות שבמקלדת מדי קטנות, ואני לוחץ לפי הציור בלי להבין ולהפנים איזו אות זאת

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

@הנגבי כתב בהקלדה עיוורת בעברית בניחוח בוגר ומעניין - גרסת בטא:

אם אפשר להוסיף דו"חות.

תודה על המשוב
מה המטרה בדוחות?

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

https://github.com/espresso3389/pdfrx
אני מציע שתשתמש עם זה
רק צריך למטב אותו בשביל עברית ואולי עוד כמה פיצרי על הדרך אבל פחות או יותר יש כאן משהו מוכן בפלאטר שעובד יפה

הוא שומר התקדמות לא מיקום
אולי באמת צריך שישמור גם מיקום