ORM Entity Framework Core с каждой версией становится все более и более богатой на фичи. Команда разработчиков тратит много времени на перфоманс и вероятно простое обновление Nuget-пакета уже приведет к некоторому бусту, который почувствуют пользователи. Но сегодня я хочу рассказать о совершенно конкретной фиче: это новый режим запросов - “разделённые запросы” или “split queries” в оригинале.

Предыстория

На моем текущем проекте в качестве хранилища используется Postgres, доступ к которой осуществляется через драйвер Npgsql и EF Core. Одной из центральных сущностей всего бизнес-процесса является “методика выполнения ПЦР-исследования”, которая по сути представляет рецепт как выполнить исследование и включает в себя довольно много информации:

• список используемых реагентов с указанием “рецепта смешивания”
• список результатов, которые будут определены
• список оборудования на котором возможно выполнение исследования
• и так далее, всего 8 вложенных коллекций

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

В самом начале мы не парили себе голову и стали использовать lazy-loading, что хорошо работало в сценариях “частичного применения”: когда извлекалась методика только со списком реагентов, или методика только со списком результатов. Но в определенных сценариях требовалось получить методику “целиком”, что привело к классической проблеме N+1, когда для извлечения сущности и связанных коллекций требуется 1 запрос на извлечение сущности и еще по одному для каждого элемента коллекции. Такое отношение к данным сильно просаживало производительность и следующим витком было включить коллекции в родительский объект с использованием LINQ-конструкций .Include().ThenInclude().

Всё работало более менее хорошо до появления царь-методики. Это комплексный и сложный тест, в который включено много реагентов, много результатов, он использует много каналов детекции. К ней производится много форм комплектации наборов реагентов. Так или иначе, мы получили развесистую структуру, в которой каждая вложенная коллекция имела не как обычно 3-5 записей, а по 20-30. Вот тут наш софт и сказал “кря”. Если раньше на извлечение полной сущности уходило от нескольких десятков миллисекунд до сотен, то у царь-методики это занимало до полутора десятков секунд, что иногда приводило к краху запроса в БД. Это было уже недопустимо и требовало каких-то решений.

Пересказ документации

Как пишут Майкрософт в своей статье про разделённые запросы обычно каждый LINQ-запрос преобразуется в один SQL запрос с использованием JOIN для извлечения связанных коллекций. Я позволю себе немного перевернуть пример из документации и извлекать не блоги и посты, а посты и комменты. Пусть модель данных выглядит следующим образом:

public class Post 
{
    public int ID { get; set; }
    public string Content { get; set; }
    public List<Comment> Comments { get; set; }
}
public class Comment 
{
    public int ID { get; set; }
    public Post ParentPost { get; set; }
    public int ParentPostID { get; set; }
    public string CommentText { get; set; }
}

И попытаемся извлечь хайповый пост с 1000 комментариями из бд следующим запросом:

var veryPopularPost = Posts
    .Include(x => x.Comments)
    .First(x => x.ID == 42);

Что будет транслировано примерно в такой SQL-запрос усреднённый, потому что вариаций масса:

SELECT p.id, p.content, c.id, c.parentpostid, c.commenttext 
FROM posts AS p 
LEFT JOIN comments AS c ON (p.id = c.parentpostid)
WHERE p.id = 42
LIMIT 1;

А что если статья большая? Например автор был в ударе и выдал 100 КБ текста (это около 50 печатных листов). Комментаторы читали, наслаждались и комментировали, так что оставили 1000 комментариев. Сколько примерно будет весить результирующий набор, который надо вычитать ORM? На вскидку - p.content = 100 КБ, повторим 1000 раз и на выходе ~ 100 МБ текста, дублирующегося 1000 раз. И это без учета размера int и текста комментариев.

Lazy-load в этом случае будет побыстрее, хотя бомбить базу 1000 и одним запросом - тоже сомнительное развлечение. Можно ли что-то с этим сделать не прибегая вручную к оптимизации запросов?

AsSplitQuery()

Да, и вот каким образом. В EF Core 5.0 появилась новая директива .AsSplitQuery(), которая заставит query provider транслировать загрузку связанной коллекции отдельным запросом.

var veryPopularPost = Posts
    .Include(x => x.Comments)
    .AsSplitQuery()
    .First(x => x.ID == 42);

Транслируется в следующие SQL-запросы:

SELECT p.id, p.content 
FROM posts AS p
WHERE p.id = 42
LIMIT 1;

SELECT c.id, c.parentpostid, c.commenttext, p.id
FROM posts AS p
INNER JOIN comments AS c ON (p.id = c.parentpostid)
WHERE p.id = 42
LIMIT 1;

Что уже приведет к тому, что текст записи не будет читаться 1000 раз, а только 1.

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

Бенчмарки

На скорую руку я сваял бенчмарк. Пусть есть коллекция записей типа MainEntity, в которой нет ничего, кроме вложенных коллекций. 5 “маленьких” записей и 1 большая.

public class MainEntity
{
    public int ID { get; set; }
    public List<RefEntity1> Ref1 { get; set; }
    public List<RefEntity2> Ref2 { get; set; }
    public List<RefEntity3> Ref3 { get; set; }
    public List<RefEntity4> Ref4 { get; set; }
    public List<RefEntity5> Ref5 { get; set; }
    public List<BigRefEntity> BigRef { get; set; }
}

public abstract class RefEntity
{
    public int ID { get; set; }
    public string Payload { get; set; } = string.Empty;
    
    public MainEntity MainEntity { get; set; }
    public int? MainEntityID { get; set; }
}

public class RefEntity1 : RefEntity { }
public class RefEntity2 : RefEntity { }
public class RefEntity3 : RefEntity { }
public class RefEntity4 : RefEntity { }
public class RefEntity5 : RefEntity { }
public class BigRefEntity : RefEntity { }

Записи заполняются при инициализации БД строчками случайной длины по 10 символов для “маленькой” записи и по 1000 для “большой”. В каждую вложенную коллекцию добавляется по ItemsInCollection записей. Тестовый метод извлекает по 2 записи MainEntity, присоединяя к ней от 0 до 6 коллекций (параметр LoadRefs) в двух режимах - одним запросом и разделёнными запросами (параметр SplitQueries).

[Benchmark]
public List<MainEntity> QueryLoad()
{
    IQueryable<MainEntity> query = LoadRefs switch
    {
        0 => dbContext.MainEntities,
        1 => dbContext.MainEntities
            .Include(x => x.Ref1),
        2 => dbContext.MainEntities
            .Include(x => x.Ref1)
            .Include(x => x.Ref2),
        3 => dbContext.MainEntities
            .Include(x => x.Ref1)
            .Include(x => x.Ref2)
            .Include(x => x.Ref3),
        4 => dbContext.MainEntities
            .Include(x => x.Ref1)
            .Include(x => x.Ref2)
            .Include(x => x.Ref3)
            .Include(x => x.Ref4),
        5 => dbContext.MainEntities
            .Include(x => x.Ref1)
            .Include(x => x.Ref2)
            .Include(x => x.Ref3)
            .Include(x => x.Ref4)
            .Include(x => x.Ref5),
        6 => dbContext.MainEntities
            .Include(x => x.Ref1)
            .Include(x => x.Ref2)
            .Include(x => x.Ref3)
            .Include(x => x.Ref4)
            .Include(x => x.Ref5)
            .Include(x => x.BigRef),
        _ => throw new ArgumentOutOfRangeException()
    };
    var splitQuery = SplitQueries ? query.AsSplitQuery() : query;
    return splitQuery.Take(2).ToList();
}

Полный код бенчмарка доступен на гитхабе.

Я запускал бенчмарк на домашней машине, СУБД в дефолтной конфигурации, подключение локальное через localhost.

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19042
AMD Ryzen 5 2400G with Radeon Vega Graphics, 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=5.0.201
  [Host]     : .NET Core 5.0.4 (CoreCLR 5.0.421.11614, CoreFX 5.0.421.11614), X64 RyuJIT  [AttachedDebugger]
  Job-HMJXLI : .NET Core 5.0.4 (CoreCLR 5.0.421.11614, CoreFX 5.0.421.11614), X64 RyuJIT

InvocationCount=1  UnrollFactor=1  

Обратите внимание на выделенные значения. Добавление одной дополнительной коллекции всего с 10 записями (пусть и с относительно большими данными) приводит к деградации в почти 30 раз.

А при использовании разделенных запросов разница уже не так драматична. Да и сами цифры значительно меньше в абсолютных величинах (5,5 мс против 34625 мс).

Всем спасибо и следите за комбинаторными взрывами!

Ссылки

• Описание от Microsoft
• Остальные фичи EF Core 5.0
• Репозиторий с бенчмарком
• Оригинал на хабре