Kích thước lô được đề xuất cho SqlBulkCopy là gì?

Question

Kích thước lô được đề xuất cho SqlBulkCopy là bao nhiêu? Tôi đang tìm một công thức chung tôi có thể sử dụng như một điểm khởi đầu để điều chỉnh hiệu suất.

Answer 1

Tôi có tiện ích nhập trên cùng một máy chủ vật lý làm phiên bản SQL Server của mình. Sử dụng tùy chỉnh IDataReader, nó phân tích các tệp phẳng và chèn chúng vào cơ sở dữ liệu bằng cách sử dụng SQLBulkCopy. Một tệp điển hình có khoảng 6M hàng đủ điều kiện, trung bình 5 cột văn bản thập phân và ngắn, khoảng 30 byte mỗi hàng.

Với kịch bản này, tôi đã tìm thấy kích thước lô là 5.000 là sự thỏa hiệp tốt nhất về tốc độ và mức tiêu thụ bộ nhớ. Tôi bắt đầu với 500 và thử nghiệm với lớn hơn. Tôi tìm thấy 5000 nhanh hơn 2,5 lần, trung bình hơn 500. Chèn 6 triệu hàng mất khoảng 30 giây với kích thước lô là 5.000 và khoảng 80 giây với kích thước lô là 500.

10.000 không thể đo được nhanh hơn. Di chuyển lên đến 50.000 cải thiện tốc độ của một vài điểm phần trăm nhưng nó không có giá trị tăng tải trên máy chủ. Trên 50.000 cho thấy không có sự cải thiện về tốc độ.

Đây không phải là công thức, nhưng đó là một điểm dữ liệu khác để bạn sử dụng.

Answer 2

Tất cả điều này phụ thuộc vào việc triển khai của bạn.

Bạn có thể mong đợi tốc độ nào trên mạng của mình? Bạn có đang sử dụng nó trong Biểu mẫu hoặc ASP.Net không? Bạn có cần cảnh báo cho người dùng về tiến trình không? Kích thước của tổng số công việc là bao nhiêu?

Trong kinh nghiệm của tôi chạy bản sao hàng loạt không có kích thước lô được chỉ định sẽ gây ra vấn đề thời gian chờ. Tôi thích bắt đầu với 1000 bản ghi và thực hiện một số điều chỉnh từ đó.

Answer 3

Đây là vấn đề mà tôi cũng đã dành thời gian xem xét. Tôi đang tìm cách tối ưu hóa việc nhập các tệp CSV lớn (16+ GB, 65+ triệu bản ghi và phát triển) vào cơ sở dữ liệu SQL Server 2005 bằng cách sử dụng ứng dụng giao diện điều khiển C# (.Net 2.0). Vì Jeremy có already pointed out, bạn sẽ cần thực hiện một số điều chỉnh cho các trường hợp cụ thể của mình, nhưng tôi khuyên bạn nên có kích thước lô ban đầu là 500 và thử nghiệm cả hai giá trị trên và dưới đây.

Tôi nhận đề xuất kiểm tra các giá trị từ 100 đến 1000 cho kích thước lô từ MSDN forum post này và đã hoài nghi. Nhưng khi tôi kiểm tra kích thước lô từ 100 đến 10.000, tôi thấy rằng 500 là giá trị tối ưu cho ứng dụng của tôi. Giá trị 500 cho SqlBulkCopy.BatchSize cũng được đề xuất here.

Để tiếp tục tối ưu hóa hoạt động SqlBulkCopy của bạn, hãy xem MSDN advice này; Tôi thấy rằng việc sử dụng SqlBulkCopyOptions.TableLock giúp giảm thời gian tải.

Answer 4

Như những người khác đã nêu, điều đó phụ thuộc vào môi trường của bạn cụ thể là khối lượng hàng và thời gian chờ của mạng.

Cá nhân, tôi sẽ bắt đầu bằng cách đặt thuộc tính BatchSize thành 1000 hàng và xem cách thực hiện. Nếu nó hoạt động, sau đó tôi tiếp tục tăng gấp đôi số hàng (ví dụ: 2000, 4000, v.v.) cho đến khi tôi hết thời gian chờ.

Nếu không, nếu thời gian chờ xảy ra ở 1000, thì tôi sẽ giảm số lượng hàng xuống một nửa (ví dụ: 500) cho đến khi hoạt động.

Trong mỗi trường hợp, tôi tiếp tục tăng gấp đôi (nếu thành công) hoặc giảm một nửa (nếu không thành công) sự khác biệt giữa mỗi kích thước hàng loạt thử cuối cùng cho đến khi tìm điểm ngọt.

Yếu tố khác cần xem xét là phải mất bao lâu để sao chép đơn hàng lô hàng. Thời gian chờ sẽ xảy ra nếu lô hàng được sao chép vượt quá thuộc tính BulkCopyTimeout theo mặc định là 30 giây. Bạn có thể thử tăng gấp đôi thuộc tính BulkCopyTimeout lên 60 giây. Điều này cho phép một khoảng thời gian dài hơn cho một tập hợp lớn các hàng loạt được sao chép. Ví dụ: một loạt 50.000 hàng có thể mất khoảng 40 giây chỉ vượt quá giới hạn thời gian 30 giây, do đó việc tăng tốc lên tới 60 giây có thể giúp hiệu suất.