ObjectRepository - דפוס מאגר .NET בזיכרון עבור הפרויקטים הביתיים שלך

למה לאחסן את כל הנתונים בזיכרון?

כדי לאחסן נתוני אתר או backend, הרצון הראשון של רוב האנשים השפויים יהיה לבחור במסד נתונים של SQL. 

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

המצב הגרוע ביותר הוא כשאתה עובד בצוות ועמית לא יודע לבנות שאילתות מהירות. כמה זמן השקעת בפתרון בעיות N+1 ובניית אינדקסים נוספים כדי שה-SELECT בעמוד הראשי יסתיים בפרק זמן סביר?

גישה פופולרית נוספת היא NoSQL. לפני מספר שנים היה הרבה הייפ סביב הנושא הזה - לכל אירוע נוח הם פרסו MongoDB ושמחו מהתשובות בצורת מסמכי json (אגב, כמה קביים היית צריך להכניס בגלל הקישורים המעגליים במסמכים?).

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

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

יתרונות:

• הגישה לנתונים הופכת קלה יותר - אינך צריך לדאוג לגבי שאילתות, טעינה עצלנית, תכונות ORM, אתה עובד עם אובייקטי C# רגילים;
• אין בעיות הקשורות לגישה משרשורים שונים;
• מהיר מאוד - אין בקשות רשת, אין תרגום קוד לשפת שאילתה, אין צורך ב(דה)סריאליזציה של אובייקטים;
• מקובל לאחסן נתונים בכל צורה - בין אם זה ב-XML בדיסק, או ב-SQL Server, או ב-Azure Table Storage.

חסרונות:

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

איך זה עובד?

האלגוריתם הוא כדלקמן:

• בהתחלה נוצר חיבור עם אחסון הנתונים והנתונים נטענים;
• בנויים מודל אובייקט, אינדקסים ראשיים ואינדקסים יחסיים (1:1, 1:Many);
• נוצר מנוי לשינויים במאפייני האובייקט (INotifyPropertyChanged) ולהוספה או הסרה של אלמנטים לאוסף (INotifyCollectionChanged);
• כאשר המנוי מופעל, האובייקט שהשתנה מתווסף לתור לכתיבה לאחסון הנתונים;
• שינויים באחסון נשמרים מעת לעת (על טיימר) בשרשור רקע;
• כאשר אתה יוצא מהאפליקציה, השינויים נשמרים גם באחסון.

דוגמה לקוד

הוספת התלות הנדרשת

// Основная библиотека
Install-Package OutCode.EscapeTeams.ObjectRepository
    
// Хранилище данных, в котором будут сохраняться изменения
// Используйте то, которым будете пользоваться.
Install-Package OutCode.EscapeTeams.ObjectRepository.File
Install-Package OutCode.EscapeTeams.ObjectRepository.LiteDb
Install-Package OutCode.EscapeTeams.ObjectRepository.AzureTableStorage
    
// Опционально - если нужно хранить модель данных для Hangfire
// Install-Package OutCode.EscapeTeams.ObjectRepository.Hangfire

אנו מתארים את מודל הנתונים שיישמר באחסון

public class ParentEntity : BaseEntity
{
    public ParentEntity(Guid id) => Id = id;
}
    
public class ChildEntity : BaseEntity
{
    public ChildEntity(Guid id) => Id = id;
    public Guid ParentId { get; set; }
    public string Value { get; set; }
}

ואז מודל האובייקט:

public class ParentModel : ModelBase
{
    public ParentModel(ParentEntity entity)
    {
        Entity = entity;
    }
    
    public ParentModel()
    {
        Entity = new ParentEntity(Guid.NewGuid());
    }
    
    public Guid? NullableId => null;
    
    // Пример связи 1:Many
    public IEnumerable<ChildModel> Children => Multiple<ChildModel>(x => x.ParentId);
    
    protected override BaseEntity Entity { get; }
}
    
public class ChildModel : ModelBase
{
    private ChildEntity _childEntity;
    
    public ChildModel(ChildEntity entity)
    {
        _childEntity = entity;
    }
    
    public ChildModel() 
    {
        _childEntity = new ChildEntity(Guid.NewGuid());
    }
    
    public Guid ParentId
    {
        get => _childEntity.ParentId;
        set => UpdateProperty(() => _childEntity.ParentId, value);
    }
    
    public string Value
    {
        get => _childEntity.Value;
        set => UpdateProperty(() => _childEntity.Value, value
    }
    
    // Доступ с поиском по индексу
    public ParentModel Parent => Single<ParentModel>(ParentId);
    
    protected override BaseEntity Entity => _childEntity;
}

ולבסוף, מחלקת המאגר עצמו לגישה לנתונים:

public class MyObjectRepository : ObjectRepositoryBase
{
    public MyObjectRepository(IStorage storage) : base(storage, NullLogger.Instance)
    {
        IsReadOnly = true; // Для тестов, позволяет не сохранять изменения в базу
    
        AddType((ParentEntity x) => new ParentModel(x));
        AddType((ChildEntity x) => new ChildModel(x));
    
        // Если используется Hangfire и необходимо хранить модель данных для Hangfire в ObjectRepository
        // this.RegisterHangfireScheme(); 
    
        Initialize();
    }
}

צור מופע ObjectRepository:

var memory = new MemoryStream();
var db = new LiteDatabase(memory);
var dbStorage = new LiteDbStorage(db);
    
var repository = new MyObjectRepository(dbStorage);
await repository.WaitForInitialize();

אם הפרויקט ישתמש ב- HangFire

public void ConfigureServices(IServiceCollection services, ObjectRepository objectRepository)
{
    services.AddHangfire(s => s.UseHangfireStorage(objectRepository));
}

הכנסת אובייקט חדש:

var newParent = new ParentModel()
repository.Add(newParent);

בקריאה זו, האובייקט מודל הורה מתווסף הן למטמון המקומי והן לתור לכתיבה למסד הנתונים. לכן, פעולה זו לוקחת O(1), וניתן לעבוד איתו מיד עם אובייקט זה.

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

var parents = repository.Set<ParentModel>();
var myParent = parents.Find(newParent.Id);
Assert.IsTrue(ReferenceEquals(myParent, newParent));

מה קורה? מַעֲרֶכֶת () החזרות מילון טבלה, המכיל מילון במקביל ומספק פונקציונליות נוספת של אינדקסים ראשיים ומשניים. זה מאפשר לך לקבל שיטות לחיפוש לפי Id (או אינדקסים שרירותיים אחרים של משתמשים) מבלי לבצע איטרציה מלאה על כל האובייקטים.

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

myParent.Children.First().Property = "Updated value";

ניתן למחוק אובייקט בדרכים הבאות:

repository.Remove(myParent);
repository.RemoveRange(otherParents);
repository.Remove<ParentModel>(x => !x.Children.Any());

זה גם מוסיף את האובייקט לתור המחיקה.

איך עובד החיסכון?

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

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

בנוסף, יש ממשק API לכפות קריאת שמירה: ObjectRepository.Save().

לפני כל שמירה מוסרות תחילה פעולות חסרות משמעות מהתורים (למשל אירועים כפולים - כאשר אובייקט הוחלף פעמיים או אובייקטים הוסיפו/הוסרו במהירות), ורק לאחר מכן השמירה עצמה. 

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

מה עוד יש שם?

• כל הספריות מבוססות על .NET Standard 2.0. ניתן להשתמש בכל פרויקט NET מודרני.
• ה-API בטוח בשרשור. אוספים פנימיים מיושמים על בסיס במקביל מילון, למטפלי אירועים יש מנעולים או שאינם זקוקים להם. 
  הדבר היחיד ששווה לזכור הוא להתקשר ObjectRepository.Save();
• אינדקסים שרירותיים (דורשים ייחודיות):

repository.Set<ChildModel>().AddIndex(x => x.Value);
repository.Set<ChildModel>().Find(x => x.Value, "myValue");

מי משתמש בו?

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

אבל בעבר, כאשר הסטארט-אפ EscapeTeams שהוקם כעת (חשבתי שהנה זה, כסף - אבל לא, שוב ניסיון) - משמש לאחסון נתונים ב-Azure Table Storage.

תוכניות לעתיד

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

מנקודת מבט טכנית, אני רואה את התוכנית הבאה כאפשרית:

• אחסן EventLog ו-Snapshot במקום מודל אובייקט
• מצא מופעים אחרים (הוסף נקודות קצה של כל המופעים להגדרות? גילוי udp? מאסטר/עבד?)
• שכפול בין מופעי EventLog באמצעות כל אלגוריתם קונצנזוס, כגון RAFT.

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

קוד מקור

אם קראת עד לכאן, כל מה שנותר הוא לקרוא את הקוד; ניתן למצוא אותו ב-GitHub:
https://github.com/DiverOfDark/ObjectRepository

מקור: www.habr.com