Hiệu suất - Dịch vụ bảng, SQL Azure - chèn. Tốc độ truy vấn trên số lượng lớn dữ liệu

Question

Tôi đã đọc nhiều bài đăng và bài viết về so sánh SQL Azure và Dịch vụ bảng và hầu hết trong số họ đã nói rằng Dịch vụ bảng có khả năng mở rộng hơn SQL Azure.

• http://www.silverlight-travel.com/blog/2010/03/31/azure-table-storage-sql-azure/
• http://www.intertech.com/Blog/post/Windows-Azure-Table-Storage-vs-Windows-SQL-Azure.aspx
• Microsoft Azure Storage vs. Azure SQL Database
• https://social.msdn.microsoft.com/Forums/en-US/windowsazure/thread/2fd79cf3-ebbb-48a2-be66-542e21c2bb4d
• https://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx
• https://stackoverflow.com/questions/2711868/azure-performance
• http://vermorel.com/journal/2009/9/17/table-storage-or-the-100x-cost-factor.html
• Azure Tables or SQL Azure?
• http://www.brentozar.com/archive/2010/01/sql-azure-frequently-asked-questions/
• https://code.google.com/p/lokad-cloud/wiki/FatEntities

Xin lỗi vì http, tôi là người dùng mới> _ < Nhưng http://azurescope.cloudapp.net/BenchmarkTestCases/ benchmark cho thấy bức tranh khác.

Trường hợp của tôi. Sử dụng SQL Azure: một bảng có nhiều lần chèn, khoảng 172.000.000 mỗi ngày (2000 mỗi giây). Tôi có thể mong đợi hiệu quả tốt cho việc chèn và chọn khi tôi có 2 triệu bản ghi hay 9999 .... 9 tỷ bản ghi trong một bảng?

Sử dụng dịch vụ bảng: một bảng có một số phân vùng. Số lượng phân vùng có thể lớn, rất lớn.

Câu hỏi # 1: Dịch vụ bảng có một số hạn chế hoặc thực tiễn tốt nhất để tạo nhiều, nhiều, nhiều phân vùng trong một bảng không?

Câu hỏi # 2: trong một phân vùng duy nhất Tôi có một số lượng lớn các thực thể nhỏ, như trong ví dụ SQL Azure ở trên. Tôi có thể mong đợi sự thuận lợi tốt cho việc chèn và chọn khi tôi có 2 triệu bản ghi hay 9999 tỷ thực thể trong một phân vùng không?

Tôi biết về các giải pháp phân vùng hoặc phân vùng, nhưng nó là một dịch vụ đám mây, là đám mây không mạnh mẽ và làm tất cả mà không có kỹ năng mã của tôi?

Câu hỏi # 3: Ai có thể chỉ cho tôi điểm chuẩn để kiểm tra số lượng lớn dữ liệu cho SQL Azure và Dịch vụ bảng không?

Câu hỏi # 4: Có thể bạn có thể đề xuất giải pháp tốt hơn cho trường hợp của tôi.

Answer 1

ngắn trả lời

1. Tôi đã không nhìn thấy rất nhiều phân vùng gây Bàn Azure (AZT) vấn đề, nhưng tôi không có khối lượng dữ liệu này.
2. Các mặt hàng hơn trong một phân vùng, các truy vấn chậm hơn trong phân vùng đó
3. Xin lỗi không có, tôi không có tiêu chuẩn
4. Xem dưới đây

dài trả lời

Trong của bạn trường hợp tôi nghi ngờ rằng SQL Azure không phải là đi làm việc cho bạn, đơn giản chỉ vì các giới hạn về kích thước của một cơ sở dữ liệu SQL Azure. Nếu mỗi hàng bạn đang chèn là 1K với chỉ mục, bạn sẽ đạt đến giới hạn 50 GB trong khoảng 300 ngày. Đúng là Microsoft đang nói về cơ sở dữ liệu lớn hơn 50GB, nhưng họ không có khung thời gian trên đó. SQL Azure cũng có một giới hạn thông lượng mà tôi không thể tìm thấy tại thời điểm này (tôi khá chắc chắn nó ít hơn những gì bạn cần mặc dù). Bạn có thể có được xung quanh điều này bằng cách phân vùng dữ liệu của bạn trên nhiều cơ sở dữ liệu SQL Azure.

Lợi thế mà SQL Azure có mặc dù là khả năng chạy truy vấn tổng hợp. Trong AZT, bạn thậm chí không thể viết select count(*) from customer mà không cần tải từng khách hàng.

AZT cũng có giới hạn 500 giao dịch mỗi giây trên mỗi phân đoạn và giới hạn là "several thousand" per second per account.

Tôi nhận thấy rằng việc chọn những gì để sử dụng cho khóa phân vùng (PK) và khóa hàng phụ thuộc (RK) vào cách bạn truy vấn dữ liệu. Nếu bạn muốn truy cập từng mục riêng lẻ, chỉ cần cung cấp cho mỗi hàng đó là khóa phân vùng riêng và một khóa hàng không đổi. Điều này có nghĩa là bạn có nhiều phân vùng.

Ví dụ: nếu các hàng bạn chèn là các đơn đặt hàng và đơn đặt hàng thuộc về khách hàng. Nếu bạn thường xuyên liệt kê các đơn đặt hàng của khách hàng, bạn sẽ có PK = CustomerId, RK = OrderId. Điều này có nghĩa là để tìm đơn đặt hàng cho một khách hàng bạn chỉ cần truy vấn trên khóa phân vùng. Để có được một đơn đặt hàng cụ thể, bạn cần biết CustomerId và OrderId. Càng có nhiều đơn đặt hàng mà khách hàng đã có, việc tìm kiếm chậm hơn bất kỳ thứ tự cụ thể nào sẽ là.

Nếu bạn chỉ cần truy cập các đơn hàng chỉ bằng OrderId, thì bạn sẽ sử dụng PK = OrderId, RK = string.Empty và đặt CustomerId vào một thuộc tính khác. Mặc dù bạn vẫn có thể viết truy vấn trả về tất cả các đơn đặt hàng cho khách hàng, vì AZT không hỗ trợ các chỉ mục ngoài PartitionKey và RowKey nếu truy vấn của bạn không sử dụng PartitionKey (và đôi khi thậm chí tùy thuộc vào cách bạn viết chúng) sẽ gây ra việc quét bảng. Với số lượng hồ sơ bạn đang nói về điều đó sẽ rất xấu.

Trong tất cả các trường hợp tôi gặp phải, có rất nhiều phân vùng dường như không lo lắng quá nhiều về AZT.

Một cách khác bạn có thể phân vùng dữ liệu của mình trong AZT thường không được đề cập là đặt dữ liệu vào các bảng khác nhau. Ví dụ: bạn có thể muốn tạo một bảng cho mỗi ngày. Nếu bạn muốn chạy truy vấn cho tuần trước, hãy chạy cùng một truy vấn đối với 7 bảng khác nhau. Nếu bạn chuẩn bị thực hiện một chút công việc trên đầu máy khách, bạn thậm chí có thể chạy chúng song song.