Posted inProgramming

Khắc phục vấn đề N+1 trong GraphQL: Sử dụng DataLoader để tối ưu hiệu suất API

Programming tutorial - IT technology blog
Programming tutorial - IT technology blog

Kẻ sát nhân thầm lặng của cơ sở dữ liệu trong GraphQL

GraphQL cho phép client chọn chính xác dữ liệu họ cần. Mặc dù điều này rất tuyệt vời cho các nhà phát triển frontend, nhưng nó thường tạo ra một cơn ác mộng về hiệu suất vốn luôn tiềm ẩn cho đến khi bạn triển khai thực tế. Tôi từng triển khai một bảng điều khiển mạng xã hội hoạt động hoàn hảo trong môi trường staging với 50 bản ghi. Tuy nhiên, ngay khi chúng tôi chuyển sang cơ sở dữ liệu thực tế với 10.000 người dùng hoạt động, CPU đã vọt lên 100%. Thời gian phản hồi tăng từ 150ms mượt mà lên tới 5 giây đầy đau đớn.

Vấn đề nằm ở đâu? Đó là mô hình truy vấn N+1 kinh điển. Làm chủ vấn đề này là điều tối quan trọng nếu bạn muốn xây dựng các hệ thống backend không bị sụp đổ dưới áp lực. Nếu không có giải pháp khắc phục, máy chủ GraphQL của bạn về cơ bản đang thực hiện một cuộc tấn công từ chối dịch vụ (DoS) tự gây ra lên chính cơ sở dữ liệu của mình.

Vấn đề N+1 chính xác là gì?

Để hiểu nguyên nhân gốc rễ, hãy xem cách GraphQL phân giải dữ liệu. Nó thực hiện các resolver theo cách lồng nhau và đệ quy. Hãy tưởng tượng một truy vấn lấy danh sách các bài viết và tác giả của chúng:

query {
  posts {
    id
    title
    author {
      name
    }
  }
}

Nếu resolver posts của bạn trả về 100 mục, engine GraphQL sẽ kích hoạt resolver author 100 lần riêng biệt. Nhật ký cơ sở dữ liệu của bạn sẽ trông như thế này:

SELECT * FROM posts; -- (1 truy vấn để lấy danh sách)
SELECT * FROM users WHERE id = 1; -- (+1 truy vấn)
SELECT * FROM users WHERE id = 2; -- (+2 truy vấn)
... 
SELECT * FROM users WHERE id = 100; -- (+100 truy vấn)

Đây chính là cái bẫy “N+1”: một truy vấn cho các bản ghi cha và N truy vấn bổ sung cho các bản ghi con. Việc lấy 1.000 bài viết sẽ dẫn đến 1.001 lần gọi cơ sở dữ liệu chỉ cho một yêu cầu duy nhất. Hành vi này nhanh chóng làm cạn kiệt connection pool của cơ sở dữ liệu và gây ra độ trễ cực lớn.

So sánh các chiến lược: Join thủ công vs. DataLoader

Trước khi triển khai giải pháp, việc hiểu tại sao các thói quen SQL truyền thống không phải lúc nào cũng áp dụng tốt cho GraphQL là rất hữu ích.

1. Cách tiếp cận sử dụng Join (Phong cách SQL)

Bạn có thể thử viết một câu lệnh SQL JOIN phức tạp trong resolver posts cấp cao nhất. Mặc dù cách này hiệu quả với các cấu trúc phẳng, nhưng nó phá hủy tính mô-đun của GraphQL. Resolver posts không nên phải biết liệu client có yêu cầu tên tác giả hay năm bình luận gần nhất của họ hay không. Điều này dẫn đến tình trạng “Over-fetching” (lấy thừa dữ liệu) và mã nguồn trở nên cứng nhắc, bị phụ thuộc lẫn nhau.

2. Cách tiếp cận sử dụng DataLoader

DataLoader là một tiện ích sử dụng hai kỹ thuật chính: Batching (Gom nhóm) và Caching (Bộ nhớ đệm). Thay vì chạy một truy vấn ngay lập tức, DataLoader chờ đợi trong một “tick” của event loop trong Node.js. Nó thu thập mọi ID được yêu cầu và thực hiện một truy vấn batch duy nhất để lấy tất cả cùng một lúc.

Ưu và nhược điểm

  • Join thủ công: Tốt nhất để giảm số lần kết nối cơ sở dữ liệu xuống còn một lần duy nhất, nhưng là một cơn ác mộng để bảo trì khi schema của bạn phát triển.
  • DataLoader: Giữ cho các resolver sạch sẽ và cô lập. Nó giúp giảm đáng kể tải trọng cho cơ sở dữ liệu và cung cấp bộ nhớ đệm tích hợp sẵn trong suốt thời gian diễn ra yêu cầu (request).

Thiết lập được khuyến nghị

Cách tiếp cận tốt nhất là tạo các instance loader mới cho mỗi yêu cầu HTTP. Điều này giúp giữ cho bộ nhớ đệm được cô lập cho từng người dùng riêng biệt. Nó ngăn chặn rò rỉ dữ liệu trong khi vẫn tối ưu hóa đường dẫn thực thi cho truy vấn cụ thể đó.

Tôi thường gắn các loader vào context của GraphQL. Điều này giúp chúng có thể truy cập được từ bất kỳ resolver nào trong cây dữ liệu:

// Cấu trúc Context cho Apollo hoặc Yoga
const context = async ({ req }) => {
  return {
    db,
    loaders: {
      userLoader: createUserLoader(db),
    }
  };
};

Hướng dẫn triển khai: Từng bước một

Hãy xây dựng một bản triển khai thực tế bằng cách sử dụng thư viện dataloader tiêu chuẩn.

Bước 1: Cài đặt thư viện phụ thuộc

npm install dataloader

Bước 2: Định nghĩa hàm Batch

Hàm batch là trái tim của loader. Nó nhận vào một mảng các khóa (keys) và phải trả về một Promise phân giải thành một mảng các giá trị. Mảng kết quả phải khớp chính xác với độ dài và thứ tự của các khóa đầu vào.

const DataLoader = require('dataloader');

const batchUsers = async (userIds) => {
  // Lấy tất cả người dùng trong một lần
  const users = await db.table('users').whereIn('id', userIds);

  // Ánh xạ người dùng vào một object để tra cứu nhanh
  const userMap = {};
  users.forEach(user => {
    userMap[user.id] = user;
  });

  // Duy trì thứ tự ban đầu của userIds
  return userIds.map(id => userMap[id] || null);
};

const userLoader = new DataLoader(batchUsers);

Bước 3: Tích hợp với Resolver

Hãy ngừng gọi trực tiếp cơ sở dữ liệu trong các resolver lồng nhau của bạn. Thay vào đó, hãy sử dụng phương thức .load() của loader.

const resolvers = {
  Post: {
    author: (parent, args, context) => {
      // DataLoader tự động gom nhóm các lần gọi này!
      return context.loaders.userLoader.load(parent.authorId);
    }
  }
};

Cơ chế hoạt động bên dưới

  1. Resolver posts trả về 100 mục.
  2. Resolver author được gọi 100 lần, nhưng nó chỉ đưa userLoader.load(id) vào hàng đợi.
  3. DataLoader đợi ngăn xếp thực thi hiện tại kết thúc.
  4. Nó kích hoạt batchUsers một lần duy nhất với tất cả 100 ID.
  5. Cơ sở dữ liệu chạy lệnh SELECT * FROM users WHERE id IN (1, 2, ..., 100).
  6. DataLoader gửi kết quả trở lại cho từng resolver cụ thể.

Sức mạnh của Caching cấp độ Request

DataLoader cũng cung cấp khả năng lưu bộ nhớ đệm tự động. Nếu năm bài viết khác nhau được viết bởi cùng một tác giả, userLoader.load(authorId) sẽ được gọi với cùng một ID năm lần. DataLoader nhận ra ID trùng lặp và trả về Promise hiện có. Nó thậm chí không thêm ID trùng lặp vào batch, mang lại hiệu suất tăng vọt cho dữ liệu có tính kết nối cao.

Hãy lưu ý rằng bộ nhớ đệm này chỉ là tạm thời. Nó chỉ tồn tại trong vòng đời của một yêu cầu HTTP. Thiết kế này là có mục đích. Việc lưu bộ nhớ đệm toàn cục thường dẫn đến dữ liệu cũ (stale data) và rò rỉ bộ nhớ rất khó gỡ lỗi.

Các thực hành tốt nhất cho môi trường Production

  • Ánh xạ kết quả của bạn: Cơ sở dữ liệu không phải lúc nào cũng trả về các hàng theo đúng thứ tự bạn yêu cầu. Luôn ánh xạ kết quả của bạn trở lại các ID đầu vào để ngăn chặn sự sai lệch dữ liệu.
  • Xử lý các bản ghi bị thiếu: Nếu một bản ghi không tồn tại, hãy trả về null cho vị trí đó. Đừng bao giờ bỏ qua một index, nếu không dữ liệu của bạn sẽ bị lệch và bị gán sai cho bản ghi cha.
  • Giới hạn kích thước batch: Đối với các tập dữ liệu khổng lồ, hãy sử dụng tùy chọn maxBatchSize (ví dụ: 1000). Điều này giúp ngăn chặn việc tạo ra các truy vấn SQL quá lớn khiến cơ sở dữ liệu không thể xử lý.

Làm chủ DataLoader đã thay đổi cách tôi thiết kế kiến trúc backend GraphQL. Nó giữ cho mã nguồn của bạn được tách biệt (decoupled) trong khi vẫn mang lại hiệu quả như khi sử dụng SQL được tối ưu thủ công. Nếu bạn đang xây dựng bất cứ thứ gì vượt xa một bản mẫu đơn giản, DataLoader không chỉ là một sự tối ưu hóa — đó là một yêu cầu bắt buộc.

Share:
Tags: