Lưu trữ bảng Azure - Tôi có thể quét bảng nhanh như thế nào?

Question

Mọi người cảnh báo không truy vấn bất kỳ điều gì khác ngoài RowKey hoặc PartitionKey trong Bộ nhớ bảng Azure (ATS), vì sợ rằng bạn bị buộc phải quét bảng. Trong một thời gian, điều này đã làm tê liệt tôi để cố gắng tìm ra chính xác PK và RK phù hợp và tạo các chỉ mục giả ở các bảng khác khi tôi cần truy vấn cái gì khác.

Tuy nhiên, nó xảy ra với tôi rằng tôi thường quét bảng trong SQL Server khi tôi nghĩ thích hợp.

Vì vậy, câu hỏi trở nên, tôi có thể quét bảng Azure nhanh như thế nào. Đây có phải là hằng số trong thực thể/giây hay không phụ thuộc vào kích thước bản ghi, v.v. Có một số quy tắc chung về số lượng bản ghi quá nhiều để quét bảng nếu bạn muốn ứng dụng đáp ứng không?

Answer 1

Vấn đề quét bảng phải làm với việc vượt qua ranh giới phân vùng. Mức độ hiệu suất mà bạn được đảm bảo là mức độ giải thích được đặt ở cấp phân vùng. do đó, khi bạn chạy quét toàn bộ bảng, a) không hiệu quả lắm, b) không có bất kỳ đảm bảo nào về hiệu suất. Điều này là do các phân vùng tự được thiết lập trên các nút lưu trữ riêng biệt, và khi bạn chạy quét phân vùng chéo, bạn đang tiêu tốn một lượng lớn tài nguyên tiềm năng (kết hợp nhiều nút đồng thời).

Tôi tin rằng, hiệu quả của việc vượt qua các ranh giới này cũng dẫn đến các mã thông báo tiếp tục, yêu cầu thêm các chuyến đi khứ hồi để lưu trữ để truy xuất kết quả. Kết quả này sau đó trong việc giảm hiệu suất, cũng như tăng số lượng giao dịch (và sau đó là chi phí).

Nếu số lượng phân vùng/nút bạn đang chuyển là khá nhỏ, có thể bạn sẽ không nhận thấy bất kỳ sự cố nào.

Nhưng xin đừng báo cho tôi về điều này. Tôi không phải là chuyên gia về Azure Storage. Nó thực sự là khu vực của Azure Tôi là người có kiến ​​thức ít nhất. : P

Answer 2

Tôi nghĩ Brent là 100% trên tiền, nhưng nếu bạn vẫn cảm thấy bạn muốn thử nó, tôi chỉ có thể đề nghị để chạy một số xét nghiệm để tìm ra chính mình. Hãy thử bao gồm các phân vùngKey trong các truy vấn của bạn để ngăn chặn phân vùng qua bởi vì vào cuối ngày đó là kẻ giết người thực hiện.

Answer 3

Bảng Azure không được tối ưu hóa để quét bảng. Việc quét bảng có thể được chấp nhận cho một công việc nền chạy dài, nhưng tôi sẽ không thực hiện khi cần phản hồi nhanh. Với một bảng có kích thước hợp lý, bạn sẽ phải xử lý các thẻ tiếp tục khi truy vấn đạt đến một ranh giới phân vùng hoặc thu được kết quả 1k.

Nhóm lưu trữ Azure có great post which explains the scalability targets. Mục tiêu thông lượng cho một phân vùng bảng đơn là 500 thực thể/giây. Mục tiêu tổng thể cho một tài khoản lưu trữ là 5.000 giao dịch/giây.

Answer 4

Câu trả lời là Phân trang. Sử dụng số top_size - số lượng kết quả hoặc bản ghi tối đa - kết hợp với next_partition_key và next_row_key mã thông báo tiếp tục. Điều đó tạo nên sự khác biệt đáng kể về hiệu suất. Đối với một, kết quả của bạn có nhiều khả năng đến từ một phân vùng duy nhất. Kết quả đơn giản cho thấy các tập hợp được nhóm theo khóa tiếp tục phân vùng và không phải là hàng tiếp tục.

Nói cách khác, bạn cũng cần suy nghĩ về giao diện người dùng hoặc hệ thống của mình. Đừng lo lắng trả lại hơn 10 đến 20 kết quả tối đa 50. Người dùng có thể sẽ không sử dụng hoặc kiểm tra nữa.

Nghe ngu ngốc. Thực hiện tìm kiếm Google cho "chó" và nhận thấy rằng tìm kiếm chỉ trả về 10 mục. Không còn nữa. Các hồ sơ tiếp theo là avail cho bạn nếu bạn bận tâm để nhấn 'tiếp tục'. Nghiên cứu đã chứng minh rằng hầu như không có người dùng nào mạo hiểm vượt ra ngoài trang đầu tiên đó.

số select (trả lại tập con của khóa-giá trị) có thể tạo sự khác biệt; ví dụ: sử dụng select = "PartitionKey,RowKey" hoặc 'Name' bất kỳ mức tối thiểu nào bạn cần.

"Tôi tin rằng, rằng tác động của qua những ranh giới cũng dẫn đến trong thẻ tiếp tục, đòi hỏi thêm tròn-chuyến đi đến lưu trữ để lấy kết quả. Điều này dẫn đến sau đó trong việc giảm hiệu suất, cũng như một tăng số lượng giao dịch (và sau đó chi phí). "

... hơi sai. mã thông báo tiếp tục được sử dụng không phải vì vượt qua các ranh giới nhưng vì các bảng xanh cho phép không quá 1000 kết quả; do đó hai thẻ tiếp tục được sử dụng cho tập tiếp theo. mặc định top_size về cơ bản là 1000.

Để xem niềm vui của bạn, đây là mô tả cho các đối tượng truy vấn từ api trăn xanh. những người khác thì giống nhau.

''' 
    Get entities in a table; includes the $filter and $select options. 

    table_name: Table to query. 
    filter: 
    Optional. Filter as described at 
    http://msdn.microsoft.com/en-us/library/windowsazure/dd894031.aspx 
    select: Optional. Property names to select from the entities. 
    top: Optional. Maximum number of entities to return. 
    next_partition_key: 
    Optional. When top is used, the next partition key is stored in 
    result.x_ms_continuation['NextPartitionKey'] 
    next_row_key: 
    Optional. When top is used, the next partition key is stored in 
    result.x_ms_continuation['NextRowKey'] 
    '''