ObjectRepository - 홈 프로젝트를 위한 .NET 인메모리 저장소 패턴

왜 모든 데이터를 메모리에 저장합니까?

웹사이트나 백엔드 데이터를 저장하기 위해 대부분의 제정신인 사람들이 가장 먼저 원하는 것은 SQL 데이터베이스를 선택하는 것입니다. 

그러나 때로는 데이터 모델이 SQL에 적합하지 않다는 생각이 떠오릅니다. 예를 들어 검색 또는 소셜 그래프를 작성할 때 개체 간의 복잡한 관계를 검색해야 합니다. 

최악의 상황은 팀으로 작업하고 동료가 빠른 쿼리를 작성하는 방법을 모르는 경우입니다. 메인 페이지의 SELECT가 합리적인 시간 내에 완료되도록 N+1 문제를 해결하고 추가 인덱스를 구축하는 데 얼마나 많은 시간을 소비하셨나요?

또 다른 인기 있는 접근 방식은 NoSQL입니다. 몇 년 전에는 이 주제에 대해 많은 과장된 이야기가 있었습니다. 편리한 경우를 위해 MongoDB를 배포했고 json 문서 형식의 답변에 만족했습니다. (그런데 문서에 순환링크가 있어서 목발을 몇 개나 꽂아야 했나?).

다른 대체 방법을 시도해 볼 것을 제안합니다. 모든 데이터를 애플리케이션 메모리에 저장하고 주기적으로 임의 저장소(파일, 원격 데이터베이스)에 저장해 보는 것은 어떨까요? 

메모리는 저렴해졌으며 대부분의 중소 규모 프로젝트에 사용할 수 있는 모든 데이터는 1GB 메모리에 들어갑니다. (예를 들어, 제가 가장 좋아하는 홈 프로젝트는 금융 추적기45년 반 동안 나의 지출, 잔액, 거래에 대한 일일 통계와 내역을 보관하는 는 메모리를 XNUMXMB만 소모합니다.

장점 :

• 데이터에 대한 액세스가 더 쉬워집니다. 쿼리, 지연 로딩, ORM 기능에 대해 걱정할 필요가 없으며 일반 C# 개체로 작업할 수 있습니다.
• 다른 스레드에서의 액세스와 관련된 문제는 없습니다.
• 매우 빠릅니다 - 네트워크 요청이 없고, 코드를 쿼리 언어로 변환하지 않으며, 객체를 (역)직렬화할 필요도 없습니다.
• 디스크의 XML, SQL Server, Azure Table Storage 등 어떤 형식으로든 데이터를 저장할 수 있습니다.

단점 :

• 수평적 확장이 손실되고 결과적으로 가동 중지 시간이 없는 배포를 수행할 수 없습니다.
• 응용 프로그램이 충돌하면 부분적으로 데이터가 손실될 수 있습니다. (하지만 우리 애플리케이션은 결코 충돌하지 않습니다. 그렇죠?)

어떻게 작동합니까?

알고리즘은 다음과 같습니다.

• 처음에는 데이터 저장소와 연결이 설정되고 데이터가 로드됩니다.
• 개체 모델, 기본 인덱스 및 관계형 인덱스(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();

프로젝트가 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());

그러면 개체가 삭제 대기열에도 추가됩니다.

저장은 어떻게 이루어지나요?

개체 리포지토리 모니터링되는 객체가 변경되면(속성 추가, 삭제 또는 변경) 이벤트가 발생합니다. 모델이 변경되었습니다.구독하다 I저장. 구현 I저장 이벤트가 발생하면 모델이 변경되었습니다. 변경 사항은 추가, 업데이트, 삭제 등 3개의 대기열에 저장됩니다.

또한 구현 I저장 초기화 시 변경 사항이 5초마다 저장되도록 하는 타이머를 생성합니다. 

또한 저장 호출을 강제하는 API도 있습니다. 객체저장소.저장().

각 저장 전에 먼저 의미 없는 작업이 대기열에서 제거되고(예: 중복 이벤트 - 개체가 두 번 변경되거나 개체가 빠르게 추가/제거된 경우) 그런 다음 저장 자체만 수행됩니다. 

모든 경우에 전체 현재 개체가 저장되므로 개체가 대기열에 추가된 시점보다 최신 버전의 개체를 포함하여 변경된 순서와 다른 순서로 개체가 저장될 수 있습니다.

또 무엇이 있나요?

• 모든 라이브러리는 .NET Standard 2.0을 기반으로 합니다. 모든 최신 .NET 프로젝트에서 사용할 수 있습니다.
• API는 스레드로부터 안전합니다. 내부 컬렉션은 다음을 기반으로 구현됩니다. 동시사전, 이벤트 핸들러에는 잠금이 있거나 필요하지 않습니다. 
  기억할 가치가 있는 유일한 것은 전화하는 것입니다 ObjectRepository.Save();
• 임의 인덱스(고유성 필요):

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

누가 그것을 사용합니까?

개인적으로 저는 이 접근 방식을 모든 취미 프로젝트에서 사용하기 시작했습니다. 왜냐하면 편리하고 데이터 액세스 계층을 작성하거나 무거운 인프라를 배포하는 데 큰 비용이 들지 않기 때문입니다. 개인적으로는 일반적으로 litdb나 파일에 데이터를 저장하는 것으로 충분합니다. 

하지만 과거에는 지금은 없어진 스타트업인 EscapeTeams(여기에 돈이 있다고 생각했는데 아니, 다시 경험해 보세요) - Azure Table Storage에 데이터를 저장하는 데 사용됩니다.

앞으로의 계획

이 접근 방식의 주요 단점 중 하나인 수평 확장을 수정하고 싶습니다. 이렇게 하려면 분산 트랜잭션(sic!)이 필요하거나, 다른 인스턴스의 동일한 데이터가 변경되어서는 안 된다는 강력한 의지의 결정을 내리거나, "마지막 사람이 옳다"는 원칙에 따라 변경되도록 해야 합니다.

기술적 관점에서 볼 때 가능한 다음 구성표를 참조하십시오.

• 개체 모델 대신 EventLog 및 Snapshot 저장
• 다른 인스턴스 찾기(모든 인스턴스의 엔드포인트를 설정? udp 검색? 마스터/슬레이브?에 추가)
• RAFT와 같은 합의 알고리즘을 통해 EventLog 인스턴스 간 복제가 가능합니다.

제가 걱정하는 또 다른 문제도 있습니다. 계단식 삭제 또는 다른 객체와 링크가 있는 객체 삭제 사례 감지입니다. 

소스 코드

여기까지 읽었다면 이제 남은 것은 코드를 읽는 것뿐입니다. 코드는 GitHub에서 찾을 수 있습니다.
https://github.com/DiverOfDark/ObjectRepository

출처 : habr.com