Là tối ưu hóa sớm để thêm các chỉ số cơ sở dữ liệu?

Một đồng nghiệp của tôi hôm nay đề nghị chúng tôi đi qua tất cả các truy vấn trong ứng dụng của chúng tôi và để thêm các chỉ số tương ứng.

Tôi cảm thấy đây là tối ưu hóa sớm vì ứng dụng của chúng tôi thậm chí chưa được phát hành. Tôi đề nghị theo dõi các truy vấn chậm khi chúng tôi phát trực tiếp và sau đó thêm các chỉ số tương ứng.

Sự đồng thuận chung khi thiết kế cơ sở dữ liệu của bạn là gì, bạn có nên thêm một chỉ mục phù hợp mỗi khi bạn viết một truy vấn mới không? Hoặc là tốt hơn để chỉ theo dõi và xem làm thế nào nó đi?

Tối ưu hóa sớm là "tối ưu hóa" một cái gì đó bởi vì cảm giác mơ hồ, trực quan rằng, điều này có thể sẽ chậm, đặc biệt là gây bất lợi cho khả năng đọc và bảo trì mã . Điều đó không có nghĩa là cố tình không tuân theo các thực tiễn tốt được thiết lập tốt về hiệu suất.

Đôi khi, đó là một đường khó vẽ, nhưng tôi chắc chắn nói rằng không thêm bất kỳ chỉ số nào trước khi bạn phát trực tiếp là tối ưu hóa quá muộn ; điều này sẽ trừng phạt những người chấp nhận sớm - những người dùng háo hức và quan trọng nhất của bạn - và cung cấp cho họ cái nhìn tiêu cực về sản phẩm của bạn, sau đó họ sẽ lan truyền trong các bài đánh giá, thảo luận, v.v. ý tưởng tốt, nhưng tôi chắc chắn sẽ làm điều đó không muộn hơn bản beta.

giám sát các truy vấn chậm khi chúng tôi phát trực tiếp

bởi vì không có gì nói lên chất lượng như làm cho người dùng của bạn đau khổ vì thiếu thiết kế!

Bạn nên biết các truy vấn nào cần chỉ mục khi bạn thiết kế các bảng, bạn biết các cột nào đang được truy vấn trong đó các mệnh đề và tham gia. Chúng nên được lập chỉ mục vì những gì có thể không rõ ràng trong môi trường sống có thể nhanh chóng trở nên rõ ràng khi tải hoặc dữ liệu được lưu trữ tăng lên. Những gì bạn không muốn làm khi điều này xảy ra là tát các chỉ mục trên mỗi truy vấn 'chậm', bạn sẽ kết thúc với một chỉ mục trên mọi thứ.

"Tối ưu hóa sớm", theo nghĩa xúc phạm của nó, có nghĩa là tối ưu hóa tốn kém mà có thể không cần thiết. Điều đó không có nghĩa là tất cả tối ưu hóa được thực hiện trước thời điểm mới nhất có thể để ngăn chặn phá sản!

Đặc biệt, việc tối ưu hóa dựa trên các bài kiểm tra hiệu suất trước khi đi vào hoạt động là hợp pháp, để đảm bảo bạn có thể đáp ứng một số yêu cầu hợp lý (mặc dù gần đúng) để ứng dụng của bạn không hoàn toàn bị hút.

Ở mức tối thiểu, bạn nên tải lên cơ sở dữ liệu của mình với lượng dữ liệu thử nghiệm hợp lý và kiểm tra mức độ đáp ứng của ứng dụng. Điều này không sớm, vì bạn biết điều đó sẽ xảy ra và nó sẽ bắt được bất kỳ truy vấn nào kích hoạt quét chậm một cách vô lý. Như AE nói trong một bình luận:

Sử dụng các chỉ mục để tránh quét toàn bộ bảng cho bất kỳ truy vấn nào mà người dùng cuối thường thực hiện trong thời gian thực

Ít nhất, đối với các bảng được lên kế hoạch để sử dụng.

Sau đó, là một lối tắt cho điều đó, nếu bạn có kinh nghiệm quan trọng với công cụ cơ sở dữ liệu và bạn đã lên kế hoạch kiểm tra khi bạn viết đoạn mã đầu tiên, thì bạn thường sẽ biết mà không cần chạy truy vấn đó. viết sẽ quá chậm nếu không có chỉ số. Tất nhiên, bạn có thể giả vờ như bạn không biết và xem thử nghiệm thất bại trước khi thêm chỉ mục để vượt qua, nhưng không có lý do gì để biết mã bị lỗi (vì không phản hồi) được phát hành trực tuyến.

Tôi cảm thấy đây là tối ưu hóa sớm vì ứng dụng của chúng tôi thậm chí chưa được phát hành. Tôi đề nghị theo dõi các truy vấn chậm khi chúng tôi phát trực tiếp và sau đó thêm các chỉ số tương ứng.

Bạn không thể đối xử với người dùng cuối và môi trường sản xuất của mình như đảm bảo chất lượng. Nói cách khác, bạn đang nói rằng bạn sẽ tìm ra nó trong sản xuất. Tôi không nghĩ đó là cách đúng đắn và tôi thấy cách tiếp cận đó sai lầm khủng khiếp mỗi ngày .

Bạn cần ghi nhớ một điều, vì bạn không thể vẽ nó bằng cọ rộng.

Khối lượng công việc chung của bạn là gì?

Điều đó nghe có vẻ rõ ràng hoặc buồn tẻ, nhưng nó có ý nghĩa trong thực tế. Nếu bạn có 10 truy vấn chiếm 98% khối lượng công việc của bạn (khá phổ biến, tin hay không), đề xuất của tôi sẽ là một phân tích cứng trước khi sản xuất . Với dữ liệu thực tế và đại diện, hãy đảm bảo 10 truy vấn đó tốt nhất có thể ( hoàn hảo là lãng phí thời gian quý báu và gần như không thể đạt được).

Đối với 200 truy vấn khác chiếm 2% khối lượng công việc , đó là những truy vấn rất có thể không đáng để bỏ công sức và sẽ tạo nên sự kỳ quặc khắc phục sự cố hoàn hảo trong trường hợp sản xuất. Đó cũng là một thực tế, và không phải là một điều tồi tệ khủng khiếp. Nhưng điều đó không có nghĩa là bỏ qua việc lập chỉ mục các thực tiễn tốt nhất hoặc đưa ra các giả định ước tính về truy xuất dữ liệu.

Đó là thông lệ và thực tiễn tốt để tìm ra hiệu suất cơ sở dữ liệu trước khi sản xuất. Trong thực tế, có một vị trí tương đối phổ biến cho loại điều này được gọi là DBA phát triển .

Nhưng...

Một số đưa quá xa và điên cuồng thêm các chỉ mục "chỉ trong trường hợp". Ai đó khuyên đây là một chỉ số còn thiếu? Thêm nó, và bốn biến thể khác. Cũng là một ý tưởng tồi. Bạn không chỉ cần suy nghĩ về việc truy xuất dữ liệu của mình, mà còn sửa đổi dữ liệu thì sao? Bạn càng có nhiều chỉ mục trên một bảng, nói chung bạn càng có nhiều chi phí khi bạn sửa đổi dữ liệu.

Giống như hầu hết mọi thứ, có một sự cân bằng lành mạnh.

Như một lưu ý nhỏ thú vị ... Số nhiều của "Index"

"Chỉ số" dành cho dân tài chính

"Chỉ mục" là dành cho chúng tôi

Không, nó không phải là tối ưu hóa sớm, nhưng nó phải được thực hiện chính xác như bất kỳ tối ưu hóa nào.

Đây là những gì tôi sẽ làm:

1. Tải cơ sở dữ liệu với đủ dữ liệu thử nghiệm để bắt chước tải sản xuất. Bạn không thể có được chính xác 100% này nhưng điều đó vẫn ổn: chỉ cần đặt đủ dữ liệu vào. Một bảng có một lượng dữ liệu cố định không? Tải nó lên. Bạn có một bảng chứa nhiều dữ liệu không, ví dụ như bảng nào có câu hỏi trên trang web này? Tải một vài triệu bản ghi ngay cả khi chỉ là dữ liệu giả.
2. Bật hồ sơ trong máy chủ cơ sở dữ liệu của bạn.
3. Bỏ qua ứng dụng bằng cách sử dụng kết hợp các tập lệnh tự động (cung cấp âm lượng) và người dùng thực (họ biết cách phá vỡ mọi thứ).
4. Xem lại dữ liệu hồ sơ. Là truy vấn cụ thể chậm? Kiểm tra các kế hoạch giải thích và xem nếu máy chủ cơ sở dữ liệu cho bạn biết nó muốn có một chỉ mục nhưng nó không tồn tại.

Máy chủ cơ sở dữ liệu là những phần mềm phức tạp và thông minh. Họ có thể cho bạn biết cách tối ưu hóa chúng nếu bạn biết cách lắng nghe.

Các chìa khóa là để đo hiệu suất trước và sau khi tối ưu hóa và để cơ sở dữ liệu cho bạn biết những gì nó cần .

Theo các mẫu đã được chứng minh cho các vấn đề đã biết (như tìm bản ghi bằng ID của nó) không phải là bất cứ điều gì sớm. Nó chỉ hợp lý.

Điều đó nói rằng, các chỉ mục không phải luôn luôn là một doanh nghiệp đơn giản. Thật khó để biết trong giai đoạn thiết kế, chỉ số lưu lượng truy cập của bạn sẽ phụ thuộc vào và điều gì sẽ làm tắc nghẽn hoạt động ghi. Vì vậy, tôi tranh luận về việc tận dụng một số thực tiễn tốt nhất về thiết kế lược đồ "rõ ràng" (sử dụng PK phù hợp với các mẫu đọc / ghi và chỉ số FK được thiết kế); nhưng, đừng đặt chỉ số lên bất cứ điều gì khác cho đến khi bài kiểm tra căng thẳng của bạn yêu cầu.

Khi ứng dụng của bạn được phát hành, đã quá muộn.

Nhưng bất kỳ quá trình phát triển thích hợp nên bao gồm kiểm tra hiệu suất.

Sử dụng kết quả của các bài kiểm tra hiệu suất của bạn để quyết định nên thêm chỉ mục nào và xác minh tính hiệu quả của chúng bằng cách lặp lại các bài kiểm tra hiệu suất.

Mặc dù tôi không nghĩ mọi truy vấn nên được tối ưu hóa, các chỉ mục là một phần của RDBMS mà chúng cần được xem xét trước khi phát hành. Khi bạn thực hiện một truy vấn, không giống như các hình thức lập trình khác, bạn không nói cho hệ thống biết cách thực hiện nó. Họ phát triển các kế hoạch riêng và hầu như luôn dựa trên cơ sở sẵn có của một chỉ mục. Trang điểm và khối lượng dữ liệu sẽ được xem xét là tốt ở những lần sau.

Dưới đây là một số điều tôi sẽ xem xét:

1. Có một số truy vấn mà bạn nên xác định trong quá trình phát triển ban đầu mà bạn chỉ biết sẽ được sử dụng thường xuyên. Tập trung vào họ.
2. Sẽ có truy vấn chậm. Bằng cách lập chỉ mục cho chúng trước, sau đó bạn có thể xác định xem hiệu suất có còn đủ nhanh hay không và sau đó xem xét thiết kế lại (Việc không chuẩn hóa có thể là sớm). Tôi muốn làm điều này trước khi phát hành. Không ai muốn một hệ thống mà phải mất 10 phút để tìm thứ gì đó trong kho.
3. Các chỉ mục có thể cải thiện hiệu năng truy vấn nhưng chúng không cản trở việc sửa đổi dữ liệu.
4. Nhiều hệ thống có các công cụ để phân tích các truy vấn của bạn, vì vậy đừng ngại sử dụng chúng.

Sau khi xem xét ban đầu, bạn nên theo dõi nó với một số cân nhắc khi nào bạn nên xem lại điều này và làm thế nào bạn có thể thu thập thông tin để thực hiện việc này (theo dõi việc sử dụng, nhận bản sao dữ liệu khách hàng, v.v.).

Tôi nhận ra rằng bạn không muốn tối ưu hóa sớm, nhưng gần như chắc chắn bạn sẽ có hiệu suất kém mà không lập chỉ mục cơ sở dữ liệu của mình. Bằng cách giải quyết vấn đề này, bạn có thể xác định liệu có các lĩnh vực khác gây ra vấn đề về hiệu suất hay không.

Nó cũng phụ thuộc vào số lượng người dùng mà bạn mong đợi. Bạn chắc chắn nên thực hiện một số thử nghiệm tải và đảm bảo cơ sở dữ liệu của bạn có thể theo kịp từ 10 đến 100 đến 1000 yêu cầu đồng thời. Một lần nữa, nó phụ thuộc vào lượng lưu lượng truy cập bạn mong đợi và khu vực bạn mong đợi sẽ được sử dụng nhiều hơn các khu vực khác.

Nói chung, tôi sẽ tinh chỉnh các khu vực mà tôi mong đợi người dùng sẽ đạt được nhiều nhất. Sau đó, tôi sẽ tinh chỉnh bất cứ điều gì chậm từ quan điểm trải nghiệm người dùng. Bất cứ khi nào người dùng phải chờ đợi một cái gì đó, họ sẽ có trải nghiệm tồi tệ và có thể bị từ chối. Không tốt!

Đó là một thực tiễn tốt để xác định cột nào chắc chắn cần một chỉ số bằng một số phân tích trả trước. Có nguy cơ thực sự về sự suy giảm hiệu suất dần dần hoặc bất ngờ trong sản xuất khi kích thước cơ sở dữ liệu tăng lên nếu bạn hoàn toàn không có chỉ số. Tình huống bạn muốn tránh là khi một truy vấn thường chạy yêu cầu quét một số lượng lớn các hàng của bảng. Không phải là tối ưu hóa sớm để thêm các chỉ số vào các cột quan trọng vì bạn có nhiều thông tin cần thiết có sẵn và sự khác biệt hiệu suất tiềm năng là đáng kể (thứ tự cường độ). Cũng có những tình huống mà lợi ích của các chỉ số ít rõ ràng hơn hoặc phụ thuộc nhiều hơn vào dữ liệu - bạn có thể có thể trì hoãn quyết định cho một số trường hợp này.

Một số câu hỏi bạn cần hỏi là:

• Giới hạn thiết kế cho kích thước của mỗi bảng sẽ là gì?

Nếu các bảng luôn luôn nhỏ (giả sử <100 hàng), đó không phải là thảm họa nếu cơ sở dữ liệu phải quét toàn bộ bảng. Có thể có ích khi thêm một chỉ mục, nhưng điều này đòi hỏi một chút chuyên môn hoặc đo lường để xác định.

• Tần suất mỗi truy vấn sẽ được chạy và thời gian phản hồi cần thiết là bao nhiêu?

Nếu truy vấn được chạy không thường xuyên và không có yêu cầu nghiêm ngặt về thời gian phản hồi (ví dụ: tạo báo cáo) và số lượng hàng không lớn, thì có lẽ khá an toàn để trì hoãn thêm chỉ mục. Một lần nữa, chuyên môn hoặc đo lường có thể giúp cho biết nếu nó sẽ có lợi.

• Có phải truy vấn yêu cầu tra cứu bảng bằng một cái gì đó ngoài khóa chính? Ví dụ: lọc theo phạm vi ngày, tham gia khóa ngoại?

Nếu các truy vấn này được chạy thường xuyên và chạm vào các bảng có nhiều hàng, thì bạn nên nghiêm túc xem xét việc thêm một chỉ mục. Nếu bạn không chắc chắn liệu đây có phải là trường hợp của một truy vấn hay không, bạn có thể điền vào cơ sở dữ liệu một lượng dữ liệu thực tế, sau đó xem xét kế hoạch truy vấn.