הגדרת Isar ב-Flutter: אינדקסים, שאילתות, ריאקטיביות

Isar Flutter: מדוע שאילתות לבסיס הנתונים המקומי מאטות עם גידול הנתונים

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

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

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

השלישי — מנויים ריאקטיביים לשאילתות רחבות מדי: כל שינוי באוסף בונה מחדש את כל הרשימה על המסך, למרות שרק רשומה אחת השתנתה.

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

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

מה נותנת סכימת אחסון וגישה לנתונים מכוילת

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

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

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

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

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

איך זה נראה במספרים

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

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

גישות לארגון אחסון מקומי: השוואת אפשרויות

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

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

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

כיצד אנו מגדירים Isar Flutter: שלבי עבודה הנדסית

הגדרת Isar ב-Flutter אינה "לחבר חבילה ולשכוח", אלא עבודה עם סכמת נתונים: מהאופן שבו מעוצבים האינדקסים והשאילתות תלוי אם החיפוש במסד המקומי יימשך שברירי שנייה על עשרות אלפי רשומות או ייתקע בסריקה מלאה של האוסף. להלן — כיצד אנו מבצעים עבודה זו שלב אחר שלב, מה�audit ועד למסירה.

1. Audit של הסכמה הנוכחית. אנו בוחנים את האוספים, את הקשרים ביניהם, את סוגי השדות ואת השאילתות שבאמת מבוצעות באפליקציה. לעתים קרובות מתברר שחלק מהמסננים פועלים על שדות ללא אינדקס, ושעצמים מקוננים נשמרים כך שהשליפה גוררת אחריה נתונים מיותרים.
2. עיצוב אינדקסים. עבור כל תרחיש חיפוש ומיון אנו מגדירים אינדקס מורכב עם סדר השדות הנכון: תחילה שדה השוויון, לאחר מכן הטווח, ולבסוף המיון. אנו מסירים אינדקסים כפולים — כל אחד מהם מאיץ קריאה אך מאט כתיבה ותופס מקום בקובץ המסד.
3. הגדרת שאילתות. אנו כותבים מחדש את השליפות בהתאם לאינדקסים: מחליפים סינון בזיכרון בתנאים בצד המסד, מוסיפים הוצאה מדורגת במקום טעינת האוסף כולו, ועבור מסכים ריאקטיביים מחברים האזנה לשאילתה במקום קריאה חוזרת ידנית של הנתונים לאחר כל שינוי.
4. בדיקה על נפחים אמיתיים. אנו מריצים את התרחישים על נתונים הקרובים לנתוני הייצור: עשרות אלפי רשומות, כתיבה במקביל, התחלה קרה. אנו מודדים את זמן השליפה והכתיבה, בוחנים היכן נוצרים נעילות, ומתקנים את הסכמה לפני שהמשתמשים יראו זאת.
5. מיגרציות ותאימות. אנו מתכננים כיצד הסכמה תשתנה בהמשך: גרסאות, העברת נתונים בעת עדכון האפליקציה, התנהגות בעת חזרה לגרסה קודמת. זה מגן מפני אובדן נתונים מקומיים אצל חלק מהמשתמשים לאחר השחרור.
6. תיעוד ומסירה. אנו מתעדים את הסכמה הסופית, את ייעודו של כל אינדקס ואת הכללים להוספת שאילתות חדשות. הצוות שלכם מקבל לא תיקון חד-פעמי, אלא נוהל ברור שלפיו המסד נשאר מהיר עם התפתחות המוצר.

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

אינדקסים, שאילתות ריאקטיביות ומיגרציות סכמה

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

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

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

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

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

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

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

מה הלקוח מקבל לידיו לאחר הגדרת האחסון

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

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

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

במה שונה Isar מפתרונות מקומיים אחרים ב-Flutter?

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

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

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

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

אבל היתרון אינו אוניברסלי: שליפות אנליטיות מורכבות עם קיבוץ ואיחודים עדיין נוחות ואמינות יותר לעשות ב-SQL — שם זה שטח טבעי, לא תוספת.

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

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

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

מקרה בוחן: האצנו שאילתות באפליקציה עם מסד נתונים גדל

מה היה לפני השינויים

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

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

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

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

מה שינינו

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

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

מדדים לפני ואחרי

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

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

ספקות טכניים נפוצים לגבי Isar

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

איזה נפח נתונים הוא מחזיק ללא דגרדציה?

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

כיצד בנויה הריאקטיביות והאם יהיו רינדורים מיותרים?

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

מה עם מיגרציות בעת שינוי סכמה?

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

תמיכה בפלטפורמות וגישה לקובץ מסד הנתונים

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

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

בואו נדון במשימה שלכם בנוגע לאחסון מקומי

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית עבודה. בתגובה תקבלו:

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

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

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