ઑબ્જેક્ટરેપોઝિટરી - તમારા હોમ પ્રોજેક્ટ્સ માટે .NET ઇન-મેમરી રિપોઝીટરી પેટર્ન

મેમરીમાં બધો ડેટા શા માટે સંગ્રહિત કરવો?

વેબસાઇટ અથવા બેકએન્ડ ડેટા સ્ટોર કરવા માટે, મોટાભાગના સમજદાર લોકોની પ્રથમ ઇચ્છા SQL ડેટાબેઝ પસંદ કરવાની હશે. 

પરંતુ કેટલીકવાર મનમાં વિચાર આવે છે કે ડેટા મોડેલ SQL માટે યોગ્ય નથી: ઉદાહરણ તરીકે, શોધ અથવા સામાજિક ગ્રાફ બનાવતી વખતે, તમારે ઑબ્જેક્ટ્સ વચ્ચેના જટિલ સંબંધો શોધવાની જરૂર છે. 

સૌથી ખરાબ પરિસ્થિતિ એ છે કે જ્યારે તમે ટીમમાં કામ કરો છો અને સાથીદારને ખબર નથી હોતી કે ઝડપી પ્રશ્નો કેવી રીતે બનાવવું. તમે N+1 સમસ્યાઓ ઉકેલવામાં અને વધારાના અનુક્રમણિકાઓ બનાવવામાં કેટલો સમય પસાર કર્યો હતો જેથી મુખ્ય પૃષ્ઠ પરનું SELECT યોગ્ય સમયમાં પૂર્ણ થાય?

અન્ય લોકપ્રિય અભિગમ NoSQL છે. કેટલાંક વર્ષો પહેલા આ વિષયની આસપાસ ઘણો હાઇપ હતો - કોઈપણ અનુકૂળ પ્રસંગ માટે તેઓએ મોંગોડીબીનો ઉપયોગ કર્યો હતો અને જેસન દસ્તાવેજોના રૂપમાં જવાબોથી ખુશ હતા. (બાય ધ વે, ડોક્યુમેન્ટ્સમાં ગોળાકાર લિંક્સને કારણે તમારે કેટલી ક્રૉચ દાખલ કરવી પડી?).

હું બીજી, વૈકલ્પિક પદ્ધતિ અજમાવવાનું સૂચન કરું છું - શા માટે એપ્લિકેશન મેમરીમાં તમામ ડેટાને સંગ્રહિત કરવાનો પ્રયાસ ન કરો, સમયાંતરે તેને રેન્ડમ સ્ટોરેજ (ફાઇલ, રિમોટ ડેટાબેઝ) પર સાચવો? 

મેમરી સસ્તી થઈ ગઈ છે, અને મોટાભાગના નાના અને મધ્યમ કદના પ્રોજેક્ટ્સ માટે કોઈપણ સંભવિત ડેટા 1 GB મેમરીમાં ફિટ થશે. (ઉદાહરણ તરીકે, મારો પ્રિય હોમ પ્રોજેક્ટ છે નાણાકીય ટ્રેકર, જે દોઢ વર્ષ સુધી મારા ખર્ચાઓ, બેલેન્સ અને વ્યવહારોના દૈનિક આંકડા અને ઇતિહાસ રાખે છે, તે માત્ર 45 MB મેમરી વાપરે છે.)

ગુણ:

• ડેટાની ઍક્સેસ સરળ બને છે - તમારે પ્રશ્નો, આળસુ લોડિંગ, ORM સુવિધાઓ વિશે ચિંતા કરવાની જરૂર નથી, તમે સામાન્ય C# ઑબ્જેક્ટ્સ સાથે કામ કરો છો;
• વિવિધ થ્રેડોની ઍક્સેસ સાથે સંકળાયેલી કોઈ સમસ્યા નથી;
• ખૂબ જ ઝડપી - કોઈ નેટવર્ક વિનંતીઓ નહીં, ક્વેરી ભાષામાં કોડનું કોઈ ભાષાંતર નહીં, ઑબ્જેક્ટના (de)ક્રમીકરણની જરૂર નથી;
• તે કોઈપણ સ્વરૂપમાં ડેટા સંગ્રહિત કરવા માટે સ્વીકાર્ય છે - તે ડિસ્ક પર XMLમાં હોય, અથવા SQL સર્વરમાં હોય, અથવા Azure ટેબલ સ્ટોરેજમાં હોય.

વિપક્ષ:

• આડું સ્કેલિંગ ખોવાઈ ગયું છે, અને પરિણામે, શૂન્ય ડાઉનટાઇમ જમાવટ કરી શકાતી નથી;
• જો એપ્લિકેશન ક્રેશ થાય છે, તો તમે આંશિક રીતે ડેટા ગુમાવી શકો છો. (પરંતુ અમારી એપ્લિકેશન ક્યારેય ક્રેશ થતી નથી, બરાબર?)

તે કેવી રીતે કામ કરે છે?

અલ્ગોરિધમ નીચે મુજબ છે:

• શરૂઆતમાં, ડેટા સ્ટોરેજ સાથે કનેક્શન સ્થાપિત થાય છે, અને ડેટા લોડ થાય છે;
• ઑબ્જેક્ટ મૉડલ, પ્રાથમિક અનુક્રમણિકાઓ અને રિલેશનલ ઇન્ડેક્સ (1:1, 1:ઘણા) બનેલ છે;
• ઑબ્જેક્ટ પ્રોપર્ટીઝ (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();

જો પ્રોજેક્ટ હેંગફાયરનો ઉપયોગ કરશે

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 (અથવા અન્ય મનસ્વી વપરાશકર્તા અનુક્રમણિકાઓ) દ્વારા શોધવા માટેની પદ્ધતિઓની મંજૂરી આપે છે.

જ્યારે વસ્તુઓ ઉમેરી રહ્યા હોય ObjectRepository તેમની પ્રોપર્ટીઝ બદલવા માટે સબસ્ક્રિપ્શન ઉમેરવામાં આવે છે, તેથી પ્રોપર્ટીમાં કોઈપણ ફેરફાર પણ આ ઑબ્જેક્ટને રાઈટ કતારમાં ઉમેરવામાં પરિણમે છે. 
બહારથી પ્રોપર્ટીઝ અપડેટ કરવી એ POCO ઑબ્જેક્ટ સાથે કામ કરવા જેવું જ લાગે છે:

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

તમે નીચેની રીતે ઑબ્જેક્ટ કાઢી શકો છો:

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

આ ઑબ્જેક્ટને કાઢી નાખવાની કતારમાં પણ ઉમેરે છે.

બચત કેવી રીતે કામ કરે છે?

ObjectRepository જ્યારે મોનિટર કરેલ ઑબ્જેક્ટ્સ બદલાય છે (ક્યાં તો ઉમેરવું અથવા કાઢી નાખવું, અથવા ગુણધર્મો બદલવું), ઘટના ઊભી કરે છે મોડલ બદલાયેલપર સબ્સ્ક્રાઇબ કર્યું ISstorage. અમલીકરણો ISstorage જ્યારે કોઈ ઘટના બને છે મોડલ બદલાયેલ ફેરફારોને 3 કતારોમાં મૂકવામાં આવે છે - ઉમેરવા માટે, અપડેટ કરવા માટે અને કાઢી નાખવા માટે.

અમલીકરણો પણ ISstorage આરંભ પર, તેઓ એક ટાઈમર બનાવે છે જેના કારણે દર 5 સેકન્ડે ફેરફારો સાચવવામાં આવે છે. 

વધુમાં, સેવ કૉલને દબાણ કરવા માટે એક API છે: ObjectRepository.Save().

દરેક સેવ પહેલાં, અર્થહીન ઑપરેશન્સ કતારમાંથી પ્રથમ દૂર કરવામાં આવે છે (ઉદાહરણ તરીકે, ડુપ્લિકેટ ઇવેન્ટ્સ - જ્યારે ઑબ્જેક્ટ બે વાર બદલવામાં આવ્યો હતો અથવા ઑબ્જેક્ટને ઝડપથી ઉમેરવા/દૂર કરવામાં આવ્યો હતો), અને માત્ર ત્યારે જ સાચવો. 

તમામ કેસોમાં, સમગ્ર વર્તમાન ઑબ્જેક્ટ સાચવવામાં આવે છે, તેથી શક્ય છે કે ઑબ્જેક્ટને કતારમાં ઉમેરવામાં આવ્યા હતા તેના કરતાં ઑબ્જેક્ટના નવા સંસ્કરણો સહિત, તેઓ બદલાયા હતા તેના કરતાં અલગ ક્રમમાં સાચવવામાં આવે છે.

બીજું શું છે?

• તમામ પુસ્તકાલયો .NET ધોરણ 2.0 પર આધારિત છે. કોઈપણ આધુનિક .NET પ્રોજેક્ટમાં ઉપયોગ કરી શકાય છે.
• API થ્રેડ સલામત છે. આંતરિક સંગ્રહો પર આધારિત અમલ કરવામાં આવે છે સમવર્તી શબ્દકોશ, ઇવેન્ટ હેન્ડલર પાસે કાં તો તાળાઓ હોય છે અથવા તેમની જરૂર હોતી નથી. 
  યાદ રાખવા જેવી વસ્તુ માત્ર કૉલ કરવાની છે ObjectRepository.Save();
• મનસ્વી અનુક્રમણિકાઓ (વિશિષ્ટતાની જરૂર છે):

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

તેનો ઉપયોગ કોણ કરે છે?

વ્યક્તિગત રીતે, મેં તમામ હોબી પ્રોજેક્ટ્સમાં આ અભિગમનો ઉપયોગ કરવાનું શરૂ કર્યું કારણ કે તે અનુકૂળ છે અને ડેટા એક્સેસ લેયર લખવા અથવા ભારે ઈન્ફ્રાસ્ટ્રક્ચર જમાવવા માટે મોટા ખર્ચની જરૂર નથી. વ્યક્તિગત રીતે, litedb અથવા ફાઇલમાં ડેટા સ્ટોર કરવો સામાન્ય રીતે મારા માટે પૂરતો છે. 

પરંતુ ભૂતકાળમાં, જ્યારે હવે નિષ્ક્રિય સ્ટાર્ટઅપ EscapeTeems (મેં વિચાર્યું કે તે અહીં છે, પૈસા - પણ ના, ફરીથી અનુભવ કરો) - Azure ટેબલ સ્ટોરેજમાં ડેટા સ્ટોર કરવા માટે વપરાય છે.

ભવિષ્યની યોજનાઓ

હું આ અભિગમના મુખ્ય ગેરફાયદામાંના એકને ઠીક કરવા માંગુ છું - આડી સ્કેલિંગ. આ કરવા માટે, તમારે કાં તો વિતરિત વ્યવહારોની જરૂર છે (sic!), અથવા મજબૂત-ઇચ્છાથી નિર્ણય લેવો જોઈએ કે જુદા જુદા દાખલાઓમાંથી સમાન ડેટા બદલવો જોઈએ નહીં, અથવા "છેલ્લું કોણ સાચું છે" ના સિદ્ધાંત અનુસાર તેને બદલવા દો.

તકનીકી દૃષ્ટિકોણથી, હું નીચેની યોજનાને શક્ય જોઉં છું:

• ઑબ્જેક્ટ મૉડલને બદલે ઇવેન્ટલૉગ અને સ્નેપશોટ સ્ટોર કરો
• અન્ય ઉદાહરણો શોધો (સેટિંગ્સમાં તમામ ઉદાહરણોના અંતિમ બિંદુઓ ઉમેરો? udp શોધ? માસ્ટર/સ્લેવ?)
• કોઈપણ સર્વસંમતિ અલ્ગોરિધમ, જેમ કે RAFT દ્વારા EventLog ઉદાહરણો વચ્ચે નકલ કરો.

ત્યાં બીજી સમસ્યા પણ છે જે મને ચિંતા કરે છે - કાસ્કેડ કાઢી નાખવું, અથવા અન્ય ઑબ્જેક્ટ્સમાંથી લિંક્સ ધરાવતા ઑબ્જેક્ટ્સને કાઢી નાખવાના કેસોની શોધ. 

સ્રોત

જો તમે અહીં સુધી આખી રીતે વાંચી લીધું હોય, તો જે બાકી છે તે કોડ વાંચવાનું છે; તે GitHub પર મળી શકે છે:
https://github.com/DiverOfDark/ObjectRepository

સોર્સ: www.habr.com