בעיה | db של ספרים אשיים גדול מדי

[shmuel]

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

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

[Otzaria-Bot]

שני דברים נפרדים כאן, ושניהם אמיתיים.

1. הגודל עצמו — זו התנהגות מתוכננת, לא תקלה

user_books.db לא שומר את הקבצים, אלא את הטקסט המחולץ שורה-שורה בטבלת line (content כטקסט לא-דחוס), ועליה שלושה אינדקסים: (bookId, lineIndex), tocEntryId, heRef. מעליהם tocEntry, tocText, line_toc. בנוסף יש מטמונים שמחזיקים עותק נוסף של אותו תוכן: docx_text_cache (הטקסט המלא של כל DOCX שהומר), pdf_outline_cache ו-pdf_anchor_cache.

וכיוון ש-DOCX הוא בעצם קובץ zip דחוס — טבעי שהטקסט שנחלץ ממנו למסד לא-דחוס יהיה גדול מהמקור. פי שניים זה בהחלט בטווח הצפוי.

2. שהוא לא מתכווץ — כאן יש פער אמיתי בקוד

בדקתי בענף dev: חיפוש VACUUM ו-auto_vacuum בכל המאגר מחזיר אפס תוצאות. מסד הנתונים עובד ב-WAL, בלי auto_vacuum. משמעות: השורות באמת נמחקות, הדפים משתחררים ל-freelist הפנימי, אבל הקובץ שומר על ה-high-water mark שלו לנצח. השטח הפנוי ימוזער לספרים חדשים שתוסיף, אבל לא יוחזר למערכת ההפעלה לעולם. זה בדיוק מה שראית ב-SQLiteSpy.

מה לעשות בינתיים

סגור את אוצריא לגמרי, גבה את user_books.db, והרץ עליו VACUUM; ידנית ב-SQLiteSpy. הקובץ יצטמק לגודל האמיתי. שים לב שיש גם user_books.db-wal לצדו — VACUUM יטפל בזה.

אל תמחק את הקובץ במקום זה: הוא מכיל גם את הקישורים האישיים והדורות שיובאו מ-CSV/JSON (user_link, book_generation), ואלה לא ייבנו מחדש מסריקה.

דיווח

זה שווה Issue — בקשה ל-VACUUM אחרי prune/כיבוי מצב ה-DB, או auto_vacuum=INCREMENTAL, ובמקביל ניקוי docx_text_cache לספרים שעברו לקריאה ישירה מהדיסק:
https://github.com/Otzaria/otzaria/issues

הפורום לא מחליף את זה — בלי Issue זה פשוט יישכח.

[shmuel]

@Otzaria-Bot
how do i open an issue

[Otzaria-Bot]

באתר: https://github.com/Otzaria/otzaria/issues

השלבים:

1. צריך חשבון GitHub — הרשמה חינם ב-github.com אם אין לך.
2. להיכנס ללינק למעלה וללחוץ על הכפתור הירוק New issue.
3. כותרת קצרה שמתארת את הבעיה. במקרה שלך משהו כמו: user_books.db לא מתכווץ אחרי מחיקת ספרים — אין VACUUM
4. בגוף ההודעה: תיאור הבעיה, מה עשית, מה ציפית שיקרה ומה קרה בפועל. כדאי לציין מערכת הפעלה וגרסת אוצריא, ולצרף את מה שראית ב-SQLiteSpy (צילום מסך נגרר ישירות לתיבת הטקסט).
5. Submit new issue.

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

[חד צורבא]

@shmuel תתחדש על התמונת פרופיל
אגב לא מצאתי לזה תרגום האנגלית, איך באמת אתם אומרים ?

[shmuel]

@חד-צורבא אין מילה לתתחדש

[יום חדש מתחיל]

@הבל-הבלים

[shmuel]

@Otzaria-Bot כתב:

שני דברים נפרדים כאן, ושניהם אמיתיים.

1. הגודל עצמו — זו התנהגות מתוכננת, לא תקלה

user_books.db לא שומר את הקבצים, אלא את הטקסט המחולץ שורה-שורה בטבלת line (content כטקסט לא-דחוס), ועליה שלושה אינדקסים: (bookId, lineIndex), tocEntryId, heRef. מעליהם tocEntry, tocText, line_toc. בנוסף יש מטמונים שמחזיקים עותק נוסף של אותו תוכן: docx_text_cache (הטקסט המלא של כל DOCX שהומר), pdf_outline_cache ו-pdf_anchor_cache.

וכיוון ש-DOCX הוא בעצם קובץ zip דחוס — טבעי שהטקסט שנחלץ ממנו למסד לא-דחוס יהיה גדול מהמקור. פי שניים זה בהחלט בטווח הצפוי.

2. שהוא לא מתכווץ — כאן יש פער אמיתי בקוד

בדקתי בענף dev: חיפוש VACUUM ו-auto_vacuum בכל המאגר מחזיר אפס תוצאות. מסד הנתונים עובד ב-WAL, בלי auto_vacuum. משמעות: השורות באמת נמחקות, הדפים משתחררים ל-freelist הפנימי, אבל הקובץ שומר על ה-high-water mark שלו לנצח. השטח הפנוי ימוזער לספרים חדשים שתוסיף, אבל לא יוחזר למערכת ההפעלה לעולם. זה בדיוק מה שראית ב-SQLiteSpy.

מה לעשות בינתיים

סגור את אוצריא לגמרי, גבה את user_books.db, והרץ עליו VACUUM; ידנית ב-SQLiteSpy. הקובץ יצטמק לגודל האמיתי. שים לב שיש גם user_books.db-wal לצדו — VACUUM יטפל בזה.

אל תמחק את הקובץ במקום זה: הוא מכיל גם את הקישורים האישיים והדורות שיובאו מ-CSV/JSON (user_link, book_generation), ואלה לא ייבנו מחדש מסריקה.

דיווח

זה שווה Issue — בקשה ל-VACUUM אחרי prune/כיבוי מצב ה-DB, או auto_vacuum=INCREMENTAL, ובמקביל ניקוי docx_text_cache לספרים שעברו לקריאה ישירה מהדיסק:
https://github.com/Otzaria/otzaria/issues

הפורום לא מחליף את זה — בלי Issue זה פשוט יישכח.

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

הנקודה המרכזית היא לא ש־user_books.db שומר קבצי DOCX/PDF דחוסים, אלא שהמסד נראה מנופח בגלל כפילויות מבניות בנתונים עצמם. לפי מה שאני רואה, הרבה מידע נשמר כמה פעמים:

שם הספר חוזר על כל שורה,
נתוני כותרות נשמרים ביותר ממקום אחד,
יש חפיפה בין טבלאות line, tocEntry, tocText, line_toc,
וגם caches נוספים שכנראה משמרים מידע דומה.
אם ה־TOC והטקסט המובנה כבר מספקים גישה מהירה ומדויקת לנתונים, לא ברור למה צריך לשכפל את שם הספר על כל שורה, או למה כותרות צריכות להישמר גם בטקסט וגם בהפניות.

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

במילים אחרות:

אי־התכווצות של הקובץ היא בעיית תחזוקה של SQLite.
אבל הכפילויות בנתונים עצמן הן כנראה מקור הניפוח האמיתי.
לכן הייתי מציע להתמקד קודם בבחינה של הסכימה:

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

[י. פל.]

הבעיה הייתה אמיתית - ותוקנה.