Đây là một loạt bài ngắn mà tôi đã muốn chia sẻ từ lâu về những kiến thức cơ bản của "Tối ưu hóa chi phí" trên AWS.

Hãy bắt đầu cuộc hành trình này với DocumentDB !

Đừng ngần ngại 👏 nếu bạn thích bài đăng này;)

Được rồi, thành thật mà nói, tiêu đề này là một cú nhấp chuột *. *

Tôi chắc chắn có thể viết một cái gì đó như “cách tôi thực hiện tối ưu hóa chi phí trên cơ sở hạ tầng AWS của chúng tôi bằng cách tôn trọng một số nguyên tắc chung được cung cấp trong tài liệu ” nhưng nó kém hấp dẫn hơn, phải không?

Có thể một số bạn đã biết những thủ thuật và cách làm hay này.

Nếu bạn đang tìm kiếm thẳng danh sách kiểm tra mà tôi đang đề xuất, hãy cuộn vào đây.

Hiểu chi phí I / O phức tạp từ dịch vụ DocumentDB

Nếu bạn nhìn vào trang giá của họ, nó được chia cho 4 thứ nguyên chi phí, tôi tiếp tục nó ở đây:

• Giá của ví dụ : chi phí này rất dễ hiểu: bạn phải trả cho một phiên bản và việc định giá sẽ phụ thuộc vào tài nguyên của nó (CPU, RAM, v.v.)
• Chi phí lưu trữ và lưu trữ dự phòng : tương tự như trên, khá dễ hiểu và chúng tôi có thể theo dõi và ước tính dễ dàng chi phí của chúng, hóa đơn AWS trên mỗi GB được lưu trữ. Hợp pháp.
• Phần khó khăn là cơ sở dữ liệu I / O : AWS sẽ lập hóa đơn từ 0,20 đô la đến 0,30 đô la (tùy thuộc vào khu vực của ví dụ) cho mỗi 1 triệu I / O !!

Vậy, điều gì đằng sau I / O?

AWS giải thích rằng với dịch vụ DocumentDB, bạn không phải cung cấp trước tài nguyên I / O, điều này khá thú vị, vì bạn không có giới hạn lưu trữ và bạn có thể dễ dàng xử lý một số hoạt động I / O. Nó có vẻ công bằng, vì bạn đang lập hóa đơn cho việc sử dụng.

AWS mô tả trong tài liệu của họ những gì bao gồm các hoạt động I / O, chủ yếu là tất cả các hoạt động như tìm, chèn, cập nhật và xóa hoặc một số tính năng như luồng thay đổi và chỉ mục TTL (thời gian tồn tại).

Tất cả mọi thứ đạt đến dung lượng lưu trữ sẽ được tính phí cho bạn.

Chờ đã, cái gì, 0,20 đô la mỗi triệu I / O?

Hãy làm cho AWS mất tiền, ngay bây giờ!

Có một cụm từ trong tài liệu AWS DocumentDB sẽ bắt mắt bạn (và ví 💸):

Một lần, khi dữ liệu đã được đọc từ ổ đĩa lưu trữ và tiếp tục nằm trong bộ nhớ, các lần đọc tiếp theo của cùng một dữ liệu không phát sinh thêm I / Os.

Cụm từ này là chìa khóa để hiểu những gì đằng sau I / Os.

Thao tác nào sử dụng I / Os ít hơn?

Các truy vấn sử dụng chỉ mục có thể sẽ sử dụng ít I / Os hơn vì bạn không quét tất cả bộ nhớ trong bộ sưu tập của mình. Nó chắc chắn sẽ tiêu thụ I / Os nhưng ít hơn so với việc quét toàn bộ bộ sưu tập.

Hơn nữa, RAM của phiên bản của bạn cần phải bao gồm kích thước chỉ mục của bạn, nó sẽ cho phép bạn không phải chịu thêm I / Os.

Xin lưu ý rằng bạn cần tôn trọng một số nguyên tắc sử dụng chỉ mục.

Danh sách kiểm tra ✅

Đây là lời khuyên / danh sách kiểm tra của tôi khi bạn muốn tối ưu hóa việc sử dụng I / O và giảm chi phí cũng như cải thiện hiệu suất.

Bạn sẽ thấy rằng tôi không phải là một thiên tài vì tôi chỉ tổng hợp thông tin từ trang Tài liệu AWS DocumentDB với một số phương pháp hay nhất phổ biến không hoàn toàn áp dụng cho DocumentDB.

Luôn luôn tốt để làm mới tâm trí của chúng ta bằng các nguyên tắc.

• 🧠 Đầu tiên, hãy nhớ điều này : ít I / O hơn = rẻ hơn = hiệu suất tốt hơn, ở đây không phải là tất cả về chi phí hoặc không phải tất cả về các buổi biểu diễn, mà hai điều có mối liên hệ với nhau.

• ❌ Loại bỏ các chỉ mục không sử dụng : bạn không biết một chỉ số không sử dụng đắt như thế nào đối với một bộ sưu tập bận rộn. Tôi đã khiến công ty của mình tiết kiệm được 2.000 đô la / tháng chỉ như vậy 🤌, bằng cách xóa các chỉ mục không sử dụng. Và rất dễ dàng để theo dõi các chỉ mục không sử dụng với truy vấn này:

  
  

Truy vấn thống kê chỉ mục

Truy vấn sẽ xuất ra trường ops ứng với số lần chỉ mục của bạn được truy cập. Tùy thuộc vào tải ứng dụng của bạn, vui lòng xem xét xóa chỉ mục không sử dụng.

• 🧐 Kích hoạt thông tin chi tiết về hiệu suất và hoạt động lập hồ sơ : nếu bạn sử dụng RDS, bạn có thể biết thông tin chi tiết về hiệu suất , nó cung cấp cho bạn một số chỉ số và thông tin rất hữu ích về các truy vấn đang ảnh hưởng đến hiệu suất DocumentDB của bạn và bạn có thể nhanh chóng xem các truy vấn tiêu tốn I / Os hoạt động (và số lượng của chúng), vì vậy rất tốt để dễ dàng theo dõi một nút cổ chai. Một cách khác để theo dõi các truy vấn chậm hoặc truy vấn quét cuộn là bằng cách kích hoạt hoạt động Hồ sơ , như tên cho thấy nó lập hồ sơ cho bạn một số hoạt động (đây là liên kết để biết thêm thông tin:), bạn có thể đặt ngưỡng sẽ đưa vào CloudWatch nhật ký của một hoạt động mất hơn n ms . Ví dụ: rất hữu ích để theo dõi số lượng truy vấn đang thực hiện COLLSCAN. Vui lòng kích hoạt cả hai tùy chọn này vì chúng rất có giá trị!

  
  

• 💾 Trước hết hãy xem dữ liệu của bạn : bạn sẽ cần xác định trường có bản số cao tốt nhất mà bạn muốn lập chỉ mục, nếu bạn không quen với khái niệm về bản số chỉ mục, tài liệu của AWS DocumentDB được giải thích rõ ràng :)

  
  

• 🫠 Tránh các bộ sưu tập nhỏ phức tạp : nếu bạn dự định có một bộ sưu tập sẽ có ba trường với một trong số chúng có khóa duy nhất và nếu bạn định thực hiện nhiều cập nhật / chèn, vui lòng xem xét mô hình hóa bộ sưu tập của bạn, bởi vì các hoạt động I / O của bạn sẽ trở nên tồi tệ và việc sử dụng I / O của bạn cũng vậy.

  
  

• ⏱️ Tránh TTL, hay còn gọi là chỉ mục thời gian rời khỏi : (hầu hết thời gian) bạn có thể xử lý nó mà không cần đặt chỉ mục thời gian nghỉ, vì vậy hãy kiểm tra xem thông số TTL không được bật trên phiên bản hoặc cụm.

  
  

• 💡 Giải thích! Một cách rất đơn giản để kiểm tra tính chọn lọc chỉ mục của công cụ lập kế hoạch truy vấn khi bạn đang thực hiện một truy vấn mới (hoặc không) là executionStats hiện thao tác giải thích với tham số executeStats. Bạn sẽ ngạc nhiên rằng một số truy vấn mà bạn nghĩ rằng đã đạt được chỉ mục, chỉ là không đạt được bất kỳ chỉ mục nào…

  
  

• ☯️ Không tạo chỉ mục cho trường boolean . Đừng. Ghi cardinality.

  
  

• ⚖️ Theo dõi kích thước trung bình của một đối tượng cho mỗi bộ sưu tập mà bạn có bằng lệnh này: db.<mycollection>.stats(1024) Kích thước trung bình cực cao có thể nhanh chóng tạo ra một khóa cho các truy vấn của bạn và tăng tốc độ I / O do RAM của bạn thể hiện là không đủ. Vui lòng giám sát chặt chẽ các đối tượng và không lưu trữ các trường không cần thiết. Nếu bạn cần lưu trữ nhiều trường, hãy xem xét việc tối ưu hóa các truy vấn bằng cách không chọn tất cả các trường.

  
  

• ⚠️ Hãy lưu ý rằng DocumentDB không phải là MongoDB. Nó chủ yếu tương thích với MongoDB nhưng không phải MongoDB vì có một số hành vi cụ thể tồi tệ. Ví dụ: nếu bạn muốn thực hiện một truy vấn với toán tử $regex , bạn sẽ cần phải `` gợi ý () `bạn đang lập chỉ mục, vì nó là bắt buộc. Các toán tử loại trừ sẽ không bao giờ sử dụng bất kỳ chỉ mục nào, vì vậy hãy xem xét các hành vi này khi tạo hoặc tối ưu hóa chỉ mục của bạn!

  
  

• 👉 Không bao giờ gợi ý . Ngoại trừ các trường hợp sử dụng rất cụ thể được đề cập ở trên, bạn nên tránh sử dụng hint , hãy nhớ rằng nếu công cụ lập kế hoạch truy vấn không chọn chỉ mục của bạn, đó là lý do chính đáng. Hầu hết thời gian là vì nó lâu hơn hoặc tương đương với việc quét chỉ mục thay vì tất cả các tài liệu từ bộ sưu tập.

• 
  

Hy vọng bạn sẽ đánh giá cao những thủ thuật mà tôi đã học được khi làm việc về Tối ưu hóa chi phí AWS cho công ty của tôi.

Hãy theo dõi bài viết khác!

Đừng ngần ngại 👏 nếu bạn thích bài đăng này;)

Tái bút: nếu có điều gì đó có vẻ không ổn hoặc hiểu lầm, đừng ngần ngại DM cho tôi.

Cũng được xuất bản tại đây