مشکل کجاست؟ معضل N+1 Query

یکی از شایع‌ترین مشکلاتی که توسعه‌دهندگان هنگام کار با EF Core با آن مواجه می‌شوند، مشکل N+1 Query است. این مشکل زمانی رخ می‌دهد که شما ابتدا یک لیست از موجودیت‌ها را واکشی کرده و سپس در یک حلقه، داده‌های مرتبط با هر موجودیت را جداگانه بارگذاری می‌کنید.

سناریوی مشکل‌زا:

فرض کنید مدلی برای Blog و Post داریم:

public class Blog
{
    public int BlogId { get; set; }
    public string Url { get; set; }
    public ICollection Posts { get; set; } = new List();
}

public class Post
{
    public int PostId { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }
    public int BlogId { get; set; }
    public Blog Blog { get; set; }
}

حالا تصور کنید می‌خواهیم 100 وبلاگ را به همراه پست‌هایشان نمایش دهیم. یک رویکرد ساده‌انگارانه به شکل زیر خواهد بود:

var blogs = await _context.Blogs.Take(100).ToListAsync(); // 1 Query

foreach (var blog in blogs)
{
    // برای هر وبلاگ، یک کوئری جداگانه به پایگاه داده ارسال می‌شود
    var posts = await _context.Posts.Where(p => p.BlogId == blog.BlogId).ToListAsync(); // N (100) Queries
    // ... پردازش پست‌ها
}

در این کد، ابتدا یک کوئری برای گرفتن 100 وبلاگ (1) و سپس به ازای هر وبلاگ، یک کوئری دیگر برای گرفتن پست‌های آن (N یا 100) اجرا می‌شود. در مجموع 101 کوئری به پایگاه داده ارسال می‌شود که به شدت ناکارآمد است.

راه‌حل‌های استاندارد EF Core

EF Core برای حل این مشکل، راهکارهای داخلی ارائه می‌دهد:

1. Eager Loading (بارگذاری حریصانه): با استفاده از متد Include(), می‌توانید داده‌های مرتبط را در همان کوئری اولیه بارگذاری کنید.

   var blogs = await _context.Blogs
                             .Include(b => b.Posts) // تمام پست‌ها را در یک کوئری JOIN می‌کند
                             .Take(100)
                             .ToListAsync(); // تنها 1 کوئری اجرا می‌شود
   

   این روش مشکل N+1 را حل می‌کند، اما اگر تعداد پست‌های هر وبلاگ بسیار زیاد باشد، یک کوئری JOIN عظیم ایجاد می‌کند که می‌تواند باعث "Cartesian Explosion" شود و حجم زیادی از داده تکراری را از پایگاه داده به سمت کلاینت منتقل کند.

2. Explicit Loading (بارگذاری صریح): شما می‌توانید موجودیت‌ها را ابتدا بارگذاری کرده و سپس داده‌های مرتبط را به صورت صریح واکشی کنید.

   var blog = await _context.Blogs.FirstAsync(b => b.BlogId == 1);
   await _context.Entry(blog).Collection(b => b.Posts).LoadAsync();
   

   این روش برای یک موجودیت واحد کاربردی است اما برای لیستی از موجودیت‌ها دوباره ما را به سمت مشکل N+1 سوق می‌دهد.

3. Lazy Loading (بارگذاری تنبل): در این روش، داده‌های مرتبط تنها زمانی از پایگاه داده خوانده می‌شوند که به آن‌ها دسترسی پیدا کنیم. این روش نیازمند تعریف virtual برای Navigation Property ها و نصب پکیج Microsoft.EntityFrameworkCore.Proxies است. اگرچه استفاده از آن راحت است، اما کنترل اجرای کوئری‌ها را از دست توسعه‌دهنده خارج می‌کند و می‌تواند به طور ناخواسته منجر به مشکل N+1 شود.

ورود به دنیای واکشی دسته‌ای (Bulk-Fetching)

وقتی با حجم عظیمی از داده سروکار داریم (برای مثال، پردازش ده‌ها هزار رکورد)، حتی Eager Loading نیز ممکن است بهینه نباشد. واکشی دسته‌ای یک استراتژی پیشرفته‌تر است که هدف آن به حداقل رساندن تعداد رفت و برگشت‌ها به پایگاه داده و کاهش بار روی سرور است.

این تکنیک معمولاً با استفاده از کتابخانه‌های جانبی قدرتمند پیاده‌سازی می‌شود. یکی از محبوب‌ترین و کارآمدترین این کتابخانه‌ها EFCore.BulkExtensions است.

مثال تخصصی: پردازش و به‌روزرسانی دسته‌ای سفارش‌ها

سناریو:

فرض کنید یک فروشگاه آنلاین داریم و می‌خواهیم تمام سفارش‌های (Order) یک مشتری خاص که در وضعیت "در حال پردازش" (Processing) هستند را پیدا کرده، قیمت کل آن‌ها را بر اساس محصولات (OrderItem) محاسبه و در نهایت وضعیت آن‌ها را به "ارسال شده" (Shipped) تغییر دهیم. تعداد سفارش‌ها ممکن است هزاران عدد باشد.

مدل‌ها:

public class Customer
{
    public int CustomerId { get; set; }
    public string Name { get; set; }
}

public class Order
{
    public int OrderId { get; set; }
    public DateTime OrderDate { get; set; }
    public string Status { get; set; } // e.g., "Processing", "Shipped"
    public decimal TotalPrice { get; set; }
    public int CustomerId { get; set; }
    public Customer Customer { get; set; }
    public ICollection OrderItems { get; set; } = new List();
}

public class OrderItem
{
    public int OrderItemId { get; set; }
    public int ProductId { get; set; }
    public int Quantity { get; set; }
    public decimal UnitPrice { get; set; }
    public int OrderId { get; set; }
    public Order Order { get; set; }
}

رویکرد ناکارآمد (روش سنتی):

public async Task ProcessOrdersForCustomerAsync(int customerId)
{
    var ordersToProcess = await _context.Orders
                                        .Where(o => o.CustomerId == customerId && o.Status == "Processing")
                                        .Include(o => o.OrderItems) // Eager Loading
                                        .ToListAsync();

    foreach (var order in ordersToProcess)
    {
        // محاسبه قیمت در سمت کلاینت
        order.TotalPrice = order.OrderItems.Sum(oi => oi.Quantity * oi.UnitPrice);
        order.Status = "Shipped";
    }

    // این دستور برای هر سفارش یک UPDATE جداگانه ارسال می‌کند
    await _context.SaveChangesAsync();
}

مشکلات این رویکرد:

1. حافظه زیاد: ToListAsync() تمام سفارش‌ها و آیتم‌های مرتبط را در حافظه بارگذاری می‌کند. اگر مشتری 10,000 سفارش داشته باشد، میلیون‌ها رکورد OrderItem ممکن است در RAM بارگذاری شوند.

2. به‌روزرسانی ناکارآمد: SaveChangesAsync() در یک حلقه روی موجودیت‌های تغییریافته حرکت کرده و برای هر کدام یک دستور UPDATE مجزا تولید می‌کند. 10,000 سفارش به معنای 10,000 دستور UPDATE خواهد بود.

راه‌حل بهینه با Bulk-Fetching و Bulk-Update

برای حل این مشکل، از کتابخانه EFCore.BulkExtensions استفاده می‌کنیم. این کتابخانه به ما اجازه می‌دهد تا عملیات SELECT, UPDATE, DELETE و INSERT را به صورت دسته‌ای و با عملکرد بسیار بالا اجرا کنیم.

قدم اول: نصب کتابخانه

dotnet add package EFCore.BulkExtensions

قدم دوم: پیاده‌سازی بهینه

به جای بارگذاری کل موجودیت‌ها در حافظه، ما فقط شناسه‌های (ID) سفارش‌های مورد نیاز را واکشی می‌کنیم. سپس با استفاده از این شناسه‌ها، عملیات را به صورت دسته‌ای انجام می‌دهیم.

using EFCore.BulkExtensions;

public async Task ProcessOrdersForCustomerBulkAsync(int customerId)
{
    // 1. فقط شناسه‌های سفارش‌های مورد نظر را با کمترین هزینه واکشی می‌کنیم
    var orderIds = await _context.Orders
                                 .Where(o => o.CustomerId == customerId && o.Status == "Processing")
                                 .Select(o => o.OrderId)
                                 .ToListAsync();

    if (!orderIds.Any())
    {
        return; // هیچ سفارشی برای پردازش وجود ندارد
    }

    // 2. واکشی دسته‌ای آیتم‌های سفارش فقط برای سفارش‌های مشخص شده
    // ما تمام آیتم‌های مرتبط را در یک کوئری با استفاده از `Where(id IN (...))` واکشی می‌کنیم.
    var allOrderItems = await _context.OrderItems
                                      .Where(oi => orderIds.Contains(oi.OrderId))
                                      .ToListAsync();

    // 3. گروه‌بندی آیتم‌ها بر اساس شناسه سفارش در حافظه (این عملیات سریع است)
    var itemsByOrderId = allOrderItems.GroupBy(oi => oi.OrderId)
                                      .ToDictionary(g => g.Key, g => g.ToList());

    // 4. ایجاد لیستی از موجودیت‌های بروزرسانی شده بدون ردیابی توسط EF Core
    var ordersToUpdate = new List();
    foreach (var orderId in orderIds)
    {
        var order = new Order { OrderId = orderId }; // فقط شامل فیلدهایی است که می‌خواهیم آپدیت کنیم

        if (itemsByOrderId.TryGetValue(orderId, out var items))
        {
            order.TotalPrice = items.Sum(oi => oi.Quantity * oi.UnitPrice);
        }
        else
        {
            order.TotalPrice = 0;
        }

        order.Status = "Shipped";
        ordersToUpdate.Add(order);
    }

    // 5. اجرای به‌روزرسانی دسته‌ای (Bulk Update)
    // این دستور تنها یک statement `UPDATE` (معمولا با MERGE) به پایگاه داده ارسال می‌کند
    // و فقط فیلدهای مشخص شده را آپدیت می‌کند.
    var bulkConfig = new BulkConfig
    {
        PropertiesToUpdate = new List { nameof(Order.TotalPrice), nameof(Order.Status) },
        UpdateByProperties = new List { nameof(Order.OrderId) } // کلید اصلی برای شناسایی رکوردها
    };

    await _context.BulkUpdateAsync(ordersToUpdate, bulkConfig);
}

تحلیل راه‌حل بهینه

1. واکشی سبک: در مرحله اول، به جای بارگذاری کل گراف موجودیت Order و OrderItem، فقط لیستی از int (شناسه‌های سفارش) را واکشی کردیم. این کار بار حافظه و شبکه را به شدت کاهش می‌دهد.

2. واکشی دسته‌ای هدفمند: در مرحله دوم، با استفاده از Contains(), EF Core یک کوئری بهینه به شکل WHERE OrderId IN (id1, id2, ...) تولید می‌کند. این کوئری تمام OrderItem های مورد نیاز را در یک رفت و برگشت به پایگاه داده واکشی می‌کند. این قلب مفهوم Bulk-Fetch است.

3. پردازش در حافظه: محاسبات و گروه‌بندی داده‌ها در سمت کلاینت و در حافظه انجام می‌شود که بسیار سریع‌تر از پردازش در پایگاه داده برای این سناریوی خاص است.

4. عملیات BulkUpdateAsync: این جادوی EFCore.BulkExtensions است. به جای تولید N دستور UPDATE، این متد یک دستور واحد و بهینه (معمولاً با استفاده از MERGE در SQL Server) ایجاد می‌کند. ما به صراحت مشخص کرده‌ایم که فقط فیلدهای TotalPrice و Status باید به‌روز شوند (PropertiesToUpdate) که این کار از بازنویسی ناخواسته سایر فیلدها جلوگیری می‌کند.

مقایسه عملکرد

جمع‌بندی

واکشی دسته‌ای (Bulk-Fetching) یک تکنیک حیاتی برای ساخت برنامه‌های کاربردی با کارایی بالا و مقیاس‌پذیر با استفاده از EF Core است. در حالی که ابزارهای داخلی مانند Include برای سناریوهای کوچک و متوسط عالی هستند، در مواجهه با حجم داده‌های بزرگ، آن‌ها به سرعت به گلوگاه عملکرد تبدیل می‌شوند.

با استفاده هوشمندانه از استراتژی‌هایی مانند واکشی شناسه‌ها و سپس بارگذاری دسته‌ای داده‌های مرتبط، و ترکیب آن با کتابخانه‌هایی مانند EFCore.BulkExtensions برای عملیات CUD (Create, Update, Delete) دسته‌ای، می‌توانید به طرز چشمگیری عملکرد برنامه خود را بهبود بخشیده و فشار بر روی سرور پایگاه داده را به حداقل برسانید. این رویکرد نیازمند تفکر بیشتر و کدنویسی دقیق‌تر است، اما نتیجه آن یک برنامه قوی، سریع و قابل اعتماد خواهد بود.