2010-08-06 38 views
21

Tôi thấy rằng có một câu hỏi tương tự được hỏi vài tháng trước, nhưng nó thực sự không giải quyết tốt tình huống của tôi. Ở đây nó đi ...Lưu trữ Microsoft Azure so với Cơ sở dữ liệu SQL Azure

Tôi đang trong quá trình xây dựng từ đầu dựa trên web, ứng dụng .NET có tiềm năng trở thành trang web có khối lượng lớn (vài trăm nghìn lần xem trang mỗi tháng để bắt đầu) và tôi đang cân nhắc việc sử dụng Microsoft Azure để lưu trữ nó. Tôi chưa xây dựng gì và vẫn đang nghiên cứu các lựa chọn khác nhau của mình.

Bản thân ứng dụng là một ứng dụng CRUD tiêu chuẩn hoạt động dựa trên một số loại thực thể khác nhau (ví dụ: người dùng, đơn đặt hàng, mục, v.v.). Có thể một số quy trình nền có thể đang chạy và một số dữ liệu xếp hàng (ví dụ như cập nhật không theo thời gian thực - chẳng hạn như nhận huy hiệu SO), nhưng hầu hết các tương tác với người dùng sẽ là loại hành động CRUD điển hình của bạn.

Về Azure, tôi đã đọc một số bài viết về cách sử dụng Microsoft Azure lưu trữ để lưu trữ dữ liệu giao dịch và đang cân nhắc việc thực hiện thay vì sử dụng Azure SQL DB. Tuy nhiên, tôi đã không nhìn thấy hoặc đọc một số câu chuyện thành công của những người thực sự và/hoặc các công ty thực sự làm điều đó. Vì vậy, tôi nghĩ tôi sẽ liên hệ với cộng đồng SO để xem liệu có ai có kinh nghiệm sử dụng Microsoft Azure Storage không, bạn đã có loại may mắn nào, bất kỳ gotchas nào tôi nên tìm và bất kỳ phương pháp hay nhất nào mà bạn đã đi lên với.

Tôi đã đọc qua rất nhiều phần Microsoft Azure MSDN và lập trình Microsoft Azure Bảng API tài liệu từ Microsoft. Tôi đang tìm lời khuyên thiết thực, bài học kinh nghiệm, thực hành tốt nhất, vv Cảm ơn bạn trước!

Trả lời

13

Bộ nhớ Windows Azure giống như bất kỳ bộ nhớ NoSQL nào. Nó hoạt động trong các kịch bản có quy mô cao for us (bơm hàng triệu bản ghi cho mỗi người dùng). Tuy nhiên, phương pháp CRUD cổ điển là một chút khó khăn để mở rộng hoặc thích ứng với điều này.

Tôi khuyên bạn nên bắt đầu tìm kiếm dọc theo CQRS style of architectures. Dưới đây là một số tài liệu tham khảo có thể giúp bạn bắt đầu:

+2

Cảm ơn thông tin. Tôi đã nhanh chóng quét qua một số thông tin bạn đã cung cấp (tôi sẽ xem xét kỹ hơn vào cuối tuần này). Một câu hỏi - với các dự án/sản phẩm bạn đã làm việc trên, bạn đã sử dụng SQL Azure kết hợp với Azure lưu trữ, hoặc bạn chỉ cần sử dụng Azure lưu trữ? Dường như một số tài liệu bạn đã liên kết để hiển thị SQL Azure đang được sử dụng với Azure Storage. Nếu bạn sử dụng SQL Azure, được sử dụng cho phía bên của CQRS và sau đó chuyển sang lưu trữ Azure? Cảm ơn một lần nữa. –

+0

Đây là một số thông tin tốt và giúp tôi chỉ đúng hướng. Cảm ơn! –

+0

Chúng tôi đang sử dụng SQL Azure với Azure lưu trữ ở phía bên. SQL Azure cho dữ liệu quan hệ, lưu trữ Azure cho các đốm màu, hàng đợi và dữ liệu xem. Về mặt lý thuyết SQL Azure có thể được thay thế bằng sự kiện tìm nguồn cung ứng, nhưng chúng tôi chưa đến đó. –

1

Bạn cũng nên kiểm tra mô hình sử dụng dữ liệu của bạn trước khi quyết định sử dụng Azure Lưu trữ hoặc lưu trữ SQL. Vì Azure Storage cung cấp các giải pháp NoSQL, chúng hướng đến các yêu cầu cơ sở không báo cáo. Ở đây báo cáo không có nghĩa là báo cáo nhưng nó ngụ ý rằng khả năng truy vấn của bộ nhớ Azure bị giới hạn \ không tối ưu hóa cho các kịch bản truy vấn khác nhau. Với kiến ​​trúc CQRS các hoạt động CRUD và báo cáo được tách riêng và do đó một kết hợp n kết hợp của cả Azure lưu trữ và Azure SQL có thể được thực hiện.

+0

Cảm ơn. Điều này cũng giúp ích. Tôi đã xem xét việc sử dụng một hỗn hợp và kết hợp giữa lưu trữ bảng và Azure sql. Tôi không chắc chắn bao nhiêu để giữ trong sql azure - có kinh nghiệm của bạn về cơ bản đã có một bản sao của dữ liệu giữa Azure squre và lưu trữ azure? –

+0

Nó không phải là về bao nhiêu để giữ ở đâu. Ví dụ: nếu bạn đang triển khai kịch bản Xác thực người dùng \ Ủy quyền, tất cả mẫu truy cập dữ liệu sẽ xoay quanh một người dùng cụ thể và NoSQL hoạt động tốt nhất ở đây. Nhưng trong cùng một điều nếu chúng ta muốn một giao diện quản trị để quản lý người dùng, trong đó bao gồm hiển thị danh sách người dùng, bộ lọc, vv là phù hợp nhất cho định dạng quan hệ dữ liệu. Trong trường hợp này, bạn sẽ giữ bản sao dữ liệu người dùng trùng lặp trong cả hai kho lưu trữ NoSQL và SQL nhưng chỉ tin tưởng vào db NoSQL để thực hiện bất kỳ xác thực nghiệp vụ nào.Chúng tôi sẽ cần một số cơ chế để đồng bộ hóa kho dữ liệu người dùng (Một chiều) – Chandermani

+0

Do đó bạn cần phải suy nghĩ xem sự phức tạp này có được bảo đảm cho ứng dụng của bạn hay không. – Chandermani

1

Một nơi khác để tìm thông tin là bước ra ngoài tùy chọn Windows Azure và xem AWS. S3 & Các tùy chọn SimpleDB đã được xem xét trong một thời gian dài và có nhiều câu chuyện thành công bổ sung trên mạng. Tuy nhiên, S3 & SimpleDB rất giống với chức năng của Bảng lưu trữ Windows Azure và Lưu trữ Blob. Nếu bạn đang suy nghĩ về dữ liệu thực sự lớn, mà các cấu trúc này cho, chắc chắn kiểm tra các tùy chọn AWS. Nếu chỉ cho một điểm tham chiếu về các giải pháp hiện có được xây dựng xung quanh dữ liệu lớn.

Đối với SQL Azure, nó là rất tốt cho nhiều giao dịch, giữ chi phí giao dịch thấp và duy trì các mối quan hệ và tính toàn vẹn chung dựa trên dữ liệu quan hệ.Tuy nhiên, nếu bạn sẽ có khối lượng dữ liệu khổng lồ, chỉ cần tiếp tục và nhắm đến các cấu trúc dữ liệu lớn, chẳng hạn như Windows Azure Table hoặc SimpleDB của Amazon.

+0

cảm ơn lời khuyên. Tôi sẽ kiểm tra! –

8

Phụ thuộc vào loại dữ liệu bạn đang nói đến - thường có khuynh hướng đánh giá quá cao các yêu cầu dữ liệu giao dịch. Rất nhiều dữ liệu thực sự có thể phù hợp với 1 GB SQL Azure (chúng tôi là nhà cung cấp SAAS và dữ liệu giao dịch của gần 20 khách hàng có thể phù hợp với nhiều không gian đó). Ngoài ra, vì một số lý do lạ, tôi đã thấy rằng tiêu thụ không gian SQL Azure dường như hơi nhỏ hơn kích thước của cơ sở dữ liệu tôi thấy tại chỗ (có thể phải làm với cách họ xử lý nhật ký, không chắc chắn). Và bây giờ 50 GB là giới hạn, khá thẳng thắn, HUGE. Tuy nhiên, bạn cũng cần cân nhắc điều gì làm tăng việc sử dụng không gian - lưu trữ hình ảnh, video hoặc các đối tượng lớn khác trong cơ sở dữ liệu có thể tạo ra sự gia tăng đáng kể về mức tiêu thụ không gian. Nó là tốt hơn để giữ các loại đối tượng trong Windows Azure.

Vì vậy, câu trả lời ngắn - giữ dữ liệu giao dịch trong SQL Azure và dữ liệu không quan hệ trong Windows Azure. Làm việc với SQL Azure cũng sẽ giữ cho các nhà phát triển của bạn hiệu quả hơn, vì nó khá quen thuộc về mặt lập trình. Xử lý Windows Azure tương tự như cách bạn sẽ xử lý các cửa sổ lưu trữ tệp cục bộ với một số lợi ích bổ sung (cấu trúc bảng cơ bản được hỗ trợ).

+0

cảm ơn góc nhìn. Khi bạn sử dụng Windows Azure để lưu trữ dữ liệu phi giao dịch, bạn có sử dụng kết hợp bộ nhớ bảng và các đốm màu không? Bạn có sử dụng ổ đĩa không? Cảm ơn! –

+0

Chúng tôi sử dụng hai ổ đĩa đầu tiên là khá mới, chưa tìm thấy một nơi tuyệt vời để sử dụng chúng. Đã bỏ lỡ điều này ở trên, nhưng bảng màu xanh là tuyệt vời để viết nhật ký, đặc biệt là nhật ký sử dụng. Các đốm màu rất tuyệt vời cho hình ảnh, video và các tệp lớn khác Lái xe là khi bạn cần phải có thứ gì đó tương tự như ổ đĩa cứng cục bộ. Tuy nhiên đây là trường hợp cụ thể (có nghĩa là chỉ có một thể hiện có thể ghi vào một ổ đĩa tại một thời điểm) và không giống như lưu trữ azure có thể được truy cập bởi nhiều trường hợp cùng một lúc. –

+0

xin, hãy giúp tôi http://stackoverflow.com/questions/14156980/error-when-try-to-save-in-windows-azure-table – Ladessa

4

Một điều cần xem xét là số lượng giao dịch mà bạn sẽ gửi/nhận từ cửa hàng. Phần tốt đẹp về SQL Azure là nó là một chi phí cố định/tháng và nếu bạn đang làm các truy vấn trong cùng một trung tâm dữ liệu (tức là từ một vai trò Windows Azure Web nằm trong cùng một trung tâm dữ liệu như cơ sở dữ liệu SQL Azure của bạn) thì có không tính thêm phí.

Mặc dù chi phí giao dịch cho các cửa hàng Windows Azure khá thấp, nhưng đó là thứ có tiềm năng tăng thêm nếu bạn thực hiện đủ.

+0

xin hãy giúp tôi http://stackoverflow.com/questions/14156980/error-when-try-to-save-in-windows-azure-table – Ladessa

Các vấn đề liên quan