Có nên sử dụng SQL Server làm cơ sở dữ liệu cho các ứng dụng có khả năng mở rộng quy mô không?

Giả sử bạn đang dự định tạo một trang web có quy mô của Facebook (Nếu tôi sẽ trích dẫn tên của một trang web thì tại sao không phải là Facebook?!). Có nên sử dụng SQL Server làm cơ sở dữ liệu của bạn cho các ứng dụng đó không?

Tôi hỏi câu hỏi này vì nhiều đồng nghiệp của tôi nói rằng máy chủ SQL không nên được sử dụng các ứng dụng như vậy. Họ thích Oracle hoặc MySQL hơn.

Có , SQL Server đã được thiết kế để sử dụng nhiều bao gồm cả web. Nó có khả năng được đặt trong nhiều cấu hình khác nhau, chẳng hạn như các thể hiện bộ nhớ được kết hợp với các thể hiện cpu và SAN làm bộ lưu trữ.

Hỏi nhà tích hợp Microsoft hoặc nhà truyền giáo địa phương của bạn cho lời khuyên.

Bạn có thể tìm thấy nhiều tài nguyên liên quan đến khả năng mở rộng của SQL Server trên web và vì đây là một bài đăng blog hay từ nhóm SQL Server về chủ đề này: http://blogs.msdn.com/b/sqlcat/archive/ 2008/06/12 / sql-server-scale-out.aspx

Hãy chắc chắn kiểm tra cách Azure cung cấp SQL Server trong đám mây.

SQL Server phù hợp với bất kỳ cơ sở dữ liệu nào khác cho loại công việc này, nhưng nếu bạn nghĩ làm việc gì đó ở quy mô đó, bạn có thể làm việc tốt hơn với hệ thống lưu trữ bảng đám mây thay vì cơ sở dữ liệu quan hệ thông thường về khả năng mở rộng hoặc thiết kế một hệ thống không đồng nhất sử dụng lưu trữ bảng để quản lý dữ liệu quy mô lớn hơn và cơ sở dữ liệu cho những nơi bạn cần các cơ sở giao dịch hoặc quan hệ cung cấp.

Bạn không nên sử dụng các công cụ cơ sở dữ liệu truyền thống nếu bạn cần các khả năng mở rộng ồ ạt thực sự.

Cơ sở dữ liệu SQL truyền thống có quy mô khá tốt (bạn sẽ tìm thấy nhiều ví dụ về các trang web lớn sử dụng MySQL, SQL Server hoặc Orcale) nhưng tại một thời điểm nhất định, bạn sẽ đạt giới hạn khả năng mở rộng. Chính xác khi điều này xảy ra sẽ phụ thuộc vào mức độ yêu cầu, mức độ phức tạp của các yêu cầu ứng dụng của bạn, số tiền bạn sẵn sàng chi cho các máy chủ đắt tiền và mức độ bạn có thể tối ưu hóa việc sử dụng cơ sở dữ liệu. Nhiều trang web sẽ không bao giờ đạt đến giới hạn này, nhưng nếu bạn làm vậy thì điều đó khá đau đớn và bạn sẽ phải đối mặt với một thách thức kỹ thuật lớn để khắc phục vấn đề.

Ngoài thời điểm này, bạn thực sự cần một cơ sở dữ liệu NoQuery được phân phối đầy đủ - ví dụ như một thứ như Cassandra , thực tế được phát triển tại Facebook để giải quyết một số thách thức dữ liệu lớn của họ. Cơ sở dữ liệu NoQuery rõ ràng hy sinh một số khả năng của cơ sở dữ liệu SQL truyền thống (thường xoay quanh các giao dịch, khóa và tính nhất quán cuối cùng) để cho phép khả năng mở rộng theo chiều ngang không giới hạn một cách hiệu quả.

Nhìn chung, lời khuyên của tôi sẽ là tìm ra nếu bạn thực sự cần khả năng mở rộng lớn, và chọn con đường công nghệ của bạn cho phù hợp.

Đúng. Tôi tin rằng Microsoft Live.com được xây dựng dựa trên SQL Server.

Là một người hâm mộ Linux / PostgreSQL, hãy để tôi nói rằng bạn có thể tạo Facebook với bất kỳ máy chủ SQL, công nghệ đặc biệt nào hiện nay.

Nếu bạn không có kế hoạch có nhiều người dùng như Facebook (500M), thì hầu hết trang web này (mạng Stack Overflow) được xây dựng trên đầu trang .Net và SQL Server.

Là một công cụ, bạn có thể sử dụng SQL Server nhưng hãy nhớ rằng các trang web như Facebook không được xây dựng trên cơ sở dữ liệu một mình. Họ sử dụng các công nghệ khác nhau để hoàn thành nhiệm vụ, kiểm tra các video của Yahoo để tìm cách facebook quản lý Nhật ký một mình và bạn sẽ nhận ra rằng DB chỉ là một phần của Kiến trúc có thể mở rộng rất lớn. Với khoảng 10000 hàng cập nhật mỗi giây, tôi đã thấy cả SQL Server và Oracle DB đều rất chậm sau vài ngày trên máy cấu hình tốt. Vấn đề của tôi là tôi không thể sử dụng điện toán phân tán. Do đó, điều quan trọng là phải xem xét các hệ thống hỗ trợ mà DB hoặc Kiến trúc có thể mở rộng có thể cung cấp.

Tôi không thể trả lời cho MySQL (!) Nhưng tôi có kinh nghiệm hỗ trợ khách hàng, chúng tôi chọn sử dụng SQLServer hay Oracle. Cho đến nay, chúng tôi thấy rằng nhìn chung không có sự khác biệt giữa chúng, nhưng khi mọi thứ trở nên tốt hơn, Oracle là sản phẩm tốt hơn. Ví dụ: chúng tôi hiện đang gỡ bỏ hệ thống quan trọng nhiệm vụ 24/7 của chúng tôi để lọc một lượng hồ sơ vì SQLServer quyết định sẽ mất nhiều giờ để thực hiện nhiệm vụ này trong khi chạy (trong môi trường được nhân đôi). Chúng tôi đã gặp sự cố với việc vận chuyển nhật ký của một tập dữ liệu lớn qua liên kết WAN chưa bao giờ được giải quyết. Những thứ như thế này luôn khiến chúng tôi vui mừng hỗ trợ các khách hàng chạy trên Oracle, nơi chúng tôi không bao giờ gặp vấn đề như vậy.

Vì vậy, nếu bạn đang tìm kiếm một hệ thống có thể mở rộng quy mô, đó là khi bạn có thể tìm thấy những vấn đề này. Oracle thật buồn tẻ, khó khăn và phiền phức, nhưng nó thực sự hoạt động.