Giới hạn thực tế của cơ sở dữ liệu SQL-Server

Question

Tôi đang thiết lập cơ sở dữ liệu mà tôi dự đoán sẽ khá lớn, được sử dụng để tính toán và lưu trữ dữ liệu. Nó sẽ là một bảng có thể có 10 trường, chứa một khóa chính và hai khóa ngoài cho chính nó. Tôi dự đoán sẽ có khoảng một tỷ bản ghi được bổ sung hàng ngày.

Mỗi bản ghi phải khá nhỏ và tôi chủ yếu sẽ thực hiện chèn. Với mỗi lần chèn, tôi sẽ cần thực hiện cập nhật đơn giản trên một hoặc hai trường của bản ghi được kết nối. Tất cả các truy vấn nên tương đối đơn giản.

Tôi sẽ bắt đầu gặp vấn đề về hiệu suất với máy chủ sql ở kích thước nào? Tôi đã thấy đề cập đến hệ thống vldb, nhưng cũng nghe nói họ có thể là một nỗi đau thực sự. Có một ngưỡng mà tôi nên bắt đầu nhìn vào đó không? Có một db tốt hơn so với sql-server được thiết kế cho loại điều này?

Answer 1

Khi nói về tỷ lệ giao dịch trên 10k/giây bạn không nên hỏi lời khuyên trên diễn đàn ... Điều này gần với hiệu suất chuẩn TPC-C trên 32 và 64 cách, chi phí hàng triệu để điều chỉnh.

Bạn sẽ gặp phải vấn đề gì với kích thước nào?

Với mô hình dữ liệu và thiết kế lược đồ tốt, máy chủ được điều chỉnh đúng và với máy chủ được lên kế hoạch chính xác sẽ không gặp sự cố trong 1 tỷ. hồ sơ mỗi ngày. Các công bố mới nhất SQL Server benchmarks là khoảng 1,2 triệu tran/phút. Đó là 16k giao dịch mỗi giây, với hệ thống có giá khoảng 6 triệu USD vào năm 2005 (64 cách Superdome). Để đạt được 10k tran/giây cho tải theo kế hoạch của bạn, bạn sẽ không cần một Superdome, nhưng bạn sẽ cần một hệ thống khá mạnh (ít nhất 16 cách có thể) và đặc biệt là một rất tốt I/O subsytem. Khi thực hiện lại việc lên kế hoạch dung lượng phong bì, một người thường xem xét khoảng 1 nghìn tran/giây cho mỗi HBA và 4 lõi CPU để cấp dữ liệu cho HBA. Và bạn sẽ cần một vài khách hàng cơ sở dữ liệu (tầng giữa ứng dụng) chỉ để nạp 1 tỷ. hồ sơ mỗi ngày vào cơ sở dữ liệu. Tôi không tuyên bố rằng tôi đã lên kế hoạch cho khả năng của bạn ở đây, nhưng tôi chỉ muốn cung cấp cho bạn một sân chơi bóng chày về những gì chúng ta đang nói đến. Đây là một dự án trị giá hàng triệu đô la, và một cái gì đó như thế này không được thiết kế bằng cách hỏi ý kiến ​​trên diễn đàn.

Answer 2

Trừ khi bạn đang nói chuyện lớn như trong chỉ mục của Google loại lớn, cơ sở dữ liệu doanh nghiệp như SQL Server hoặc Oracle sẽ làm tốt.

James Devlin over at Coding the Wheel summed it up nicely (mặc dù điều này là nhiều hơn một so sánh giữa miễn phí của DB như MySQL với Oracle/SQL Server

Ngày nay tôi muốn nghĩ của SQL Server và Oracle như các ngôi sao chết của vũ trụ cơ sở dữ liệu quan hệ. Vô cùng phức tạp gần như vượt ra ngoài khả năng của một tâm trí con người duy nhất để hiểu.Và một sự lãng phí tiền bạc hoành tráng, ngoại trừ trong những tình huống hiếm hoi khi bạn thực sự cần phải tiêu diệt một hành tinh.

Theo như hiệu suất đi , tất cả đều phụ thuộc vào phân đoạn lập chỉ mục của bạn egy. Chèn thực sự là nút cổ chai ở đây, như các hồ sơ cần phải được lập chỉ mục khi chúng đến, càng có nhiều chỉ mục bạn có, các chèn dài hơn sẽ mất.

Trong trường hợp giống như chỉ mục của Google, hãy đọc "Bảng lớn", thật thú vị khi Google thiết lập để sử dụng các cụm máy chủ để xử lý các tìm kiếm trên lượng dữ liệu khổng lồ chỉ trong vài phần nghìn giây.

Answer 3

Kích thước của cơ sở dữ liệu chính nó không tạo ra vấn đề hiệu suất. Các vấn đề thực tế trong kích thước cơ sở dữ liệu đến từ các vấn đề vận hành/bảo trì.

Ví dụ:

1. De-phân mảnh và tái xây dựng các chỉ số mất quá lâu.
2. Quá trình sao lưu mất quá nhiều thời gian hoặc chiếm quá nhiều không gian.
3. Khôi phục cơ sở dữ liệu không thể thực hiện đủ nhanh trong trường hợp mất điện.
4. Các thay đổi trong tương lai đối với bảng cơ sở dữ liệu mất quá nhiều thời gian để áp dụng.

Tôi khuyên bạn nên thiết kế/xây dựng trong một số loại phân vùng ngay từ đầu. Nó có thể là phân vùng SQL Server, phân vùng ứng dụng (ví dụ: một bảng mỗi tháng), lưu trữ (ví dụ: đến một cơ sở dữ liệu khác).

Tôi tin rằng những sự cố này xảy ra trong bất kỳ sản phẩm cơ sở dữ liệu nào.

Ngoài ra, hãy đảm bảo thực hiện các khoản phụ cấp cho kích thước tệp nhật ký giao dịch.

Answer 4

Nó có thể được thực hiện, nhưng với chi phí phần cứng và kế hoạch của bạn có được MS để spec những thứ ra cho bạn. Nó sẽ là một phần của chi phí HW của bạn.

Nói rằng, Paul Nielson blogged about 35k TPS (3 tỷ hàng mỗi ngày) 2 năm trước. Bình luận đáng đọc quá và phản ánh một số những gì Remus đã nói