Зачем хранить все данные в памяти?

Для хранения данных сайта или бекэнда первым желанием большинства здравомыслящих людей будет SQL база данных. 

Но иногда в голову приходит мысль что модель данных не подходит для SQL: например, при построении поиска или социального графа нужен поиск по сложным связям между объектами. 

Хуже всего ситуация, когда работаете в команде, и коллега не умеет строить быстрые запросы. Сколько времени вы потратили на решение проблем N+1 и на построение дополнительных индексов, чтобы SELECT на главной странице отрабатывал за разумное время?

Другим популярным подходом является NoSQL. Несколько лет назад был большой хайп вокруг этой темы — для любого удобного случая разворачивали MongoDB и радовались ответам в виде json-документов (кстати, сколько костылей пришлось вставить из-за циклических ссылок в документах?).

Почему бы не попробовать хранить все данные в памяти приложения, периодически сохраняя в произвольное хранилище (файл, удаленная база данных)? 

Память стала дешёвой, а любые возможные данные большинства малых и средних проектов влезут в 1 Гб памяти. (Например, мой любимый домашний проект — финансовый трекер, который ведет ежедневную статистику и историю моих трат, балансов, и транзакций за полтора года потребляет всего 45 Мб памяти.)

Плюсы:

• Доступ к данным становится проще — не нужно заботиться о запросах, ленивой загрузке, особенностях ORM, работа происходит с обычными C# объектами;
• Нет проблем, связанных с доступом из разных потоков;
• Очень быстро — нету сетевых запросов, отсутствует трансляция кода в язык запросов, не нужна (де)сериализация объектов;
• Допустимо хранить данные в любом виде — хоть в XML на диске, хоть в SQL Server, хоть в Azure Table Storage.

Минусы:

• Теряется горизонтальное масштабирование, и как следствие нельзя сделать zero downtime deployment;
• Если приложение упадет — можно частично потерять данные. (Но ведь наше приложение-то никогда не падает, правда?)

Как это работает?

Алгоритм следующий:

• На старте устанавливается соединение с хранилищем данных, и происходит загрузка данных;
• Строится объектная модель, первичные индексы, и индексы отношений (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());
    }
    
    // Пример связи 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);

При этом вызове объект ParentModel добавляется и в локальный кэш, и в очередь на запись в базу. Поэтому эта операция занимает O(1), и с этим объектом можно сразу работать.

Например, чтобы найти этот объект в репозитории и убедиться что вернувшийся объект является тем же экземпляром:

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

Что при этом происходит? Set<ParentModel>() возвращает TableDictionary<ParentModel>, который содержит в себе ConcurrentDictionary<ParentModel, ParentModel> и предоставляет дополнительный функционал первичных и вторичных индексов. Это позволяет иметь методы для поиска по Id (или другим произвольным пользовательским индексам) без полного перебора всех объектов.

При добавлении объектов в ObjectRepository добавляется подписка на изменение их свойств, поэтому любое изменение свойств также приводит добавлению этого объекта в очередь на запись. 
Обновление свойств снаружи выглядит так же, как и работа с POCO-объектом:

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

Удалить объект можно следующими способами:

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

При этом также происходит добавление объекта в очередь на удаление.

Как работает сохранение?

ObjectRepository при изменении отслеживаемых объектов (как добавление или удаление, так и изменение свойств) вызывает событие ModelChanged, на которое подписан IStorage. Реализации IStorage при возникновении события ModelChanged складывают изменения в 3 очереди — на добавление, на обновление, и на удаление.

Также реализации IStorage при инициализации создают таймер, который каждые 5 секунд вызывает сохранение изменений. 

Кроме того существует API для принудительного вызова сохранения: ObjectRepository.Save().

Перед каждым сохранением сначала происходит удаление из очередей бессмысленных операций (например дубликаты событий — когда объект менялся дважды или быстрое добавление/удаление объектов), и только потом само сохранение. 

Во всех случаях сохраняется актуальный объект целиком, поэтому возможна ситуация, когда объекты сохраняются в другом порядке, чем менялись, в том числе могут сохраняться более новые версии объектов, чем на момент добавления в очередь.

Что есть ещё?

• Все библиотеки основаны на .NET Standard 2.0. Можно использовать в любом современном .NET проекте.
• API потокобезопасен. Внутренние коллекции реализованы на базе ConcurrentDictionary, обработчики событий имеют либо блокировки, либо не нуждаются в них. 
  Единственное о чем стоит помнить — при завершении приложения вызвать 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 discovery? master/slave?)
• Реплицировать между инстансами EventLog через любой из алгоритмов консенсуса, например RAFT.

Так же существует ещё одна проблема, которая меня беспокоит — это каскадное удаление, либо обнаружение случаев удаления объектов, на которые есть ссылки из других объектов. 

Исходный код

Если вы дочитали до сюда — то дальше остается читать только код, его можно
найти на GitHub.