Tôi đã nghe nói rằng hiệu suất của cơ sở dữ liệu quan hệ không phân đoạn như MySQL hoặc PostgreSQL "phá vỡ" vượt quá 10 TB.
Tôi nghi ngờ rằng những giới hạn như tồn tại sẽ không xuất hiện với Netezza, Greenplum hoặc Vertica, v.v., tuy nhiên tôi muốn hỏi liệu có ai ở đây có tham khảo bất kỳ nghiên cứu hay nghiên cứu trường hợp chính thức nào trong đó những giới hạn này được định lượng không.
Câu trả lời:
Không có câu trả lời đơn giản cho câu hỏi của bạn, nhưng đây là một vài điều cần suy nghĩ.
Đầu tiên, quy mô không phải là điều duy nhất phải lo lắng. Những gì bạn làm với dữ liệu của bạn là. Nếu bạn có 500 bảng 30 TB dữ liệu và bạn đang thực hiện OLTP đơn giản với rất ít báo cáo, tôi không nghĩ bạn sẽ có quá nhiều vấn đề. Có 32TB cơ sở dữ liệu trên PostgreSQL ngoài kia. Tuy nhiên, đồng thời hiệu suất sẽ giảm đi phần nào vì nó phải đánh vào mọi thứ. Tương tự nếu bạn có 50TB nếu dữ liệu nhưng có bộ dữ liệu thường đạt khoảng 100 GB, thì bạn có thể xây dựng một máy chủ có đủ RAM để giữ phần db đó trong bộ nhớ và bạn là vàng.
Mặt khác, nếu bạn đang cố gắng đưa chế độ (giá trị phổ biến nhất) ra khỏi 1TB dữ liệu, thì việc bạn đang sử dụng hệ thống nào cũng không thành vấn đề, điều này sẽ gây đau đớn khi có hoặc không có shending. (Chỉnh sửa: Trên thực tế, Shending có thể làm cho vấn đề này tồi tệ hơn. )
Các vấn đề chính mà bạn sẽ gặp phải với db khổng lồ trên MySQL và PostgreSQL liên quan đến thực tế là không hỗ trợ song song truy vấn. Nói cách khác, một truy vấn được chạy dưới dạng một khối bởi một luồng duy nhất và nó không thể được chia thành từng phần và chạy riêng lẻ. Đây thường là một vấn đề khi chạy các truy vấn phân tích lớn trên một lượng lớn dữ liệu. Đây là nơi Postgres-XC và Green Plum đến giải cứu vì họ tách rời việc lưu trữ khỏi thực thi và có thể thực hiện việc này ở cấp điều phối viên. Lưu ý rằng Postgres-XC và Green Plum về cơ bản sử dụng shending trong nội bộ nhưng các điều phối viên thực thi tất cả sự nhất quán trên toàn cầu.
Với tính song song truy vấn, bạn có thể chia nhỏ truy vấn, có các kênh I / O bộ xử lý / đĩa khác nhau chạy các phần của nó và báo cáo lại các phần của kết quả được tập hợp và chuyển lại cho ứng dụng. Một lần nữa, điều này thường hữu ích nhất trong phân tích hơn là tải xử lý giao dịch.
Điều thứ hai là một số hệ thống, như Vertica hoặc Greenplum lưu trữ các cột thông tin cùng nhau. Điều này làm cho hệ thống khó sử dụng hơn từ góc độ OLTP và giảm hiệu suất ở đó, nhưng nó làm tăng đáng kể hiệu năng cho khối lượng công việc phân tích lớn. Vì vậy, đây là một sự đánh đổi khối lượng công việc cụ thể.
Vì vậy, câu trả lời là một khi bạn có kích thước trên 1-2 TB, bạn có thể thấy mình phải đối mặt với một số sự đánh đổi giữa các hệ thống và khối lượng công việc. Một lần nữa, đây là đặc trưng cho cơ sở dữ liệu, kích thước của các bộ làm việc, v.v. Tuy nhiên, tại thời điểm này, bạn thực sự phải đi với các hệ thống bông tuyết, tức là các hệ thống độc đáo và phù hợp với khối lượng công việc của bạn.
Tất nhiên điều này có nghĩa là các giới hạn thường không thể định lượng được.
Chỉnh sửa : Bây giờ tôi đã làm việc với cơ sở dữ liệu 9TB xử lý hỗn hợp hỗ trợ quyết định và khối lượng công việc xử lý giao dịch trong PostgreQuery. Thách thức lớn nhất là nếu bạn có câu hỏi đánh vào các phần lớn của tập dữ liệu, bạn sẽ phải chờ một lúc để có câu trả lời.
Tuy nhiên, với sự chú ý cẩn thận đến các nguyên tắc cơ bản (bao gồm chỉ mục, tự động lưu trữ, cách thức hoạt động của chúng ở mức độ thấp, v.v.) và các tài nguyên tính toán đủ, chúng hoàn toàn có thể quản lý được (và tôi ước tính sẽ có thể quản lý tốt trong phạm vi 30TB trong PG).
Edit2 : Khi bạn đi tới 100TB dù gì công trình sẽ phụ thuộc vào dữ liệu của bạn. Tôi đang làm việc trên một cái ngay bây giờ sẽ không mở rộng phạm vi này bởi vì nó sẽ đạt giới hạn 32TB cho mỗi bảng trong PostgreQuery trước tiên.