Điều chỉnh truy vấn nên chủ động hay phản ứng?

Là một nhà phát triển phần mềm và một DBA đầy tham vọng, tôi cố gắng kết hợp các thực tiễn tốt nhất khi tôi thiết kế cơ sở dữ liệu SQL Server của mình (99% thời gian phần mềm của tôi nằm trên SQL Server). Tôi thực hiện thiết kế tốt nhất có thể trước và trong quá trình phát triển.

Nhưng, giống như bất kỳ nhà phát triển phần mềm nào khác, có thêm chức năng, lỗi và chỉ thay đổi các yêu cầu yêu cầu thay đổi / tạo các đối tượng cơ sở dữ liệu.

Câu hỏi của tôi là, nên điều chỉnh truy vấn là chủ động hay phản ứng? Nói cách khác, một vài tuần sau khi sửa đổi mã / cơ sở dữ liệu nặng, tôi có nên dành ra một ngày để kiểm tra hiệu năng truy vấn và điều chỉnh dựa trên điều đó không? Ngay cả khi nó dường như đang chạy ổn ?

Hoặc tôi chỉ nên biết rằng hiệu suất thấp hơn mức trung bình nên là một kiểm tra cơ sở dữ liệu và quay trở lại bảng phấn tục ngữ?

Điều chỉnh truy vấn có thể mất rất nhiều thời gian và tùy thuộc vào thiết kế cơ sở dữ liệu ban đầu, nó có thể mang lại lợi ích tối thiểu. Tôi tò mò về modus operandi được chấp nhận.

Cả hai, nhưng chủ yếu là chủ động

Điều quan trọng là phải kiểm tra trong quá trình phát triển dựa trên khối lượng thực tế và chất lượng dữ liệu. Thật không thể tin được là có một truy vấn chạy trên 100 hoặc 1000 hàng của nhà phát triển, sau đó giảm xuống với 10 triệu hàng sản xuất.

Nó cho phép bạn ghi chú quá về "chỉ mục có thể giúp ở đây". Hoặc "thăm lại tôi". Hoặc "sẽ sửa với tính năng mới xxx trong phiên bản DB tiếp theo".

Tuy nhiên, một vài truy vấn sẽ không vượt qua được thử thách của thời gian. Phân phối dữ liệu thay đổi hoặc nó đi theo cấp số nhân vì trình tối ưu hóa quyết định sử dụng một loại kết nối khác. Trong trường hợp này, bạn chỉ có thể phản ứng.

Nói rằng, đối với SQL Server ít nhất, các truy vấn DMV "thiếu chỉ mục" và "truy vấn dài nhất" khác nhau có thể chỉ ra các khu vực có vấn đề trước khi gọi điện thoại

Chỉnh sửa: để làm rõ ...

Chủ động không có nghĩa là điều chỉnh mọi truy vấn bây giờ. Nó có nghĩa là điều chỉnh những gì bạn cần (thường xuyên chạy) đến thời gian đáp ứng hợp lý. Chủ yếu bỏ qua các truy vấn báo cáo 3 giờ sáng chủ nhật hàng tuần.

OK, tôi sẽ cắn và có một cái nhìn trái ngược. Trước hết, tôi sẽ nói bạn không bao giờ nên bắt đầu bằng cách làm điều gì đó mà bạn biết sẽ dẫn bạn vào rắc rối. Nếu bạn muốn gọi đây là cách thực hành tốt nhất, hãy tiếp tục. Điều này là xa như là chủ động nên đi.

Sau đó, lãng phí thời gian (và tiền bạc) vì vậy hãy tiếp tục với nó và giao sản phẩm của bạn. Thay vì mất hàng tấn truy vấn điều chỉnh thời gian thiết kế có thể hoặc không bao giờ trở thành cổ chai, hãy sử dụng thời gian đó để kiểm tra thêm, bao gồm kiểm tra tải.

Khi bạn phát hiện ra rằng một cái gì đó không hoạt động theo thông số kỹ thuật thiết kế của bạn hoặc nếu có thứ gì đó rơi vào đáy 10% hoặc 20% trong danh sách thời gian phản hồi của hồ sơ của bạn, thì hãy đầu tư thời gian bạn cần điều chỉnh bất cứ thứ gì đó là bị hỏng.

Trong một thế giới hoàn hảo, mọi thứ sẽ được thiết kế hoàn hảo ngay từ đầu và được phát triển bằng cách sử dụng trình tự xây dựng logic. Trong thế giới thực, có những hạn chế về ngân sách và thời gian và dữ liệu thử nghiệm của bạn có thể không giống như dữ liệu sản xuất của bạn. Vì lý do này, tôi nói sử dụng lẽ thường để tránh các vấn đề một cách chủ động nhưng tập trung các nguồn lực hạn chế của bạn để điều chỉnh những thứ trở thành vấn đề thực sự thay vì tốn thời gian và tiền bạc mà bạn có thể không tìm kiếm cho các vấn đề tưởng tượng hoặc tiềm năng.

Bạn sẽ thực hiện 3 loại điều chỉnh, 1 phản ứng và 2 chủ động.

Phản ứng

Không có màu xanh, một số truy vấn bắt đầu gây ra vấn đề cho bạn. Đó có thể là do lỗi ứng dụng hoặc tính năng, bảng phát triển vượt quá mong đợi, tăng lưu lượng truy cập hoặc trình tối ưu hóa truy vấn trở nên "sáng tạo". Đây có thể là một kiểu ngoại tình ảm đạm vào giữa đêm, hoặc nó có thể là để đáp ứng với sự chậm chạp của hệ thống có tính chất không quan trọng. Dù bằng cách nào, đặc điểm xác định của điều chỉnh phản ứng là bạn đã có vấn đề . Không cần phải nói, bạn muốn làm càng ít điều này càng tốt. Điều này đưa chúng ta đến ...

Chủ động

Loại 1: Bảo trì định kỳ

Theo một số loại lịch biểu, cứ sau vài tháng hoặc vài tuần tùy thuộc vào tần suất thay đổi lược đồ của bạn và tốc độ tăng dữ liệu của bạn, bạn nên xem lại đầu ra của các công cụ phân tích hiệu suất của cơ sở dữ liệu của mình (ví dụ: báo cáo AWR cho Oracle DBA). Bạn đang tìm kiếm các vấn đề khó khăn, đó là những điều đang trên đường yêu cầu điều chỉnh Phản ứng, cũng như trái cây treo thấp, các mặt hàng không có khả năng gây ra sự cố sớm nhưng có thể được cải thiện với ít nỗ lực với hy vọng ngăn chặn xa vấn đề -future. Bạn nên dành bao nhiêu thời gian cho việc này sẽ phụ thuộc vào thời gian bạn có, và những gì khác bạn có thể dành cho nó, nhưng số tiền tối ưu không bao giờ bằng không. Tuy nhiên, bạn có thể dễ dàng giảm số tiền bạn cần chi tiêu bằng cách thực hiện thêm ...

Loại 2: Thiết kế phù hợp

Lời khuyên của Knuth chống lại "tối ưu hóa sớm" được biết đến rộng rãi và được tôn trọng đúng mức. Nhưng định nghĩa đúng của "sớm" phải được sử dụng. Một số nhà phát triển ứng dụng, khi được phép viết các truy vấn của riêng họ, có xu hướng chấp nhận truy vấn đầu tiên mà họ đánh vào đó là chính xác về mặt logic và không quan tâm đến hiệu suất, hiện tại hay tương lai. Hoặc họ có thể kiểm tra đối với tập dữ liệu phát triển đơn giản là không đại diện cho môi trường sản xuất (mẹo: Đừng làm điều này! Các nhà phát triển phải luôn có quyền truy cập vào dữ liệu thực tế để thử nghiệm.). Vấn đề là thời điểm thích hợp để điều chỉnh truy vấn là khi nó được triển khai lần đầu tiên, chứ không phải khi nó hiển thị trên danh sách SQL hoạt động kém và chắc chắn không phải khi nó gây ra sự cố nghiêm trọng.

Vì vậy, những gì sẽ đủ điều kiện là một tối ưu hóa sớm trong đất DBA? Ở đầu danh sách của tôi sẽ là hy sinh bình thường hóa mà không cần một nhu cầu chứng minh. Chắc chắn bạn có thể duy trì một khoản tiền trên một hàng cha mẹ thay vì tính toán nó trong thời gian chạy từ các hàng con, nhưng bạn có thực sự cần phải không? Nếu bạn là Twitter hoặc Amazon, tính toán bình thường hóa và tính toán trước có thể là người bạn tốt nhất của bạn. Nếu bạn đang thiết kế một cơ sở dữ liệu kế toán nhỏ cho 5 người dùng, cấu trúc phù hợp để tạo điều kiện cho tính toàn vẹn dữ liệu cần được ưu tiên hàng đầu. Tối ưu hóa sớm khác cũng là một vấn đề ưu tiên. Đừng mất hàng giờ để điều chỉnh một truy vấn được chạy một lần một ngày và mất 10 giây, ngay cả khi bạn nghĩ rằng bạn có thể cắt nó thành 0,1 giây. Có thể bạn có một báo cáo chạy trong 6 giờ hàng ngày, nhưng hãy khám phá việc lên lịch cho nó như một công việc hàng loạt trước khi đầu tư thời gian vào việc điều chỉnh nó. Không đầu tư vào một trường hợp báo cáo nhân rộng theo thời gian thực riêng biệt nếu tải sản xuất của bạn không bao giờ vượt quá 10% (giả sử bạn có thể quản lý bảo mật).

Bằng cách kiểm tra dữ liệu thực tế, thực hiện các dự đoán có giáo dục về tăng trưởng và mô hình lưu lượng truy cập (cộng với các khoản phụ cấp cho các đột biến) và áp dụng kiến ​​thức về các yêu cầu tối ưu hóa nền tảng của bạn, bạn có thể triển khai các truy vấn chạy (gần) tối ưu không chỉ trong hiện tại, mà trong tương lai và trong các điều kiện ít hơn lý tưởng. Khi bạn áp dụng các kỹ thuật phù hợp, hiệu suất truy vấn có thể được dự đoán chính xác và được tối ưu hóa (theo nghĩa của từng thành phần là nhanh nhất có thể).

(Và trong khi bạn đang ở đó, hãy tìm hiểu số liệu thống kê! )

Trong một thế giới hoàn hảo, tất cả việc điều chỉnh sẽ được thực hiện trong giai đoạn thiết kế một cách chủ động và không có gì có thể gây phản ứng, nhưng thế giới không hoàn hảo. Bạn sẽ thấy rằng dữ liệu kiểm tra đôi khi không đại diện, các trường hợp kiểm tra sẽ bị bỏ qua, tải sẽ khác nhau bất ngờ và sẽ có lỗi gây ra vấn đề về hiệu suất. Những tình huống này có thể yêu cầu một số điều chỉnh phản ứng, nhưng điều đó không có nghĩa là điều chỉnh phản ứng được ưu tiên. Mục tiêu phải luôn luôn là để bắt những thứ này lên phía trước.

Kế hoạch điều chỉnh hồi tố của bạn là rất thực dụng. Khi bạn đang kiểm tra, bạn nên ghi lại thời gian và thông lượng dự kiến ​​và đôi khi nên thực sự xây dựng phân tích cho phép bạn biết khi nào quy trình sản xuất không đáp ứng các thông số kỹ thuật thiết kế. Bằng cách này, bạn có thể xác định trước những mã nào cần được điều chỉnh. Sau đó, bạn có thể xác định không chỉ vấn đề là gì, mà tại sao bạn không nắm bắt được nó trong giai đoạn thiết kế / thử nghiệm.

Đối với tôi, kiểm tra hiệu suất luôn là một phần của quá trình phát triển. Bạn muốn thay đổi bảng này, thay đổi báo cáo này, thêm tính năng này? Là một phần của thử nghiệm, bạn đảm bảo rằng bạn có thể so sánh hiệu suất của từng cá nhân và tổng thể với các đường cơ sở đã biết và / hoặc với các yêu cầu (ví dụ: một số báo cáo chạy trong nền hoặc được tự động hóa, do đó hiệu suất - hay đúng hơn là tốc độ - của mỗi truy vấn duy nhất trong hệ thống không phải luôn luôn là ưu tiên hàng đầu).

IMHO, đây hoàn toàn không phải là một quá trình phản ứng - bạn không bao giờ nên đợi cho đến khi thay đổi gây ra vấn đề về hiệu suất trong sản xuất để bắt đầu phản ứng với nó. Khi bạn thực hiện thay đổi trong dev / test, v.v., bạn nên kiểm tra những thay đổi đó với dữ liệu tương tự trên phần cứng tương tự với cùng các ứng dụng và mô hình sử dụng tương tự. Đừng để những thay đổi này được đưa vào sản xuất và làm bạn ngạc nhiên. Điều này hầu như sẽ luôn xảy ra khi không thuận tiện để dành một ngày điều chỉnh - ngân sách cho thời gian điều chỉnh đó trước.