Đâ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ư   ” nhưng nó kém hấp dẫn hơn, phải không? “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  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:    : 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.) Giá của ví dụ    : 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. Chi phí lưu trữ và lưu trữ dự phòng    : AWS sẽ lập hóa đơn từ   đến   (tùy thuộc vào khu vực của ví dụ)  Phần khó khăn là cơ sở dữ liệu I / O 0,20 đô la 0,30 đô la 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ó 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. Các truy vấn sử dụng chỉ mục   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.  🧠   : í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. Đầu tiên, hãy nhớ điều này  ❌   : 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.   🤌, 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:  Loại bỏ các chỉ mục không sử dụng 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  Truy vấn thống kê chỉ mục  Truy vấn sẽ xuất ra trường   ứ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. ops  🧐   : nếu bạn sử dụng RDS, bạn có thể biế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   , 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   . 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ị! Kích hoạt   và  thông tin chi tiết về hiệu suất hoạt động lập hồ sơ thông tin chi tiết về hiệu suất động Hồ sơ n ms  💾 Trước hết   : 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 :) hãy xem dữ liệu của bạn  🫠   : 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 các bộ sưu tập nhỏ phức tạp  ⏱️   : (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. Tránh TTL, hay còn gọi là chỉ mục thời gian rời khỏi  💡   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à   hiện thao tác   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… Giải thích! executionStats giải thích  ☯️   . Đừng. Ghi cardinality. Không tạo chỉ mục cho trường boolean  ⚖️   cho mỗi bộ sưu tập mà bạn có bằng lệnh này:   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. Theo dõi kích thước trung bình của một đối tượng db.<mycollection>.stats(1024)  ⚠️   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ử   , 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! Hãy lưu ý rằng DocumentDB không phải là MongoDB. $regex  👉   . 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   , 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. Không bao giờ gợi ý hint  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

Amazon

Read My Stories

Buy Me a Coffee

Software Engineer/AWS Architect

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

Tôi đã khiến AWS mất tiền - Đây là cách!

About Author

BÌNH LUẬN

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI

Related Stories

179 Stories To Learn About Reading

309 Stories To Learn About Smart Contracts

189 Stories To Learn About Reading Books

184 Stories To Learn About Psychology

179 Stories To Learn About Reading

309 Stories To Learn About Smart Contracts

189 Stories To Learn About Reading Books

184 Stories To Learn About Psychology

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps